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]
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
