Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Task scheduler's kill message, which one?
Message
 
À
06/03/2015 13:12:03
Dragan Nedeljkovich (En ligne)
Now officially retired
Zrenjanin, Serbia
Information générale
Forum:
Visual FoxPro
Catégorie:
Installation et configuration
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows Server 2003
Network:
Windows 2008 Server
Database:
MS SQL Server
Application:
Web
Divers
Thread ID:
01616357
Message ID:
01616358
Vues:
45
>I have a little exe which needs to monitor a certain resource. To make sure it's always on, I run it via task scheduler (so far so good, that works), however just in case it may get stuck, I want to recycle it. So I've set the task scheduler to stop the existing instance if it's already running. That doesn't work.
>
>The exe has practically no GUI, save for a toolbar with an exit button, and it sits in infinite Read Events state. The exit button works fine - deletes the objects, executes a Clear Events and the app exits gracefully.
>
>However, the task scheduler doesn't kill it. I've set it to run a new instance every 5 minutes (just for testing) and sure enough, after half an hour I have 5-6 of them stacked up. Now I guess I should bindevent() to something, just don't know what. I've tried _screen's QueryUnload() - doesn't fire (not even when I click the closebox manually). Tried _screeen.hwnd with wm_close, wm_quit and wm_destroy, doesn't fire.
>
>What am I doing wrong?

What about having a little launcher like this:

- Kills all instances of your exe
- Launches a new instance of said exe
- Finishes

Then you schedule this launcher instead of your exe (and this can be a .cmd script, does not need to be an exe, I have one exactly like this)
"The five senses obstruct or deform the apprehension of reality."
Jorge L. Borges?

"Premature optimization is the root of all evil in programming."
Donald Knuth, repeating C. A. R. Hoare

"To die for a religion is easier than to live it absolutely"
Jorge L. Borges
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform