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: > 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 > > 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 > [email protected] > http://www.lazarus.freepascal.org/mailman/listinfo/lazarus _______________________________________________ Lazarus mailing list [email protected] http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
