Der initialization-Abschnitt: MDI- , SDI- Usesmix

AndyB · Beiträge: 1173 Erhaltene Danke: 14 RAD Studio XE2

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?

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?

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:

markieren

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.

_________________
Ist Zeit wirklich Geld?

wdbee · Beiträge: 628 Erhaltene Danke: 1

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 · Beiträge: 754 Erhaltene Danke: 1

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.

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.

// EDIT: Omg bin ich verplant *auf uhr guck* ich hab den ersten Eintrag zu diesem Post überschrieben. :autsch:

_________________
Stellen Sie sich bitte Zirkusmusik vor.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme