[Lazarus] RE : Forms in DLL

[Juan Sánchez]

Tested on Mac. It seems to work fine.

El 18 de agosto de 2011 10:23, Juan Sánchez <aldeacity at gmail.com> escribió:

> Well,
>
>     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.
>
>     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.
>
>     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.
>     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.
>
>     I hope it will be a useful idea.
>
> Regards,
>
> Juan.
>
> 2011/8/17 Michael Schnell <mschnell at lumino.de>
>
>> 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
>>
>>
>> --
>> ______________________________**_________________
>> Lazarus mailing list
>> Lazarus at lists.lazarus.**freepascal.org<Lazarus at lists.lazarus.freepascal.org>
>> http://lists.lazarus.**freepascal.org/mailman/**listinfo/lazarus<http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20110818/00fd7ddf/attachment-0003.html>