[Lazarus] RE : Forms in DLL

Michael Schnell mschnell at lumino.de
Wed Aug 17 17:27:31 CEST 2011


On 08/17/2011 04:06 PM, Marco van de Voort wrote:
> What was your testprogram?
I never did any tests on SOs with Lazarus. I did some tests with Delphi 
ages ago. So I would need to retest anything it it's important.
> So yes, it solves the ansistring problem, no it doesn't solve 
> the.synchronize problem.
This is obvious and this is what I wanted to say, as well. I there is 
only one main thread and only one copy of of "the LCL" (in fact the 
Application instance) there is only one event queue and thus only the 
main thread of the main program will be notified ("synchronized") The 
only chance to have the SO work on its on is to have another totally 
independent TApplication instance (and thus the static memory of the 
LCL) and its own mainthread.

Juan seems to have found out that the SO in fact automatically creates 
it's own Application instance (I can't comment if that is true). But as 
the SO seemingly in fact creates it's own static memory for the LCL, it 
should be possible to have it run as it's own independent application 
with it's own main thread and its own binding to the GUI framework. I 
don't see the major difference between this and two independent 
executables only here the same MMU memory mapping is used (and the main 
program is provided with some pointers to procedures defined in the SO).
> The only safe solution is to avoid any duplicated state, RTL or LCL.
This would create a single application with a common GUI (and only one 
event queue). I feel that the other option to create a completely 
independent SO with its own main thread and completely independent 
LCL/Application should be easier to do. Of course here the mutual 
notification of upcoming events is an "interesting" task.

> But that is not a matter of project, but of engineering, and a bit of
> engineering that is waiting for sb to implement it.
>
> It is not a matter of project, since a project in lazarus can only
> instrument the FPC compiler and RTL, and for this to be resolve, massive
> changes to those are needed first.
Of course this is not viable to introduce any changes in the current 
code base. Only an Add-on might be considered.

I'm very interested in seeing if Juan comes up with something useful and 
would like to test it.

-Michael




More information about the Lazarus mailing list