>There is a guarantee! If you pass a timeout to EvtGetEvent, you are
>guarateed to get some event on or before the timeout passes. If no other
>events are generated, a nilEvent will be created for you when the timer
>expires.
This is a good point to keep in mind when you set up your nilEvent 'loop'.
You are only guaranteed an event every x cycles if you set EvtGetEvent, not
just nilEvent. If your app requires a nilEvent every X seconds, be sure to
pass a value to EvtGetEvent that is a multiple of your required interval. I
would recommend increasing the rate by at least a factor of 2. The more you
need a guaranteed nilEvent interval, the more you should increase the rate.
This will help insure you get at least one nilEvent when you need it. Less
critical routines could decrease the rate (like updating the time onscreen).
Also note that there is a trade off - power consumption. The more the
processor is active, the more power it draws. When there is nothing for the
processor to do, it slows down to conserve battery life.
-----Original Message-----
From: Bob Ebert <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Wednesday, May 26, 1999 8:25 PM
Subject: Re: simple animation...
>At 2:15 PM -0700 5/26/99, Dan Rowley wrote:
>> I think the "company line" is that nilEvents can come at any time and
>>without warning - they are generated by the OS for various internal
purposes
>>and the timing/frequency is not guaranteed.
>
>There is a guarantee! If you pass a timeout to EvtGetEvent, you are
>guarateed to get some event on or before the timeout passes. If no other
>events are generated, a nilEvent will be created for you when the timer
>expires.
>
>I think the problem is misreading the guarantee to suppose that no other
>nilEvent can be returned before your timeout. That's not part of the deal.
>
>Basically, passing a timeout to EvtGetEvent puts a cap on how long you will
>have to wait. It does not promise that nothing will happen sooner.
>
>Said another way, the conceptual error is in interpreting the nilEvent as
>"nothing happened" -- that's wrong. nilEvent just means there's no other
>type of event that would be appropriate for what did happen. (Usually what
>happened is a timer expired.)
>
> --Bob
>
>
>
>
