<p>Well,</p><p>    of course, this is very complicate theme. Reading all mails I can see that is a hard way. But, I've designed a basic prototype to see if it can be useful.</p><p>    Based on the fact that every dll has its own application system, this prototipe includes a unit with a class that all forms in a dll can use for some protocols needed to all run wel. I found that there was an important problem. When a main form calls a dll function to create a formfrom dll, dll "subsystem" runs ok but there are several problems when user wants to include modal forms from dll forms. These modal forms include message box. In this cases, main form is independent and never goes to disabled and if user closes this main form application crashes.</p>
<p>    To resolve this problem, I've designed this prototype. I've tested it on Win32 only both in Win32 native an Win32 GTK and it runs ok. </p><div>    As my English is not rich enough :-) I think that it's better to attach source to let everybody test it. All functions are commented and also functions unit to be included in all dll units is commented.</div>
<div><br>    I hope it will be a useful idea.</div><p>Regards,</p><p>Juan.<br><br></p><div class="gmail_quote">2011/8/17 Michael Schnell <span dir="ltr"><<a href="mailto:mschnell@lumino.de">mschnell@lumino.de</a>></span><br>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" class="gmail_quote">On 08/17/2011 04:06 PM, Marco van de Voort wrote:<br>

<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" class="gmail_quote">
What was your testprogram?<br>
</blockquote>
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.<div class="im"><br>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" class="gmail_quote">
So yes, it solves the ansistring problem, no it doesn't solve the.synchronize problem.<br>
</blockquote></div>
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.<br>

<br>
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).<div class="im">
<br>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" class="gmail_quote">
The only safe solution is to avoid any duplicated state, RTL or LCL.<br>
</blockquote></div>
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.<div class="im">
<br>
<br>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;" class="gmail_quote">
But that is not a matter of project, but of engineering, and a bit of<br>
engineering that is waiting for sb to implement it.<br>
<br>
It is not a matter of project, since a project in lazarus can only<br>
instrument the FPC compiler and RTL, and for this to be resolve, massive<br>
changes to those are needed first.<br>
</blockquote></div>
Of course this is not viable to introduce any changes in the current code base. Only an Add-on might be considered.<br>
<br>
I'm very interested in seeing if Juan comes up with something useful and would like to test it.<br><font color="#888888">
<br>
-Michael</font><div><div></div><div class="h5"><br>
<br>
--<br>
______________________________<u></u>_________________<br>
Lazarus mailing list<br>
<a href="mailto:Lazarus@lists.lazarus.freepascal.org" target="_blank">Lazarus@lists.lazarus.<u></u>freepascal.org</a><br>
<a href="http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus" target="_blank">http://lists.lazarus.<u></u>freepascal.org/mailman/<u></u>listinfo/lazarus</a><br>
</div></div></blockquote></div><br>