Entwickler-Ecke :: Thema anzeigen - Der initialization-Abschnitt: MDI- , SDI- Usesmix

opfer.der.genauigkeit - Do 31.03.05 14:29
Titel: Der initialization-Abschnitt: MDI- , SDI- Usesmix

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?!? :shock:

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. :roll:

wbdbee hat folgendes geschrieben:

Irgend wie reden wir noch aneinander vorbei?

Anscheinend. :lol:

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. :D 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.

jasocul - Do 31.03.05 15:10

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. :gruebel:

opfer.der.genauigkeit - Do 31.03.05 15:17

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. :roll:

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:

Delphi-Quelltext

1:	Application.Initialize;

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. :wink:

opfer.der.genauigkeit - Do 31.03.05 15:52

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. :cry:

//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. :shock:

opfer.der.genauigkeit - Do 31.03.05 16:49

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:

Delphi-Quelltext

1:
2:
3:
4:

initialization
  ClassMgr.Add(TMyMDIClass); // Add ist eine Liste mit Elementen des Typs "TFormClass"

end.

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. :gruebel:

opfer.der.genauigkeit - Do 31.03.05 17:43
Titel: Re: Der initialization-Abschnitt: MDI- , SDI- Usesmix

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 :D
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. :roll:

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.

AndyB - Do 31.03.05 18:09
Titel: Re: Der initialization-Abschnitt: MDI- , SDI- Usesmix

opfer.der.genauigkeit hat folgendes geschrieben:

Woran könnte das liegen :?:
===========================
Ich vermute irgendwie, daß SDI- Formulare vor MDI- Formularen initialisiert werden?!? :shock:

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.

Zitat:

Gibt es da Prioritäten, mit denen bestimmte Module, in bestimmter Reihenfolge initialisiert werden?

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?

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.

Als Alternative kannst auch aus der ClassMgr Variable eine Funktion (mehr eine Art Singleton) machen:

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:

interface

function ClassMgr: TClassMgr;

implementation

var
  GlobalClassMgr: TClassMgr = nil;

function ClassMgr: TClassMgr;
begin
  if not Assigned(GlobalClassMgr) then
    GlobalClassMgr := TClassMgr.Create;
  Result := GlobalClassMgr;
end;

initialization

finalization
  FreeAndNil(GlobalClassMgr);

end.

wdbee - Do 31.03.05 18:31

Irgend wie reden wir noch aneinander vorbei?
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.

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!

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.

// Edit: Der Vorschlag von AndyB meint doch genau das selbe Prinzip. Leider ist dein Klassenmanager aber keine Funktion sondern ein Objekt.
Ich habe bei meinen IPC-Units (Siehe im Forum Windows API - Unit zur Interprozesskommunikation) ein sehr ähnliches Problem. Jede Instanz des Demo-Progrmms erzeugt blind per Obj.Create eine Instanz des Kommunikationsobjektes, denn keine Instanz weiß vorher ob es das Objekt schon gibt und erst mit diesem Objekt kann miteinander kommuniziert werden! Der Konstruktor selbst prüft dann im MappedMemory, ob es das Objekt schon gibt. Wenn nein, wird es angelegt, wenn ja liefert der Konstruktor das vorhandene Objekt. Das war zwar etwas Gymnastik für den Konstruktor, aber die Anwendungen sind damit sehr einfach zu programmieren.

opfer.der.genauigkeit - Fr 01.04.05 08:02

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?!? :shock:

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?

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:

AndyB hat folgendes geschrieben:

wbdbee hat folgendes geschrieben:

Irgend wie reden wir noch aneinander vorbei?

Anscheinend. :lol:

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:

Nicht mehr die erste bei der Initialisierung. Richtig. :)

wbdbee hat folgendes geschrieben:

Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!