>>>I use the same solution as Nadya: create a file with a reserved name, the executable for each user runs a timer that checks for this special file.
>>
>>The one problem with VFP timer is that it doesn't fire under all circumstances (e.g., if someone has a messagebox open). The free bbTimer, however, always fires regardless of what else is going on, and that's what I use to time "idle" people out of the system or to send shutdown warnings to everyone.
>
>But in "idle" situations I could get my implementation to work reliably with a small array of timers even in heavy activeX scenarios<g> - I know this is at least a half kludge. I was toying with the idea of interrupt like timer usage as some tasks could take a while, but opted to make calling the "CheckForPendingMessage" method a necessary ingredient in such tasks, as not all code in that project took kindly to have other code switched in between. Could you elaborate a bit more on your approach for interupting currently heavy working methods ?
>
>curious
>
>thomas

Thomas,

It's pretty simple, really (unless I misunderstood your question <g>). bbTimer runs regardless of what else is going on, so it is a perfect VFP add-on.

The way I detect idle users is have the timer reset on every keystroke or mouse movement. Yeah, I know, sounds like this sure should bog down the user interface, but since bbTimer is written in C++ and evidently highly optimized, it really doesn't slow anything down whatsoever. So, if nothing happens on the mouse or the keyboard for a pre-set -time (which can be set in each user's security profile), the program rolls back any open transactions for that user and makes a note about the event with as much detail as possible about the open transaction(s) to an event -table so that when the kicked-out user comes back he/she gets a note about the previously aborted session. To make this work reliably, you of course have to have clearly defined transaction boundaries, so that partially committed transactions won't creep into your database.

I handle "global" messaging through a trigger file -- when the timer "sees" a global message file on a shared location, it pops up a message, whatever is in the file. For this functionality I run a separate bbTimer (you can have up to 5 timers running at once), so that the file checking is done in 30 second intervals or so in order to avoid system slow-down caused by too-frequent file checking.