>>>>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 ?
>
>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.

We built oue Messagebox implementation on the steve black code, so went around that issue<g>. But "our" system could go into some "maintainance" mode synching or (pre) analyzing data on certain user-definable intervals. Vfp timers won't fire there as well, but the question was if it was a good idea to stop such a process at all.

>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.

Similar thiunking here<g>. Thanks for the info.

regards

thomas