[Lazarus] Seeking to resolve LCL in DLL problems

[Marco van de Voort]

On Fri, Aug 29, 2008 at 08:55:56AM +0100, Duncan Parsons wrote:

(please turn off the html stuff)

> (i)   Library is loaded, either statically or dynamically<br />
> (ii)  DLL has an exported function 'SetHostApplication(HostApp:TApplication):TApplication;' before the host app can use a form, it must call something like DLLApp:=SetHostApplication(Application); and inside the dll the application object passed should be stored (in a global or whatever is appropriate), and its own Application object should be returned. The host and the dll now both know about each other.<br />
> (iii) After calling SetHostApplication, the received DLLApp is registered into an internal list in TApplication - let's call it fChildApps - using a procedure RegisterChildApp(DLLApp);...<br />
> (iv)  In the Host's message-loop it iterates fChildApps calling a procedure to attempt to process the current message [if it's keyboard or mouse related]. If it is handled, the host proceeds to the next message, if not it handles it itself. At the end of the loop, a call should be made to each of the fChildApps.ProcessMessages which calls the relevant Widgetset.AppProcessMessages.<br />
> (v)   When a dll is done, if dynamically unloaded, a call should be made to UnRegisterChildApp.

> Hmmm - looks complicated!

And that is the easy part. Because what happens if you deallocate an object
in the mainprogram that is allocated in the lib using a different
memmanager?

or if you do

if x is ty then

when X was allocated in the lib, and ty is from context of the main program. ?

See http://wiki.freepascal.org/packages

So in short, any interaction that trancends the most simplistic definition of C api
is not possible between mainprogram and DLL.
 
> Right - who thinks what? :-)

That you used packages on Delphi, and never understood what they are about
;-)