[Lazarus] RE : Forms in DLL

[Michael Schnell]

On 08/15/2011 09:14 PM, Marcos Douglas wrote:
> What about memory leaks. Have you tested?
+1

Thanks for providing your results, Juan.



Some more background:

(AFAIK:)

A normal Lazarus/FPC (and Delphi) created SO (shared object)  ( = 
Windows DLL, Linux .so, Mac ???, ...???) instantiates its own 
independent memory manager. This is perfectly fine, as it does not know 
in what language the calling program is done and what memory manager 
same uses.

The Plus is that it just works, the Minus is that the interface between 
the program and the SO always needs to be "flat" (just using simple C 
compatible types, no Objects no Pascal Strings etc.)

The SO is not supposed to do anything on it's own but is just a 
"library" of functions that can be called

Thus such a SO is not supposed to provide any kind of GUI, neither 
reusing the GUI of the main program nor creating its own GUI binding.

As a result e.g. TTimer will not work (or at least is not supposed to 
work).

A SO can use threads to implement "free running" activities. AFAIK, you 
can use TThread instances for this, but any normal (portable, 
LCL-defined) communication with the main Thread (such as 
TThread.Synchronize and Application.QueueAsyncCall) is not allowed.



Now it does make sense to use Pascal SOs from Pascal programs (e.g. for 
creating a "plug in" system).

Here it is highly desirable to use a non-flat interface, communicating 
objects and Pascal stings. This in fact is possible (I did test it with 
Delphi but AFAIK something similar is provided for Lazarus/FPC as well) 
by using a memory manager in the SO that hooks into the main program's 
memory manager.


Now in the end a SO-designer might want to provide a GUI for his SO. 
Here in theory two alternatives are possible (1) plugging into the GUI 
of the main program and (2) do a completely independent GUI.

For (1) is seems obvious that the main program needs to be done in 
Lazarus/FPC as well and a common memory manager needs to be used. (thus 
aiming to a very tight integration).

For (2) the main program does not need to be done in Lazarus/FPC and it 
is not necessary (but possible) to use a common memory manager (thus 
aiming to a rather self-contained SO). IMHO, to make  this decently 
work, the SO needs it's own independent "main thread" and do a GUI 
binding (aka TApplication instance) for same. With that normal GUI work 
and things like TTimer, TThread.Synchronize and 
Application.QueueAsyncCall can work (completely internally in the DLL). 
How to do a notification of events generated in the DLL onto the main 
program (and vice versa) is an additional question. It should be 
achieved e.g.by Application.QueueAsyncCall using the other site's 
TApplication instance in case the main project in fact is done by 
Lazarus and by some kind of "callback" in case of the main program done 
somehow else.


Conclusion:

It would be great, if Lazarus would provide a kind of "SO-Application" 
project prototype that allows for all this in a decently reliable and 
verified and portable way.

The user should be allowed to select  if (s)he want to use

(a) a common memory manager or not ("Yes" forces that the main program 
is done in Lazarus, too) and
(b) no, a shared, or an independent GUI ("shared" forces a common memory 
manager)

for the SO.

Of course some support for the main program for providing the 
appropriate hooks for the SO needs to be necessary.

have fun :-) ,
-Michael