Remote Shutdown VFP 7

[RFanslow]

I have been approached by a client, looking for ways to shut down a vfp executable which is sitting at a menu
it never fails that several users leave the app open and files are open which need to be closed for maintenance.

while I don't believe there is a timer function on a main menu, does anyone have a work around as users are located in 3 states using a wan/lan to a main directory on the server.

Any Idea's...

Fanz

 

[RFanslow]

Dave
Good to hear from you... Hope all is well

I'll review these comments made late yesterday, but i have come to the conclusion that the menu is the issue....

I am looking for a simple way to shut down the app if left open after hours... right now i must login to the server and kill connections, not really a preferred method or ideally the best use of time, when wanting to make upgrade or data changes in a 24/7 operation

I know this has been don over and over, but recall this as a menu within a form or even when a form was open.... this is some very old upgraded code from 2.6 .. 5.0... 6.0... 7.0 all tables get opened on the onset, hence the problem with unattended apps being opened


being it's an .exe you cant really see if the object is still there or even running as it is not writing to the screen once the menu state is open

running it on a debug mode it works perfectly fine, as the class is hidden, writing to the screen every 60 seconds

Fanz

 

[Olaf Doschke]

So, why not make the timer independent of the form. It would then start the form instead of showing it in case of a shutdown. AFAIK a timer ON A FORM may have the problem, what we've shown and warned about is, that even an independent timer object would have it's event run and yet not quit the application.

You could put the timer as a sub object of _SCREEN, eg.

Bye, Olaf.

 

[Mike Lewis]

I tested ExitProcess() with the Messagebox() and you can't put it last to work. You have to do it before QUIT.

The whole point of ExitProcess() is that you do it instead of the QUIT. As soon as you execute it, the application stops stone dead.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Well, while that's true you can try a QUIT and in parallel start something doing Exitprocess (from inside) or pskill or other things (from outside). If QUIT can quit, the other part will only not find the process anymore, but that doesn't hurt and in the normal case you still can exit graceful. That's my idea.

Bye, Olaf.

 

[Mike Lewis]

Olaf, I don't quite understand that. I mean, how would you know at which point the QUIT didn't work?

To stay with my earlier example: You issue a QUIT while a data-entry form is open. That causes the form's QueryUnload to fire. The QueryUnload prompts the user to save or cancel any unsaved edits. The user has gone home, so the application is waiting indefinitely for the user's response.

In that scenario, how would you know that the QUIT had failed? At what point would you do the ExitProcess()?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

>how would you know at which point the QUIT didn't work?
You don't, and you don't need to know. You do both things in parallel.

You start a cmd file via RUN /N and QUIT.
In the cmd file you use timeout to wait a little and give QUIT a chance, then pskill.exe with the process id you pass into the cmd script, to kill the process

OR you start another timner doing ExiProcess after a timeout.

OR...

If QUIT succeeds the process is gone before pskill or Exitprocess or anything can kill it, if QUIT fails, the secondary exit strategy kicks in.

Simplest case, in VFP you do

lcProcessID = STR(_vfp.processid)
RUN /N quit.cnd &lcProcessID
QUIT

The quit.cmd script looks like this

timeout /t 5
pskill %1

Untested

Bye, Olaf.

 

[Mike Lewis]

OK, I get it (I think). At first glance, it looks quite complicated, but it might work.

What's the advantage over doing a simple ExitProcess() (after making the various safeguards I mentioned earlier)?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

>What's the advantage over doing a simple ExitProcess() (after making the various safeguards I mentioned earlier)?
Well, you can do a cleanup routine, I prefer the event triggered by QUIT, which means every object cleans up itself, in the end.

And a simple QUIT triggers that. If it works, everything's fine, if not the priority is to kill the process.

But you can't have the normal (for me) clean up of each single object by calling a cleanup routine and finishing with ExitProcess.

So in shot QUIT is my way of a clean exit and preferred without any centralised routine to rollback all transactions and close all forms. If you Quit, every form should clean up after itself and clen up it's datasession etc.

Bye, Olaf.