[Customdrawn] LazClock exercise

[Michael Schnell]

On 04/02/2012 03:03 PM, Felipe Monteiro de Carvalho wrote:
> people should avoid depending on implementation details.
That should be documented, at least :)

> The only way to make it guaranteed would be to make it run the even on
> another thread and make the timer completely threaded
Throwing the TTimer event in a Thread is not at all what anybody would 
want. This would ask for huge complexity in the user code.

What _might_ be desirable is to have is a property in TTimer, that can 
be set to one of those settings:
  - default (do what is usually best, thus no change to the current 
definition of TTimer)
  - don't schedule an event before the last one has been handled by the 
main Thread (loose as many ticks as necessary to provide lowest main 
thread overhead) (e.g. most useful for on a GUI displaying a varying 
embedded state)
  - schedule all events in natural order (so they inter-mix with all 
other events, the event is a perfectly normal Main Thread event, no 
ticks are lost)
  - schedule all collected events as soon as possible (only one event of 
this TTimer is scheduled normally, the next ones only increment a 
counter. When the event is scheduled the handler is called as often as 
the counter indicates. Thus the appropriate count of ticks is performed 
as fast as possible. (e.g. most useful with applications that rely on 
best Timer performance)

-Michael