Sorry Richard, I must correct my answer,
When system modal MESSAGEBOX is displayed. (Not application modal!) I saw it sometimes in the past when I used them. I use today only "normal, common" MESSAGEBOX-es.

bb

>Hi Richard,
>
>the most important thing, when you implement my cpptimer, that is not fired, when a MESSAGEBOX is displayed and _AutoYield is FALSE.
>I also suggest you to check my bbScheduler.
>
>bb
>
>>Craig
>>
>>You're right, to call the Task Scheduler and manipulate its innards and back to VFPs innards via _VFP is a huge job even in C++ according to my MSDN CDs, plus it depends on what version of Windows is present. I have no experience with the WSH. Isn't that for writing viruses?
>>
>>I kinda like cpptimer, it looks like it is designed to be OK in the background for a few hours and it could pop up a VFP dialog form for me on top of whatever the user is doing then regardless of what that is, although it is in-process. I try to restrict VFP timers to being enabled for only short intervals and only when the forms they live within are active. Thats the snag with VFP timer here, relying on it to fire, even if it is created off-screen or in code. The user will come to rely on whatever I give him and then, what if he is out-to-lunch and left a modal form or a Messagebox up... right now there is a nice button and he has to press it to run the batch which works, y'know.
>>
>>In case the user is away, I'd plan to use a VFP timer in the dialog form I pop up to auto-close it, and then carry out the default batch action. There are no conditions I can see which will prevent the batch completing but that is obviously the next set of concerns if I move away from that button he presses.
>>
>>So it looks like cpptimer... but before I change the app design, which ain't broke at present, I am wondering if anyone out there has experience using cpptimer in the VFP process space... comments anyone?
>>
>>Cheers
>>
>>Dick