On 06/26/2014 02:52 PM, Mattias Gaertner wrote:
On Thu, 26 Jun 2014 14:06:15 +0200
Michael Schnell <mschn...@lumino.de> wrote:
[...]
Of course I do know this.
Make up your mind. Either I'm "Not true at all" or I wrote something
right.
"Not true" was, that my implementation of Application.QueuAsyncCall
using TThread.Queue would not perform the calls in the main thread.
(This in fact already does work perfectly.)
But maybe it really is not perfectly compatible, as,
_when_called_in_the_main_thread_, TThread.Queue perhaps does a direct
call instead of a queued schedule, which might not be true with
Application.QueueAsyncCall. I need to take a look at this.
If your main thread does not call Application.ProcessMessages, what
does it call to give time to the async calls?
See the my messages above in this thread:
checksynchronize()
Stating the obvious:
If you implement a LCL function in the nogui widgetset, you have to
implement it compatible. Your goals and opinions are no excuses
for incompatibility.
"Events are executed without the user needing to call
Application.ProcessMessages" is how all "decent" LCL WidgetTypes work
(but supposedly not NoGUI). Hence this is perfectly "compatible".
My initial intention was a new WidgetType called "ActiveNoGUI". But
here, I was presented with the suggestion to instead enhance the current
"NoGUI" WidgetType. This might or might not (for compatibility issues)
be desirable.
Of course, my primary goal is compatibility, of course, secondary is low
overhead.
-Michael
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
