>
>
> Dave Lippincott wrote:
>>
>> The UI does generate the nilEvent message periodically.
>
> how periodically? i thought it only came at the end of the timeout of
> EvtGetEvent. my app seems to be sending it normally (at the end of
> EvtGetEvent) AND whenever i interact with my app (pushing buttons that
> cause a field to be rewritten, hitting the applications silk screen,
> etc...). anything that sends an event, of whatever type, seems to also
> send a nilEvent. the docs dont mention this, not that i have seen at
> least...
>
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.
>> I got around this
>> by checking the tick counts before handling the nilEvent. If the > count is
>> greater than some pre-defined timing interval, than I act on the > nilEvent.
>> Otherwise I ignore it.
>>
>
> sorry if i seem stupid here, but i dont quite understand what you are
> saying. how do i check the tick counts before handling nilEvents? do
> you have a short bit of code to illustrate this?
>
The trick is to decide the minimum amount of time that must pass before
you respond to the nilEvent, and to ignore any nilEvents that happen before
that time has elapsed. So, every time you get a nilEvent, check your tick
counter against a value you stored last time around, and if enough time has
elapsed save this new tick value and do your thing. Otherwise, ignore the
nilEvent.
--
Dan Rowley
Innovative Computer Solutions
Developers of fine software for Newton, Windows CE, Palm Computing Platform,
Windows, and MacOS
