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

[Michael Schnell]

On 06/27/2014 12:24 PM, Michael Schnell wrote:
>
> Unfortunately this is even true if you do TThread.Queue with a fake 
> thread pointer, as it internally checks using GetCurrentThread. 
In fact the first  parameter (Thread) in the class procedure 
TThread.Queue is just use to mark the event, so that it can be removed 
by the procedure TThread.RemoveQueuedEvents(aThread: TThread;...

Anyway, for me, the lacking full compatibly with the other Widget Types' 
"Application.QueuAsyncCall" in case this function is called in the main 
thread will not make me do a completely different (i.e 
double-Queue-based) design for the TTimers in this NoGUI Widget Type.

IMHO a decent way would be to remove the feature from TThread.Queue that 
a simple call is done when used in the Main thread.

If Course I would also happily use a different TThread class function 
instead of Queue, if provided if the fpc team decides that TThread.Queue 
really needs this Delphi compatible quirk (while I can't see any use of 
calling TThread.Queue in the main thread, and even here would not have a 
dangerous incompatibility it the call is delayed).

-Michael