Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2008-08

Seeking to resolve LCL in DLL problems

3 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Marco van de Voort
to Duncan Parsons

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

(please turn off the html stuff)

Show quoted text 7 lines
(i)&nbsp;&nbsp; Library is loaded, either statically or dynamically<br /> (ii)&nbsp; 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)&nbsp; 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)&nbsp;&nbsp; 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 ;-)

Reply by email

Duncan Parsons
to Marco van de Voort

OK, just returning to this after having to detour for a while...

Marco, thx for your reply (& sarcasm!). I'm well aware of packages, as it goes :-)

Looking further at what I want to do, I realised that the my previous description isn't actually what I'm after... What I'm looking to have is a dll which can be used as a plugin in any type of relevant app. It happens that I'm developing VST audio plugins, but it could as well be property pages for shell extensions or db managers - what is required is a method of exporting a form and housing it in a host supplied form.

I've been reviewing http://bugs.freepascal.org/view.php?id=7181 (& its relatives) and found that if the ShowModal; in the example is replaced with a simple Show; and another mechanism employed for freeing the form, all works well :) It doesn't matter that there are two copies of the LCL, they don't _need_ to have any great interaction or share a mem manager... I have changed the Delphi version so that it doesn't alter the Application.Handle and ensured it's not compiling with packages, just to do a like for build, so both host and dll have their own rtl built-in for both Delphi and Lazarus. And you know what - both work perfectly! LazHost can load and show forms from Delphi and Laz dlls; Delphi host can do the same. I would build a C++ host as well, but can't quite get the energy for it just now...

Only issue I have now is getting a form to change parent to a given window handle (whether win32 or carbon [my primary targets]). I can easily change a form's parent, and maintain operation, but that relies on a TWinControl... I could do with an LCL equivalent of CreateParented, but that may have strange widgetset implications. Any ideas on that would be most welcome! Other than that I'll keep hacking :)

Duncan

Marco van de Voort wrote 21 lines
On Fri, Aug 29, 2008 at 08:55:56AM +0100, Duncan Parsons wrote: > (i) Library is loaded, either statically or dynamically > (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. > (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);... > (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

ChildApps.ProcessMessages

Show quoted text 31 lines
> which calls the relevant Widgetset.AppProcessMessages. > (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 ;-) _______________________________________________ Lazarus mailing list http://www.lazarus.freepascal.org/mailman/listinfo/lazarus

Reply by email