AndyB hat folgendes geschrieben:

opfer.der.genauigkeit hat folgendes geschrieben: Woran könnte das liegen =========================== Ich vermute irgendwie, daß SDI- Formulare vor MDI- Formularen initialisiert werden?!? Das sicherlich nicht, denn der Compiler weiß nicht mal was ein SDI oder MDI Formular ist. Er ist eben auch nur ein Compiler, der mit Units arbeitet.

Naja, wäre auch irgendwie schwer vorstellbar, aber ich kann mir das irgendwie nicht mehr erklären. (siehe Zitat Hilfe)

AndyB hat folgendes geschrieben:

opfer.der.genauigkeit hat folgendes geschrieben: Gibt es da Prioritäten, mit denen bestimmte Module, in bestimmter Reihenfolge initialisiert werden? Ja. Diese ergeben sich aus allen Units mit uses-Anweisungen. Wobei der genaue Initialisierungsablauf sich durch eine kleine Änderung der uses-Liste sicht stark verändern kann, wie es in deinem Fall passiert. Zitat: In der Hilfe hab ich leider keine Details gefunden, vielleicht weiß jemand von euch ja genaueres. Steht da nicht irgendwo, dass die initialization"-Abschnitte nicht in einer vorhersagbaren Abfolge durchlaufen werden?

Laut Hilfe aber schon:

Delphi-Hilfe hat folgendes geschrieben:

.. Der initialization-Abschnitt enthält Anweisungen, die beim Programmstart in der angegebenen Reihenfolge ausgeführt werden. .. Die initialization-Abschnitte von Units, die von Clients eingebunden werden, werden in der Reihenfolge ausgeführt, in der die Units in der uses-Klausel des Clients angegeben sind.

Klingt für mich so, daß die Abhängigkeit der Initialisierung von der Reihenfolge der Uses- Einträge in der Projekt- Datei und gegebenenfalls dann der Uses- Reihenfolge der einzelnen Module. In dem Projekt hier ist der KM als erster Eintrag in der DPR, im Child und im SDI vorhanden. Danach kommen SDI und Child.

AndyB hat folgendes geschrieben:

Wo wird denn der Klassenmanager (KM) initialisiert? Steht er in einer eigenen Unit? Wenn ja, da solltest du in allen Units, die ihn benutzen, die KM-Unit vor alle anderen "Benutzer-Units" (Formulare, Datenstrukturen, ...) stellen. Und im Hauptprogramm-Quellcode die Unit ebenfalls höher schieben.

Das wäre schön, wenn es funktionieren würde. Jedes MDI- Child ist von einer abgeleiteten Formularklasse, die als ersten Eintrag in der Uses den Klassenmanager besitzt. Der Klassenmanager liegt in einer eigenen Unit und wird dort im initialization- Abschnitt erstellt.
Ich hab schon mehrere Male die Problemmodule verschoben in der Uses- Klausel. Es gab keine Änderung im Resultat, deshalb auch meine seltsame Vermutung bezüglich der Prioritäten bei der Initialisierung.

Bezüglich des Signolton- Vorschlags, danke. Aber ich kann bzw. darf keine Codeänderungen mehr vornehmen außer dem Verschieben der Uses- Einträge.

wbdbee hat folgendes geschrieben:

Irgend wie reden wir noch aneinander vorbei?

Anscheinend.

wbdbee hat folgendes geschrieben:

Ich habe das jetzt so verstanden, dass in jeder Unit, die eine MDI-Klasse enthält, im initialization-Abschnitt ein Aufruf GlobalClassManager.Add(AlleMeineKlassenDieserUnit); steht.

Richtig.

wbdbee hat folgendes geschrieben:

Bisher gab es eine bestimmte Unit, die den GlobalClassManager.Create-Aufruf zuvor erledigt hat. Aber jetzt wechselt die Reihenfolge aus unvermeidlichen Gründen und diese Unit ist nicht mehr die erste!

Nicht mehr die erste bei der Initialisierung. Richtig.

wbdbee hat folgendes geschrieben:

Jetzt kannst du doch in allen MDI-Units im Initialisierungsabschnitt eine globale Funktion aufrufen, die den Klassenmanager BEI BEDARF erzeugt. Nur der erste macht das wirklich, aber die Reihenfolge wird nie wieder eine Rolle spielen. Der der zufällig zu erst kommt, erstellt den Klassenmanager, die folgenden verwenden ihn.

Nein, kann ich nicht und darf ich nicht. Hab ich die über ganz genau *nachgeguckt hat* 820 Formulare erwähnt? *kichert*

Das Problem ist eben, daß ich keine weitläufigen Änderungen machen darf.
Ich arbeite zwar an dem Projekt, bin aber nicht Projektverantwortlicher. .. Bin ja nur Azubi. , da hat man nicht viel Entscheidungsbefugnis.

Erzeugst du die SDIs zur Laufzeit oder sind sie schon vorher erzeugt?

jasocul hat folgendes geschrieben:

Erzeugst du die SDIs zur Laufzeit oder sind sie schon vorher erzeugt?

Laufzeit.

opfer.der.genauigkeit hat folgendes geschrieben:

jasocul hat folgendes geschrieben: Erzeugst du die SDIs zur Laufzeit oder sind sie schon vorher erzeugt? Laufzeit.

Autsch... das ist IMHO so wie du's machst nicht möglich. Mach halt ein eins zur {Laufzeit; EDIT:}Designzeit.

AXMD

Meine Frage war nicht sonderlich sinnvoll (nach einigem Überlegen).
Ich vermute folgendes:
Auch wenn ein Formular nicht erzeugt wird, so muss dennnoch die Initialisierung der Unit durchgeführt werden, wenn diese benötigt wird. Eventuell werden ja Dinge aus der Unit benötigt, die mit dem Formular nichts zu tun haben.
Wenn du also eine MDI-Unit im Uses deiner SDI-Unit benutzt, muss der Initialization-Teil durchgeführt werden.

Daraus folgt, dass du mal mit der Reihenfolge der Uses experimentieren kannst (in der MDI-Hauptform) oder du musst dir ein anderes Konzept zum Initialisieren ausdenken.

@AXMD:

AXMD hat folgendes geschrieben:

opfer.der.genauigkeit hat folgendes geschrieben: jasocul hat folgendes geschrieben: Erzeugst du die SDIs zur Laufzeit oder sind sie schon vorher erzeugt? Laufzeit. Autsch... das ist IMHO so wie du's machst nicht möglich. Mach halt ein eins zur Laufzeit. AXMD

Verstehe ich jetzt irgendwie nicht.

AXMD hat folgendes geschrieben:

Autsch... das ist IMHO so wie du's machst nicht möglich. Mach halt ein eins zur Laufzeit. AXMD

Ich erstelle doch die Formulare erst zur Laufzeit.

jasocul hat folgendes geschrieben:

Wenn du also eine MDI-Unit im Uses deiner SDI-Unit benutzt, muss der Initialization-Teil durchgeführt werden. Daraus folgt, dass du mal mit der Reihenfolge der Uses experimentieren kannst (in der MDI-Hauptform) oder du musst dir ein anderes Konzept zum Initialisieren ausdenken.

Der Initalisierungsteil wird generell ausgeführt:


Das einzige, was definitiv instanziert wird bei Programmstart ist der Klassenmanger und die Haupt- MDI- Form.
Seit das SDI- Formular eingefügt wurde, scheint es aber eine höhere Prio bei der Initialisierung zu besitzen als alles andere.
Mit der Reihenfolge der Uses habe ich schon gespielt, ohne Erfolg.

//Edit: Meine eigentliche Frage bezieht sich darauf, daß ich wissen wollte ob meine Vermutung richtig ist.. wegen Prio und SDI, MDI etc.
Und ob jemand vielleicht weiß, wer welche Prio genießt.

P.S.: Das Projekt hab ich nur übernommen.

Tja, Pech gehabt. Übernommene Projekte sind immer so undankbar.
Eine logisch schlüssige Erklärung habe ich da leider auch nicht parat. Vielleicht gibts ja noch einen Spezi, der sich in dem Bereich auskennt.
Das geht aber schon sehr in die Interna von Delphi. Vielleicht solltest du die Frage mal an Borland weiter geben, wenn du hier keine Antwort bekommst.

Muss mich entschuldigen; hatte mich verschrieben. Designzeit meinte ich natürlich. Tut mir leid, hab's in meinem Post oben korrigiert.

AXMD

jasocul hat folgendes geschrieben:

Tja, Pech gehabt. Übernommene Projekte sind immer so undankbar. Eine logisch schlüssige Erklärung habe ich da leider auch nicht parat. Vielleicht gibts ja noch einen Spezi, der sich in dem Bereich auskennt. Das geht aber schon sehr in die Interna von Delphi. Vielleicht solltest du die Frage mal an Borland weiter geben, wenn du hier keine Antwort bekommst.

Ja, werd wohl Borland schreiben müßen.
Wenn ich das gemacht hab, post ich hier die Antwort.

AXMD hat folgendes geschrieben:

Designzeit meinte ich natürlich. AXMD

Ändert leider nix an dem Problem.


Ich werd jetzt mal versuchen, ob es ne Möglichkeit gibt die Initalisierungsreihenfolge zu beeinflußen.

Soweit aber erst mal danke Leute.

Schau dir mal im Einzelstep den Programmablauf von Anfang an an. Dann siehst sofort, in welcher Reihenfolge die Units initialisiert werden. Setzt dann halt die Unit mit der wichigen Initialisierung an die erste Stelle der Uses-Klausel der ersten initialisierten Unit. Dann sollt die Initialisierung klappen.

wdbee hat folgendes geschrieben:

Schau dir mal im Einzelstep den Programmablauf von Anfang an an. Dann siehst sofort, in welcher Reihenfolge die Units initialisiert werden. Setzt dann halt die Unit mit der wichigen Initialisierung an die erste Stelle der Uses-Klausel der ersten initialisierten Unit. Dann sollt die Initialisierung klappen.

Hab ich glaub ich oben schon erwähnt, bezüglich uses- Klausel spielen und so.
Das ändert nichts an dem Problem.

//Edit: Um ganz genau zu sein, passiert folgendes:

Application.Initialize;

und ab hier springt er ohne Berücksichtigung aller anderen Module sofort in das in den initalization- Abschnitt des MDI- Childs, wenn
es in die SDI- Form eingebunden wird.
Es wird einfach garnichts vorher initialisiert außer der Applikation selbst.

Verändere ich die Reihenfolge tritt der Fehler auch auf.
Entferne ich den Eintrag in der uses- Klausel -> Kein Fehler, Initalsierung findet als aller erstes beim Klassenmanager statt.

Schon mal in den Projektoptionen mit der Reihenfolge der Forms herumgespielt? Soweit ich bemerkt habe, beiinflusst die das Verhalten von MDI-Fenstern auch denn, wenn sie erst zur Laufzeit erzeugt werden.

AXMD

Es gibt keinen Eintrag der "Zu erzeugende Formulare".

Passiert alles zur Laufzeit.

//Edit: ein Teufelskreis *kichert*

opfer.der.genauigkeit hat folgendes geschrieben:

Es gibt keinen Eintrag der "Zu erzeugende Formulare". Passiert alles zur Laufzeit. //Edit: ein Teufelskreis *kichert*

Und was, wenn du mal testweise im Projektquelltext ein einziges von diesen Formularen erzeugst (aber nicht anzeigst)?

AXMD

Welches Formular?

MDI- Formulare zu erzeugen, würde grundsätzlich den Fehler hervorrufen, da sich alle im initalization- Abschnitt beim Klassenmanager registrieren.
SDI- Formulare so zu erzeugen, wenn sie ein MDI- Formular als Eintrag in der uses- Klausel besitzen, führt ebenfalls zu diesem Fehler.

Ich sag ja, Teufelskreis.

Oder was meinst du?

opfer.der.genauigkeit hat folgendes geschrieben:

Welches Formular? MDI- Formulare zu erzeugen, würde grundsätzlich den Fehler hervorrufen, da sich alle im initalization- Abschnitt beim Klassenmanager registrieren. SDI- Formulare so zu erzeugen, wenn sie ein MDI- Formular als Eintrag in der uses- Klausel besitzen, führt ebenfalls zu diesem Fehler. Ich sag ja, Teufelskreis. Oder was meinst du?

Könntest du vielleicht mal so einen initialization-Code posten? Soweit ich weiß, wird der nämlich auch dann ausgeführt, wenn du die Form nicht erstellst.

AXMD

Wenn ich dich richtig verstanden habe, wird der Teil, der initialisiert werden muss, erst benötigt, wenn das erste Formular erstellt werden soll.
Warum muss das dann im initialization Abschnitt erfolgen?
Könntest du nicht eine class procedure Init; verwenden, bei der du bestimmen kannst, wann sie aufgerufen werden muss?

AXMD hat folgendes geschrieben:

Könntest du vielleicht mal so einen initialization-Code posten? Soweit ich weiß, wird der nämlich auch dann ausgeführt, wenn du die Form nicht erstellst. AXMD

Jap, wird auch ausgeführt, wenn die Form noch nicht erstellt ist.


MDI- From:

wdbee hat folgendes geschrieben:

Wenn ich dich richtig verstanden habe, wird der Teil, der initialisiert werden muss, erst benötigt, wenn das erste Formular erstellt werden soll.

//Edit: Die Formularklassen werden von Anfang an benötigt.
Zwar werden keine Formulare erzeugt, aber die Klassen werden in einem anderen Modul verwendet)

wdbee hat folgendes geschrieben:

Warum muss das dann im initialization Abschnitt erfolgen?

Weil das so definiert wurde. Der Hintergrund ist sogar an sich nicht mal schlecht.
Alle MDI- Formulare registrieren sich beim Klassenmanager mit ihrer Formularklasse (TFormClass)
und können dann bei Bedarf über den Klassenmanager erzeugt werden.
Also Modularität, Transparenz etc. was halt so die Vorteile für sowas sein könnten.

wdbee hat folgendes geschrieben:

Könntest du nicht eine class procedure Init; verwenden, bei der du bestimmen kannst, wann sie aufgerufen werden muss?

Wie gesagt, es sind insgesamt über 100 MDI- Formulare und eine Unzahl von anderen Klassen und d.h. ich müßte jeden "Init" per Hand
aufrufen um die Formulare zur Registrierung beim Klassenmanager zu bringen. Das wäre ziemlich zeitaufwendig.

Ja hm.. naja.. is halt doof irgendwie.

opfer.der.genauigkeit hat folgendes geschrieben:

Details bezüglich des Klassenmanagers sind hier nicht wichtig, nur soviel, daß er vor den MDI- Childs instanziert worden sein muß.

Mein Konzept: Dein Klassenmanager wird von jedem MDI-Child initialisert, bzw. die entsprechende classen procedure Init wird aufgerufen. In einer Klassen- bzw. Unit-Variablen cBinInitialisert: Boolean; vermerkt der Erste, das es erledigt ist. Alle weiteren Aufrufe kehren sofort zurück. Da kann doch nie etwa durcheinander kommen?

Moderiert von AXMD: Quote-Tags repariert

wdbee hat folgendes geschrieben:

Mein Konzept: Dein Klassenmanager wird von jedem MDI-Child initialisert..

Naja, ich glaub nicht, daß du das wirklich so meinst, wie du gesagt hast, sonst hab ich bald 100 Instanzen meines Klassenmanagers
Du meinst eher, daß die MDI- Childs sich dann dort registrieren.

wdbee hat folgendes geschrieben:

.., bzw. die entsprechende classen procedure Init wird aufgerufen. In einer Klassen- bzw. Unit-Variablen cBinInitialisert: Boolean; vermerkt der Erste, das es erledigt ist. Alle weiteren Aufrufe kehren sofort zurück. Da kann doch nie etwa durcheinander kommen?

Der Ansatz wäre an sich ja richtig, das entscheidende Problem ist der "Mehraufwand" den ich dadurch hätte.
Ich müßte also für jedes MDI- Child die Initfunktion aufrufen, in der dann die jeweilige Formularklasse weitergereicht wird.
D.h. aber auch, daß es ein Modul geben muß, daß für jedes Child die Initfunktion aufruft, da die Klassen ja registriert werden müßen
und das Modul müßte alle Formulare kennen. (Eintrag in die Uses)

Im Prinzip, könnte man sich das ja mit dem Initialization - Teil, da dieser so oder so nur 1 Mal aufgerufen wird.

Bloß die Reihenfolge stimmt nicht wegen dem SDI. Ich schätze mal, das wußte keiner von den Leuten, auch ich nicht.

Ich kann nicht das ganze Konzept von dem Projekt über den Haufen werfen bzw. darf nicht, den Zeitaufwand bezahlt mir keiner.

Das Problem ist zwar in diesem Fall das Konzept, aber dafür brauch ich ja garkeine Lösung, weil ich es nicht ändern kann.
Das Projekt ist jetzt ca. 8 Jahre alt.