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