Tested on Mac. It seems to work fine. El 18 de agosto de 2011 10:23, Juan Sánchez <[email protected]> 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 <[email protected]> > >> 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 >> [email protected].**freepascal.org<[email protected]> >> http://lists.lazarus.**freepascal.org/mailman/**listinfo/lazarus<http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus> >> > >
-- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
