[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