Wie kommt ein TDBEdit an die Instanz meines DataModules? Warum/Wie funktioniert es?

[Stevie]

Das ganze könnte man als Bug bezeichnen, denn wenn du dir zur Laufzeit mal anschaust, ob MyDBEdit.DataSource assigned ist, wirst du feststellen, dass dies nicht der Fall ist. Die IDE nimmt einfach nur den Klassennamen des DataModules und streicht das T weg.

Wenn du mal händisch den Namen der globalen DataModule variable änderst, wirst du feststellen, dass dies dann auch passiert.
Korrektur: Das lag bei mir nur daran, dass ich dann keine Instanz des DataModules hatte - siehe meinen Post weiter unten.

[Hansa]

Zitat von schlecki:

hm, da ich nicht soo viel visuell arbeite, ist mir das eigentlich gleich

Was hat visuell mit Sichtbarkeiten von Variablen + Co. zu tun ? Obwohl, vom Wort her könte man das eventuell schon vermuten.

Zur Frage an sich : das geht schon sehr, sehr tief in die Eingeweide von Delphi rein. Solche Fragen werden sich hier kaum lösen lassen. Zumindest, wenn man mal folgendes bedenkt : die einzige mir bekannte Quelle, wo das Verhalten, IDE/Laufzeit in punkto DB-Komponenten näher erläutert wird, das sind Marco Cantus Bücher. Und sogar der braucht ca. 10-50 Buchseiten, je nachdem wo man anfängt.

Zitat von RSE:

Das Datenmodul wird "von Hand" im Konstruktor von MyForm erzeugt. Deswegen wundere ich mich ja, wie es trotz allem noch funktioniert.

Warum wird das denn überhaupt von Hand erzeugt ? Welchen Sinn macht das denn ? Ich erzeuge etliches zur Laufzeit, aber auf die Idee, ein Datamodul so zu erzeugen bin ich noch nicht gekommen, das macht einfach nur Ärger. Siehe diesen Thread hier.

[schlecki]

Zitat von Hansa:

Zitat von schlecki:

hm, da ich nicht soo viel visuell arbeite, ist mir das eigentlich gleich

Was hat visuell mit Sichtbarkeiten von Variablen + Co. zu tun ? Obwohl, vom Wort her könte man das eventuell schon vermuten.

Mir ging es hier nur um den Unterschied public vs. published

[RSE]

Zitat von Stevie:

Das ganze könnte man als Bug bezeichnen, denn wenn du dir zur Laufzeit mal anschaust, ob MyDBEdit.DataSource assigned ist, wirst du feststellen, dass dies nicht der Fall ist.

Widerlegung:

Delphi-Quellcode:

procedure TMyCustomForm.MyDBEditClick(Sender: TObject);
begin
  if MyDBEdit.DataSource = nil then
    Exit;
  Showmessage(MyDBEdit.DataSource.Owner.ClassName); // Rückgabe: "TMyDM"
end;

Zitat von Stevie:

Die IDE nimmt einfach nur den Klassennamen des DataModules und streicht das T weg.

Das habe ich mir auch so zusammengereimt. Das, was dann dabei rauskommt + Name der DS kann man im OI in die Eigenschaft DataSource eintragen. Dann hat man mein Verhalten.

Zitat von Hansa:

Zitat von RSE:

Das Datenmodul wird "von Hand" im Konstruktor von MyForm erzeugt. Deswegen wundere ich mich ja, wie es trotz allem noch funktioniert.

Warum wird das denn überhaupt von Hand erzeugt ? Welchen Sinn macht das denn ?

Die Bezeichner, die ich hier verwende sind beispielhaft gewählt (wer hätte das vermutet?). Das Originalprojekt besteht aus hunderttausenden Quelltextzeilen. Es gibt ein Grundprogramm, in das verschiedene Projekte integriert werden. In jedem Projekt gibt es ein DM und ein ProjektForm. Es ist immer nur ein Projekt instanziert, lassen wir auch die Projekt-DMs nicht automatisch bei Programmstart erzeugen. In das ProjektForm werden mehrere Frames geladen, die mehrere Seiten ergeben (das wäre dann der Inhalt des Projekts). Ein Projekt besteht aus 10.000-15.000 Quelltextzeilen. Beim Anlegen neuer Projekte wird ein altes Projekt kopiert und entsprechend der Anforderungen des neuen Projekts abgeändert. Bitte diskutiert jetzt nicht über das Design der Anwendung, das steht seit vielen Jahren fest und kann nicht problemlos geändert werden. Diskussionen darüber sind daher zwecklos.

Früher haben wir mit den globalen Variablen gearbeitet, die Delphi uns vorgegeben hat. Das hatte zur Folge, dass das DM in jedem Projekt unter anderem Namen erreichbar war. D.h. bei jeder Übernahme von Quelltextpassagen aus anderen Projekten musste jede Referenz auf das DM per Suchen und Ersetzen ausgetauscht werden. In einem ersten Schritt haben wir also die Variable einheitlich genannt (ProjektDM). Wir haben uns nix weiter dabei gedacht und es funktioniert prima.

Nun habe ich eine projektübergreifende Superklasse für das DM und das ProjektForm entworfen. Das entspricht nun genau meinem komplexeren Beispiel, über das hier nun diskutiert wird.

[stahli]

Hmm, mal ein paar Überlegungen:

Was bringt denn:

Delphi-Quellcode:

Showmessage(MyDBEdit.DataSource.Owner.Name);
Showmessage(MyDBEdit.DataSource.Name);
FindComponent('MyCustomDM')...

Kann es denn sein, dass Du in Deinem Demobeispiel maßgebliche Variablen Deines echten Projektes "unterschlägst", dass also tatsächlich irgendwo eine solche Variable definiert ist?

Kannst Du Deinen Demotext mit vertretbarem Aufwand in ein echtes Projekt gießen und live testen?
Dann könnten wir das vielleicht auch mal genauer nachvollziehen...

[RSE]

Zitat von stahli:

Hmm, mal ein paar Überlegungen:

Was bringt denn:

Delphi-Quellcode:

Showmessage(MyDBEdit.DataSource.Owner.Name);
Showmessage(MyDBEdit.DataSource.Name);
FindComponent('MyCustomDM')...

1. "MyDM"
2. "MyDS"
3. nil
Das scheinen mir alles sehr korrekte Werte zu sein...

Zitat von stahli:

Kann es denn sein, dass Du in Deinem Demobeispiel maßgebliche Variablen Deines echten Projektes "unterschlägst", dass also tatsächlich irgendwo eine solche Variable definiert ist?

Ich habe das ganze Projekt durchsucht: Es kommt TMyCustomDM, UMyCustomDM (Der Klassenname ohne T ist im Originalprojekt Teil des Unitnamens - Fehler im ersten Beitrag) und in der DPR etwas wie "UMyCustomDM in 'pfad\UMyCustomDM.pas' {MyCustomDM: TDataModule},". Die Zeile in der DPR ist also der einzige Ort im ganzen Projekt (abgesehen von DFMs), in dem der Bezeichner MyCustomDM vorkommt, und dort tut er es nur in einem Kommentar.

Zitat von stahli:

Kannst Du Deinen Demotext mit vertretbarem Aufwand in ein echtes Projekt gießen und live testen?
Dann könnten wir das vielleicht auch mal genauer nachvollziehen...

Ich probiere mal, inwieweit das ohne tatsächliche DB-Anbindung ausführbar ist und hänge es ggf. hier an einen Beitrag von mir an.

[stahli]

"UMyCustomDM in 'pfad\UMyCustomDM.pas' {MyCustomDM: TDataModule},"

Ich weiß es nicht wie der Compiler genau vorgeht, aber vielleicht wertet er ja diesen "Kommentar" irgendwie aus und erzeugt beim Öffnen des Projektes eine passende Variable - eben zur Herstellung der Projektverbindungen. Ist nur Spekulation - wäre aber ja denkbar.

Ändere doch mal testweise den Kommentar in {MyCustomDMXxx: TDataModule}.

Wenn es dann nicht mehr funktioniert, hätte man eine Erklärung...

[RSE]

Ich habe jetzt mal mein Beispiel implementiert... und es läuft nicht. Baue ich in das Originalprojekt genau die selbe DS und das selbe DBEdit ein, klappt es. Somit ist dem Thread gerade die Diskussionsgrundlage entzogen worden...
Ich werde mich auf die Suche machen und mich dann wieder melden.

[Stevie]

Du kannst in deinem uns nicht vorliegenden Projekt gern widerlegen, was ich sagte, es stimmt dennoch. Erzeugst du allerdings irgendwo eine Instanz dieses DataModules, wird diesem DataModule ein Name verpasst (rat mal welcher) und sie wird gefunden, wenn die Form aus der dfm geladen wird bzw wenn dieses ominöse GlobalFixupReferences aufgerufen wird (Tip: kompilier mit debug dcus und setz nen Stoppunkt in TDBEdit.SetDataSource)

Die Identifizierung der Komponenten, die in der dfm einander zugewiesen werden, geschieht anhand des Namens.

Siehe Anhang

[stahli]

Oha!

Also mit dem DataModuleName stimmt. Siehe Code + ScreenShot.

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var
  DM2a, DM2b: TDataModule2;
begin
  DM2a := TDataModule2.Create(Application);
  Caption := Caption + '->' + DM2a.Name;
  DM2b := TDataModule2.Create(Application);
  Caption := Caption + '->' + DM2b.Name;
end;

Dann sollte aber FindComponent die Komponente finden...

Ich steige hier aus und warte auf einen Abschlussbericht des TE