[Lazarus] LCL and DLLs, initializing the widget set safely?

[Marco Alvarado]

I converted a demo of a Netscape plug-in from Delphi to Lazarus. I
just found two bugs, one was solved by placing
Application.Initialize() right before dynamically creating the form
(I'm not using lfm), and another related to CreateParented(). With
those bugs solved, now I have a perfectly running Netscape plugin
created with Lazarus and LCL 0.9.28. I tested the DLL on Firefox 3.5.
The only files I kept from Delphi are the resource files, since those
bring the MIME-type and other info the browser requires in the DLL,
and Lazarus doesn't support custom version info fields at the moment
(hope in the future). The DLL's size is 1483KB.

I think that LCL just misses the application initialization in DLL...
at which moment it must be called is something I don't know. Maybe
placing an initialization flag and calling it once before creating
components might be a workaround.

Lazarus rules!!

-Marco


2009/12/9 Mattias Gaertner <nc-gaertnma at netcologne.de>:
> On Wed, 9 Dec 2009 09:33:32 +0100
> "Gerard N/A" <gerardusmercator at gmail.com> wrote:
>
>> On Tue, Dec 8, 2009 at 11:39 PM, Marco Alvarado <cronodragon at gmail.com> wrote:
>> > I'm really happy to inform that I solved the bug, and now I have a
>> > working version of LCL 0.9.28.2 in DLL. It seems the fix might not be
>> > difficult for someone who understands the LCL's internals. I'll
>> > explain what I did hoping someone could work on it.
>> >
>>
>> Am I wrong or this cannot be really fixed unless a Delphi-like package
>> system is implemented?
>
> Delphi like packages makes many things easier like calling the
> initialization/finalization sections in the right order and only once.
> You can emulate this.
> The most important thing is sharing the VMTs and global variables.
> This can not be emulated.
> The shared VMTs and global variables are needed, when you
> want to use a LCL form of a DLL in a LCL application.
>
> I didn't try, but it should be possible to put an LCL application into
> a dynamic lib on all platforms and accessing it only via pointers.
> And with various hacks it is possible to share more.
>
> The main problem is, that the guys knowing the compiler and linker
> issues, thinks that the disadvantages of packages outweighs the
> advantages, so it is not worth implementing.