<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Vinzent Hoefler wrote:
<blockquote cite="mid200611080714.35028.JeLlyFish.software@gmx.net"
type="cite">
<pre wrap="">On Tuesday 07 November 2006 17:10, Michael Schnell wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Of course, because the common concept of a timer is as asynchronous
as in "multi-threaded" or even "interrupt".
</pre>
</blockquote>
<pre wrap="">That is not true ! (See my other post.)
</pre>
</blockquote>
<pre wrap=""><!---->
Well, a timer is, even though the Delphi implementation of a so-called
TTimer object might not.
</pre>
</blockquote>
A TTimer by definition is what a Delphi TTimer is (and of course the
Lazarus implementation is done according these lines). <br>
<br>
Of course you can do a TVinzentTimer that does a callback in a thread.
In Linux this even is a very useful thing in some projects, as (other
than in Windows) creating threads is very cheap here. The user needs to
be aware of what he is doing and that hes required to protect resources
from mutual access and that it's not possible to uses LCL functions
(many of which are not thread save) in a TVinzentTimer event.<br>
<br>
<blockquote cite="mid200611080714.35028.JeLlyFish.software@gmx.net"
type="cite">
<pre wrap="">
Basically a timer starts, later then it expires an that expiration
creates an event (in the old days we called that interrupt). This event
is no way synchronous to the code currently running.
</pre>
</blockquote>
As said, his is useful in some projects, but by far more difficult to
use than the Delphi-like TTimer.<br>
<blockquote cite="mid200611080714.35028.JeLlyFish.software@gmx.net"
type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">Timer events are queued in a line (message-queue) with all
"hardware"/"GUI" events.
</pre>
</blockquote>
<pre wrap=""><!---->
Ok. So this would do nothing more than synchronize the asynchronous
event of an expired timer to the main thread. </pre>
</blockquote>
Exactly<br>
<blockquote cite="mid200611080714.35028.JeLlyFish.software@gmx.net"
type="cite">
<pre wrap="">Of course, the "time" of
execution of the code associated with the expiration is now determined
by the time the message queue is handled the next time.
</pre>
</blockquote>
You are absolutely right. (Delphi like) TTimer can't be used for
"realtime" stuff. Here you need threads and taking the pain to care
about mutual access problems is required and sensible.<br>
<blockquote cite="mid200611080714.35028.JeLlyFish.software@gmx.net"
type="cite">
<pre wrap="">
So why don't use CheckSynchronized for this?
</pre>
</blockquote>
What is CheckSynchronized ? Can this help queuing multiple (e.g. Timer)
events so that they get executed in order of their occurrence in a non
preempted way ? <br>
<br>
To enable TTimer to work in the Delphi/Lazarus-like way, of course the
main program needs to call an RTL function that never returns and _all_
actions need to be events that are queued and handled by callbacks in
the sequence of their occurrence. Application.ProcessMessages needs to
be in place to allow a less important event granting precedence to more
important ones.<br>
<br>
-Michael <br>
</body>
</html>