On 06/07/2011 02:41 PM, Michael Van Canneyt wrote:
I want to see if we can integrate it in a TCustomApplication
descendent (TEventApplication), of which the LCL TApplication can be
made a descendent. If so, then the NOGUI widget type will
automatically have an event loop and timer.
Sounds nice !
I vote for a kind of "general" implementation:
An TEventQueue class defined in a central location so that it can be
used by any Widget Type (AKA "interface" implementation, AKA
TApplication class derived from TCustomApplication, I don't know how
this is related to the "Application Type" that is selectable when
creating a "New" project.)
The TEventQueue class should provide the necessary hooks that
theoretically would allow all (non-Windows) Widget Type implementation
to be re-implemented using them. Maybe a partly virtual
TCustomEventQueue class might be sensible to define the hooks and the
basic functionality, so that the final TEventQueue derived from same
again is implemented in the Widget Type code. With this I suppose that
any (future) Widget Type implementation would be able to reuse the
active code. With that maintenance would be perfect and optimizing the
central active EventQueue code would make much sense. (AFAIK there are
several more or less optimized implementations of self-sizing FiFOs
around that could be considered to be tested against any initial
implementation.)
Maybe in fact a future TApplication could be based on the
TEventApplication you are planning (instead of directly on
TCustomApplication as it seems to be done right now). If this is the
plan, again I suggest that TEventApplication is done in a way that
theoretically all (non-Windows) Widget Type implementation could be
re-implemented as a sibling of same, dumping the active event-queue code
done in the individual Widget Type implementation.
Well, based on your various descriptions and questions, I think it can
be used to create this widget type.
Sounds good :).
... This is exactly what I want to establish.
Please let me know if I can be helpful in any way.
For testing I already have a quite generally usable testing project.
Suggestions:
I think, it would be good enough to implement
TEventApplication.QueueAsnycCall() as a central entry to the queue.
Other mechanisms (such as TThread.Synchronize(), PostMessage(), and
PostThreadMessage() ) can just use it. This would facilitate the code
maintenance.
As you are a very active core member of the community, maybe you can
improve the FPC RTL, too. Here, TThread should be enhanced by the
TThread.Queue() procedure. Same is implemented in Delphi since years
(but not decently documented in the Delphi help of all versions).
TThread.Queue() would be nothing but a call to QueueAsnycCall with one
argument.
Thanks again,
-Michael
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
