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

[Mattias Gaertner]

On Thu, 26 Jun 2014 15:07:22 +0200
Michael Schnell <mschnell at lumino.de> wrote:

>[...]
> 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()

Application.ProcessMessages calls CheckSynchronize and calls the
queued async calls. Under nogui that's all. Other widgetsets process
the widgetsets events as well.

> > 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".

Not true. A LCL program calls Application.Run, which is a loop calling
Application.ProcessMessages. You can create sub loops. A common example
is TForm.ShowModal, which also calls Application.ProcessMessages.
Or you can do your own loop, in which case you have to call it yourself.

If you call CheckSynchronize instead of Application.ProcessMessages you
simply omit the widgetsets and queued async calls.
Why do you think this is a feature?
 
> 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.


Mattias