Forms in einer DLL erzeugen - die Theorie

[sieppl]

Hi!

Ich möchte kurz die Theorie der Erzeugung von Forms in DLL beleuchten:

Warum führt es zu Problemen in einer DLL eine Form ganz normal mit SHow zu erzeugen? Mir wurde gesagt, dass DLLs keine eigene Nachrichtenschleife haben, was auch logisch ist. Sie benutzen die Nachrichtenschleife der aufrufenden Applikation. Damit wäre dann auch die Nachrichtenschleife von TApplication ausgehebelt. Was es dann sehr schwierig macht eine bestehende Anwendung in eine DLL einzubetten.

Was passiert wenn eine DLL eine Form modal anzeigt?

Ich möchte ein kleines PlugIn für ACDSee schreiben und eine bestehende Applikation zum Verwalten von Fotos einbinden.
In dieser Applikation befinden sich natürlich zahlreiche Application.ProcessMessages und zig andere Referenzen auf TApplication. Ich stehe nun wie eine Ochse im Wald und weiß nicht, welche Konsequenzen mein Vorhaben mit sich bringen wird.
Könnte ich die App zu umschreiben, dass sie brav in einem modalen Fenster läuft? (Inkl. Threads)

Grüße

Sebastian

[MarcoWarm]

bei ShowModal hält der jeweilige Thread an... Wenn du also die Dll nicht in einem Extra Thread laufen lässt, bleibt das Hauptprogramm stehen.

[sieppl]

Ich habe das Problem, dass ich zwar eine Form erzeugen kann und diese modal anzeige, wenn ich in auf dieser andere Frames einbinden möchte, scheitern die Aufrufe mit 'kein übergeordnetes Fenster'. Dies liegt daran, dass der Application.Handle = 0 ist.
Hat denn niemand Erfahrung, was in einer DLL möglich ist und wie man stabil mit Delphi eine Form erzeugt, die alle Möglichkeiten einer 'vollwertigen' Applikation bietet?

[sieppl]

hier habe ich mist geschrieben - gelöscht -

[MarcoWarm]

also das ist alles Möglich...
Es ist so, daß es generell nicht empfohlen wird VCL-Formulare in DLLs auszulagern, da das viel Speicher fressen soll, weil die VCL mehrfach geladen werden muss. Ich mach es trotzdem und die Programme laufen auch Anstandslos. Der offizielle Weg ist, bpl's zu benutzen. Das hab ich auch schon versucht, aber da ärgert man sich nur rum und muss dem Endkunden auch die ganzen System-BPLs von Borland mitliefern (nich so schön)

Auf alle Fälle solltest du der DLL beim Aufruf das ApplicationHandle übergeben.

wenn du willst kann ich dir ja ein bissl Beispielcode posten.

[sieppl]

Zitat von MarcoWarm:

also das ist alles Möglich...
Es ist so, daß es generell nicht empfohlen wird VCL-Formulare in DLLs auszulagern, da das viel Speicher fressen soll, weil die VCL mehrfach geladen werden muss. Ich mach es trotzdem und die Programme laufen auch Anstandslos. Der offizielle Weg ist, bpl's zu benutzen. Das hab ich auch schon versucht, aber da ärgert man sich nur rum und muss dem Endkunden auch die ganzen System-BPLs von Borland mitliefern (nich so schön)

Auf alle Fälle solltest du der DLL beim Aufruf das ApplicationHandle übergeben.

wenn du willst kann ich dir ja ein bissl Beispielcode posten.

BPL ist nicht nötig. Das PlugIn (als DLL) wird ausschließlich für ACDSee benutzt werden. Also werden Formulare nur einmal geladen.
Mein Problem: Falls während der Erstellungsphase eines Frames eine Message an den Handle des Frames gepostet werden soll gibt es die Fehlermeldung 'kein übergeordnetes Fenster'. Weil der Owner in diesem Moment noch kein Handle besitzt wird auf den Handle der Application zurückgegriffen. Dieses ist aber Null wenn die Form von einer DLL erzeugt wird. Ich habe schon versucht dem Application. Handle der globalen Instanz innerhalb meiner DLL den Handle der aufrufenden Application zuzuweisen. Probeweise Application.Handle einer DummyHost.exe die ich mir fix zusammengeschraubt habe, aber auch den Handle einer TestForm der DummyHost.exe. Beides führt zu Zugriffsverletzungen. Ich kann aber gerne nochmal die genauen Resultate posten, bei beiden Versuchen.

[negaH]

Tja, so geht es los, die ständigen Probleme mit "Forms in DLLs".

Technisch gesehen kann die VCL solche Sachen nicht unterstützen, d.h. jedweige Lösung des Problems über die VCL muß in schlechten Tricksereien ausarten.
Die einzigst saubere Lösung wäre es auf die VCL zu verzichten und reines native Windows API zu benutzen, da die Windos-Fensterhandles sehr wohl über DLL's erzeugt werden können.

Möchte man die VCL denoch benutzen so gibt es nur eine saubere Lösung:

1.) beim Aufruf der DLL Funktion die ein TForm erzeugt muß der Aufrufer ein ParentWindowHandle: hWnd mit übergeben.
2.) der Aufrufer erzeugt seinerseits ein TForm als Container und übergibt dessen Handle der DLL als ParentWindowHandle.
3.) die DLL Funktion die nun das TForm erzeugt muß Form.ParentWindowHandle := ParanWindowHandle setzen. Das So erzeugte TForm muß ohne Caption, Border und alClient erzeugt werden. Somit ist dieses TForm inplaced eingebettet in den TForm Container der Hauptanwendung. Dieser TForm Container kann auch ein MDI Child sein.
4.) die Hauptanwendung muß ihrerseits einige Änderungen am VCL Code vornehmen, sprich an den Original Sourcen der VCL. Hauptsächlich müssen nur 2-3 Methoden geändert werden in denen per IS und AS Operatoren in der Fokusierung eines Controls dessen Klassentyp abgefragt wird. Diese IS und AS Sourcestücken müssen dürch Class.ClassNameIs() umgebaut werden. Statt also mit IS und AS direkt den Klassenzeiger zu vergleichen muß man alles so umbauen das die Klassennamen verglichen werden.

Dann und nur dann kann man davon ausgehen das dieses System zu 99% stabil funktioniert.

Gruß Hagen