[Lazarus] nonlcl basic issue: is codetools LCL dependent?

[Michael Schnell]

On 06/26/2014 02:52 PM, Mattias Gaertner wrote:
> On Thu, 26 Jun 2014 14:06:15 +0200
> Michael Schnell <mschnell at 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