Nach welcher Regel werden Procedures ausgeführt?

[Nogge]

Hallo Community,
Der Titel beschreibt leider nicht genau meine Frage, aber wusste keine bessere Formulierung. Ich möchte gern wissen, wann die 2te Form erstellen wird:

Delphi-Quellcode:

 Application.CreateForm(TForm1, Form1);
 Application.CreateForm(TForm2, Form2);

Da müsste es ja (rein logisch gedacht) 2 Varianten geben:
1.) Die 2te Form wird erst erstellt (mit dem zusätzlichen Code in OnCreate), wenn die 1te Form erstellt wurde (mit dem zusätzlichen Code in OnCreate).
2.) Die 2te Procedure wird sofort nach der 1ten ausgeführt, d.h. es könnte zu Problemen in der 2ten Procedure kommen, wenn diese best. Variablen o.Ä. aus der 1ten vorraussetzt. Wenn nämlich die 1te Procedure ziemlich viel Code enthält, der während des Ausführens der 2ten Procedure abgearbeitet wird, könnte eine Variable noch auf false (Standard) gesetzt sein, obwohl diese im Verlauf des Abarbeitens auf true gesetzt wird.

Hoffe, Ihr könnt mir helfen...
mfg Nogge

[Bernhard Geyer]

Du hast D7-Pro und kannst die Sache ja selbst nachvollziehen:

Einfach Debug-Breakpoints an den zu untersuchenden Stellen setzen.
Aber Variante 1 ist richtig (Ohne Test und gewähr). OnCreate wird am Ende des Konstruktur gerufen.

[Hansa]

Formübergreifende Variablen etc. sollte man tunlichst auf jeden Fall vermeiden. 8) Dann tauchen nämlich solche Probleme auf, die du hast/befürchtest. Ein Grund, warum ich Forms nur zur Laufzeit erzeuge ist, daß dann eventuelle Fehler viel früher auftauchen. Z.B. habe ich immer im OnCreate die Initialierungen drin. Dadurch kann man sicher sein, daß sofern keine AV kommt wegen nicht zugreifbarer Form, daß dann die Variablen von Anfang an richtige Werte haben. Es taucht aber kein Fehler auf und es handelt sich nicht um ein kleines Projekt.

Wenn du anfängst, zu überlegen in welcher Form welche Variable drin ist und wo sie wie von was auch immer für irgendeine Aktion gebraucht und auch verändert wird, das ergibt dann im Endeffekt den klassischen Spaghetti-Code. :mrgreen: Und dann gibts ja auch noch private, protected usw. Würde ich mir mal ansehen.

[SirThornberry]

1tens ist richtig, zweiteres geht ja nicht wenn du nicht mit threads arbeitest da ja immer nur einwas gemacht werden kann. Und somit wird erst das create von form1 abgeschlossen und danach wird weitergemacht.

[Nogge]

Ich habs gerade ausprobiert: Methode 2 ist die richtige! Ich habe ShowMessage('bla') in OnCreate von Form2 geschrieben und einen BreakPoint in OnCreate der Form1 gesetzt (einmal ganz oben, mitte und weiter unten). In allen Fällen habe ich die Message erhalten.
Gefällt mir zwar gar nicht, dass es sich so verhält, aber damit muss ich leben...
Vielen Dank für den Tipp, Bernhard Geyer.

[Hansa]

Zitat:

Zitat von Nogge

...aber damit muss ich leben...

Mußt du nicht. Höchstens alle Antworten lesen. :stupid: Warum erzeugst du nicht alles selber und zwar dann, wenn das ganze Sinn macht ? Gehe mal zu Projekt -> Optionen -> Formulare.

[Nogge]

Forms zur Laufzeit zu erstellen, ist zwar besser (nur eine Unit, d.h. keine formübergreifenden Variablen, kontrolliertes Erstellen von anderen Forms usw.), aber so müsste ich wie bei NonVCL alle Objects selbst setzen, d.h. die Position und deren Procedures, was unglaublich viel Arbeit ist!
@Hansa: Was wolltest du mir damit sagen?

Zitat:

Gehe mal zu Projekt -> Optionen -> Formulare.

Ich kann doch auch gleich manuell im program das "Autoerstellen" aller Forms deaktivieren, indem ich best. Zeilen löschen...

[Luckie]

Du kannst doch in den Projekt Optionen einstellen, dass er die zweite Form nicht sofort beim Start laden soll. Nix mit Kontrolls erst zur Laufzeit erzeugen usw.

[Nogge]

Wenn ich das richtig gemacht habe (Auto-create forms in Available forms verschieben außer der Main_Form), dann erscheint, wenn ich eine andere Form öffnen möchte, eine Fehlermeldung (geht nicht genauer..."Read of Address: YxYYYYYYY).

[Sharky]

Hai Nogge,

hast du das Fenster denn auch erstellt?
Im Anhang ist mal ein ganz einfaches Beispiel.

[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

Delphi-Quellcode:

Listbox.Parent := Form2;

[Nogge]

Delphi-Quellcode:

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:

Delphi-Quellcode:

TNewClass.SetParent(TControl);

statt:

Delphi-Quellcode:

TNewClass.Parent := TControl;

aufrufst wird es knallen.
Gruß

[Nogge]

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