There are lots of resources and solutions out there on the internet that are specific to this problem, however, in using the BusinessSkinForm components, that are tightly integrated with the VCL and messaging, I came across a few problems with the standard approaches.
The final solution came with the assistance of Steve Woods (aka Reconics).
The main problem with storing Forms in dlls and being able to create instances of them from within a host exe is that when Delphi compiles up a dll, it has its own TApplication and TScreen instances (as well as other info as to be discovered).
This means that the DLL and the EXE message loops are different, the RTTI information is different, and causes lots of problems like the well know "cannot assign a TFont to a TFont" message.
So how do we Coax the form in the DLL to think it is part of the EXE, we replace the Application and Screen Object in the DLL with the reference to the EXE's Application and Screen.
This is a standard approach that you will find on the net. However there is one additional element that needs to be passed from EXE to DLL and this is the tricky one.
From Steve Woods -
The problem is caused by the ControlAtom local variable in the Controls.pas units. When the controls unit initializes it creates a global atom based on the string 'ControlOfs' + the HInstance and thread ID of the application and stores the atom in the ControlAtom local variable.
All well and good. Then when new wincontrols are added to the application a pointer to the control is stored under the window handle using the SetProp API function. This allows
Delphi to get the TWinControl of a Handle.
The CM_MouseEnter etc. events are generated from the TApplication.DoMouseIdle method. In order to get the current wincontrol under the mouse, and thus pass the required messages, its searches for a property with a Atom equal to the local ControlAtom variable stored in the Controls units.
This all works fine for standalone apps but when you start putting forms in DLL's the following happens:
The controls unit is initialized again for the DLL. This creates a new global atom and stores it in the Controls unit local variable, so you now have TWO control global atoms, one for the main app and one for the DLL.
And thus, when the Application.DoMouseIdle method tries to find a property stored with the same name (atom) as the application on a DLL form, it fails. To solve this I had to hack the controls.pas units a little. I added a routine : Function GetControlAtom : Pointer that returns @ControlAtom from the controls units.
Then in your DLL's you initialize by passing the ControlAtom from the application Controls units and set this value in the Controls unit of the DLL:
eg
Library ADLL;
Uses
...
forms,
Controls, //Add this here so it initializes unit before we try and change GetControlAtom;
...
procedure CreateForm(App : TApplication;Scr : TScreen;RealControlAtom :
Integer);
Var
P : ^Word;
Begin
If (OldApp = Nil) Then
Begin
OldApp := Application;
OldScr := Screen;
P := GetControlAtom;
OldAtom := P^;
Application := App;
Screen := Scr;
P^ := RealControlAtom;
end;
TForm1.Create(Application.MainForm);
end;
and make sure you clean-up before you unload the dll."