Indeed, there is an error in my last message. There is at least 1 queue in the LCL:
TApplication.FAsyncCall: TAsyncCallQueues; And it is pooled by the main application loop. I took a quick look and I didn't find any other queues in TApplication. > But IMHO (other than Windows) X11 and friends do not provide a relevant > "queue" > (aka store in this meaning) but here the queue > (s) is (are) done in pascal code and are "attached" to X11 / Widget Set > functions, > that do callbacks to push events into this queue. Not true, X11 provides a queue for it's own events, see the file: lcl/interfaces/customdrawn/customdrawnobject_x11.inc In the method TCDWidgetSet.AppRun There are no queues there, only a loop to interact with the queue which is located inside X11. X11 does not send direct events. Direct events are sent by Cocoa and also by Android. I don't know if you can stick non-X11 events into that queue, but this hability by itself is not what defines something as a queue or not. > LCL only sees the incoming events and (other than with Windows) can't (or in > fact does not) issue events towards a potential > external queue, what LCL sees is a "not queuing functionality", and thus > needs to provide the event queue(s) itself. I think it works just the same if you implement a queue ourself and pool it mixed in the main loop alternating 1 pool from the backend library and 1 pool from your own queue or if you use the pool of the backend library to store your extra messages. But if there is no interaction with the backend queue at all, but you only get direct events, then things get problematic. I think that one solution would be creating a dedicated timer and use it to queue our internal pool. -- Felipe Monteiro de Carvalho -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
