Nach welcher Regel werden Procedures ausgeführt?

[Nogge]

Jo, Danke! Hab das Schema jetzt verstanden, nur sind dadurch andere Probleme entstanden, die ich aber wohl alleine beheben kann. Sonst greif ich auf Eure Hilfe zurück^^

[Nogge]

Ich habe den neuen Fehler leider nicht lösen können.
Im OnCreate-Event einer 2ten Form, die jetzt also im OnCreate-Event der Main_Form erstellt wird (Form2:=TForm2.Create(self)), lasse ich eine Listbox zur Laufzeit erstellen. Mit Hilfe von SetParent(Form2) setze ich den Hintergrund. Jedoch erhalte ich eine Fehlermeldung ('Control '' has no Parent Window'), sobald auf die Listbox zugegriffen wird.
Eigentlich müsste die Listbox angezeigt werden, da ich ein Parent gesetzt habe...

[SirThornberry]

den Parent setzt man ja auch so
Listbox.Parent := Form2;

[Nogge]

Listbox.SetParent(Form2) ist genau das selbe. Aber wenn du mir nicht glaubst, kannste es ja mal ausprobieren. Zur Beruhigung: Ich habs auch schon mit "deiner" Variante versucht, was den selben Fehler entstehen ließ.

[Leuselator]

1. SetParent(TControl) ist nicht das selbe wie Parent:= TControl, auch wenn es funktioniert. Sinn der Property "Parent" und der dazugehörigen Setter-Methode "SetParent" ist ja eben, Dich daran zu hindern, direkt mit den Objektinternen Methoden zu arbeiten (OOP). Benutze also "Parent :=" und Dein Code wird auch noch funktionieren, wenn sich die Setter-Methode "SetParent()" ändern sollte.

2. Verlagere die Erzeugung der Listbox in der 2. Form aus OnCreate nach OnShow - dann sollte das Problem behoben sein. OnCreate wird getriggert, bevor z.B. ein Handle erstellt wurde - daher knallt Dein Code wenn Du ein Parent setzen möchtest, da dafür ein Parent-Handle nötig ist.
Gruß

[Nogge]

Jo, Danke. Wenn ich das Erstellen der Listbox in das OnShow-Event verlege, funktioniert wieder alles. Allerdings habe ich deine Erklärung für den Unterschied zw. SetParent und Parent nicht ganz verstanden ;_;

[Leuselator]

Der Grund ist saubere OOP:
Der Sinn, ein Property namens "Parent" anzubieten ist, Dir einen immer funktionierenden Weg zu geben, das Parent eines Controls zu setzen. Intern ruft das Control seine Setter-Methode "SetParent" auf und nimmt die nötigen Schritte vor. Wenn der Programmierer des Controls (mußt nicht Du sein) sich entscheidet, eine andere Setter-Methode für das Property "Parent" zu implementieren, stehst Du da und änderst Deinen gesamten Code. Dem Programmierer des Controls ist kein Vorwurf zu machen, solange er das Property "Parent" am Leben läßt - er geht davon aus, daß alle Zugriffe auf dieses erfolgen und nicht auf die Objektinterne Setter-Methode.

Spielt für VCL-Controls nicht so die Rolle (da relativ selten geändert), aber wenn Du eigene Controls entwickelst, oder Fremdcontrols nutzt, solltest Du Dich strikt an die Benutzung der Properties und nicht der internen Setter-Methoden halten, weil auch das geht:

Delphi-Quellcode:

TNewClass = class(TWinControl)
private
  function  GetMyNewParent:TControl;
  procedure SetMyNewParent(Value:TControl);
public
  property Parent read GetMyNewParent write SetMyNewParent;
end;

implementation

function  TNewClass.GetMyNewParent:TControl;
begin
  Result := inherited Parent;
end;

procedure TNewClass.SetMyNewParent(Value:TControl);
begin
  // hier macht er irgendwas Lebenswichtiges oder verrücktes
  // und dann:
  inherited Parent := Value;
end;

Wenn Du dann:
TNewClass.SetParent(TControl); statt:
TNewClass.Parent := TControl; aufrufst wird es knallen.
Gruß

[Nogge]

Alles klar, Vielen Dank für die Mühe ;-)