[Lazarus] RE : Forms in DLL

[Juan Sánchez]

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/ff1da32f/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dllgui.zip
Type: application/zip
Size: 8066 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20110818/ff1da32f/attachment-0003.zip>