[Lazarus] Form in DLL

[Mark Morgan Lloyd]

Michael Schnell wrote:
> On 05/03/2012 10:22 AM, Mark Morgan Lloyd wrote:
>>
>> So using the LCL, is it possible to e.g. put the code associated with 
>> a right-button menu in a DLL, and have it interact with e.g. a SynEdit 
>> on the main form?
> I do believe this is possible, but I am sure that nobody has tried this, 
> yet and there of course will be lots of issues to handle.
> 
> The LCL (i.e. the GUI-related functions) is not reentrant: it can't be 
> used by multiple threads. As it is instantiated by by the programs the 
> main thread in the startup code of an "Application", it only can be used 
> by the main thread, (A DLL does not have a "main thread" by default.)
> 
> This means (besides other thread- and external-widget-set- issues) that 
> there are static variables in memory that are (and need to be) preserved 
> between calls to functions in the LCL. Same are not (and need not be) 
> protected against concurrent calls from multiple threads.
> 
> The DLL has it's own static memory, that is why all the static variables 
> of the LCL instance in the DLL are independent of those in the main 
> program. This it is "dual entry" (or in fact completely independent as 
> the code also is duplicated) regarding two different threads.
> 
> Moreover when (with it's own thread) instantiating this copy of the LCL 
> TApplication, it on it's own attaches to the OS Widget Set and thus I 
> _believe_ the Widget Set handles it as if it would be a completely 
> different program. In fact the OS widget set _could_ find out that this 
> call is done by a program that already did attach and create a main 
> Window and act appropriately (either by creating a somehow depending 
> sub-main window or somehow unexpectedly so that the intended function 
> can't be accomplished. But I don't see why it even should do so.
> 
> Good luck !

OK, but if the DLL was specially written, i.e. we're not talking about 
an arbitrary mix of programs and techniques, and if it specifically did 
not encapsulate an explicit thread, and possibly if it could only be 
called from a single app, what then? Am I correct in believing that the 
major issue would be that the DLL had its own memory manager and 
globals, so the issues would boil down to manipulating strings and 
objects (e.g. the text in an editor)?

I'm way too low on the learning curve to be stupid enough to try this, 
but I was musing on whether a collaborative app could detect that part 
of itself had been updated in SVN, and recompile the relevant bits on 
the fly.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]