Force shutdown

[EzLogic]

I have an app in vfp9 sp2

I have a shutdown method that forces people out of the app if i drop a file in the folder.

it seems to close all the apps perfectly for reports, forms, etc..

the only problem i have is, if a user has a Messagebox() poped up and they never clicked on it.

how do i force the messagebox to cancel/close?



Ali Koumaiha
TeknoSoft Inc.
Michigan

 

[TamarGranor]

You can add a timeout to your Messagebox() call, so that it can't sit there forever.

Tamar

 

[EzLogic]

Thanks Tamar,

I guess, i have to go to each one and add it..

there are tons

is there an easier way?

Ali Koumaiha
TeknoSoft Inc.
Michigan

 

[TamarGranor]

Use Code References to find them all and make them easily accessible.

Tamar

 

[EzLogic]

I use GoFish4

I guess, it's a good practive to add timeout anyway..

I do have them on some, but, not all..

especially the one with "Yes/No" or "Cancel/OK" etc..

Ali Koumaiha
TeknoSoft Inc.
Michigan

 

[Mike Lewis]

I guess, it's a good practive to add timeout anyway..

No. No. No. Adding a timeout to a messagebox is not a good idea, for three reasons.

First, because of some quirk in the system, a messagebox with a timeout opens in its own window on the desktop. It has its own taskbar button, and therefore it is not necessarily on top of your application's main window.

This means that the user can click anywhere in the application's main window and no longer see the messagebox. But the messagebox is still active, so the user thinks the application has hung.

Second reason: When a messagebox with a timeout is active, other timers in the application will be suspended. This could muck up any timer-based processing you are doing.

Third reason: It's poor interface design. A user might start reading the message, only to find it disappear when they are part-way through. This does nothing to make your users feel comfortable with your application.

A better way of getting rid of a messagebox under program control is simply to KEYBOARD an ESC character.

In fact, the problem with a shutdown handler is that there are many situations - not just messageboxes - where a simple QUIT won't work. There are workarounds to all of them. But just adding a timeout to every messagebox is definitely not the way to go.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Mike,

My everyday expereince would say Messageboxes always get displayed on top, globally, no matter what application is active, but I could force it: If your app is not active and creates a messagebox, it displays on top of your application main window, but not on top of all windows.

My idea of the messageboxes always coming on top surely also comes, because I seldom use them to notify a lengthy process has ended, for example, but only use them triggered by user actions, to inform or as safety (OK/Cancel) or for a simple Yes/No question. I tend to introduce checkboxes for the latter.

So your idea of cancelling open messageboxes via ESC is perhaps the best bet and good advice.

Another good advice is to put code into forms QueryUnload Event to handle QUIT in a different way than the normal closing of a form, eg to rollback open transactions and revert changes if saving the current state of the data fails due to broken rules.
The ReleaseType property is 2, if the QueryUnload of a form is triggered by the QUIT command.

And by Mikes advice, before issuing QUIT you should check whether a Messagebox is open and escape it via ESC. I wonder though, if it's ok to simply do Keyboard("{ESC}") in any case, or if you need to SET ESCAPE ON or OFF to not get an interruption dialog, if no messagebox is active, I think that only would occur in IDE mode anyway, but am not sure.

Lot's of quirks you need to think about at automatic shutdown. Actually, several years ago in the german community the agreement was QUIT, too and in regard of modal states we also identified messageboxes as a bummer and their timeout as a solution. You can set the timeout quite large as a compromise of being noted and not giving an endless modal state.

If you really need your users to note a message and let it be modal, you could also roll your own message form and set it modal, but let it react via QueryUnload to a shutdown situation.

Bye, Olaf.

 

[Mike Lewis]

Good points, Olaf.

Some of the other complications of a forced shutdown:

- A modal form might be open (QUIT won't necessarily close it).

- There might be unsaved data in a buffer.

- A transaction might be in progress.

- An error-handler might be in progress.

- An open form might have code in its QueryUnload, Unload or Quit which interrupts the closedown (such as prompting the user if they really want to close the form).

- The ON SHUTDOWN might have code that interrupts the closedown.

My solution to all these is as follows (but I know some people won't agree with this):

1. Rollback all transactions in all data sessions.

2. Revert all buffers.

3. Execute this code:

DECLARE Integer ExitProcess IN WIN32API 
ExitProcess()

That code will kill the application stone dead, regardless of what is happening in the application at the time.

I have successfully used this method in several applications.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Mike Lewis]

By the way, for more information about a messagebox with a timeout parameters, see this discussion: thread184-1249874

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Thanks Mike,

ExitProcess also came to mind, and it's okay after you cared for the things you do previous to that.

Adressing your complications:

- A modal form might be open (QUIT won't necessarily close it).
- There might be unsaved data in a buffer.
- A transaction might be in progress.
Adding appropriate QueryUnload code can take care of that, especially individually handling buffered changes to either store or revert, whatever is more appropriate in the situation, and you know that better in a concrete form than in a centralised routine

- An open form might have code in its QueryUnload, Unload or Quit which interrupts the closedown (such as prompting the user if they really want to close the form).

Again an appropriate QueryUnload should pay attention to the ReleaseType and in case of a shutdown or quit should never interrupt the closing, but have a default noninteractive way of handling the above mentioned circumstances.

- The ON SHUTDOWN might have code that interrupts the closedown.
I'd suggest using ON SHUTDOWN QUIT, which does trigger the QueryUnload of all forms, thus again the appropriate QueryUnload code does not interrupt the shutdown by a QUIT. At least QUIT should be part of the shutdown code and you should only handle any transactions or buffers of the general datasession not handled by any form, as the forms QueryUnload should handle their own buffers and transactions, if you don't want to break encapsulation rules.

In regard to encapsulation of course in such a situation cetrally reverting all transactions is not really breaking the rule,security and in this case data integrity is more important, but give each form a chance to handle it's own problems itself.

Points remaining are surely the general datasession and an error handler in progress. I wonder what the implication would be, a QUIT should also cancel out of error handling, if it is in progress, shouldn't it? The genreal datasession or any session not handled by a form QueryUnload (eg also Sessions started via the nonvisual Session class) should be handled with a central routine, which makes it hard to decide what to handle previous to QUIT and what to leave to be done by each form on it's own.

And for everything else than forms Destroy should run.

A good advice surely is to program in ways to keep your application in a closable state. Actually buffers are reverted by default, so buffering is a good way to keep your DBFs stable and uncorrupted, even if you QUIT without doing any tidy up code.

Bye, Olaf.

 

[clipper01]

yes , have met the same probs with open dialogs etc

there is an FLL timer file that solves ALL these problems of the native VFP timer just use this , 50 independent timers ,
kicks in when users are waiting for messagebox dialog , old-style gets etc etc

http://www.bbcontrols.com/fll.shtml

something like this at startup , does the important job also of stopping new users jumping in

Exe_path=Sys(5)+ Sys(2003)
If File(exe_path+'\unplug.txt')
=messagebox('User Sessions Barred'+Chr(13)+'Contact System Manager',64,'Anord',5000)
On Shutdown
Clear All
Quit
Else
inittimers(1,100)
setuptimer(1,1000,"closedown()")
* sets up timer #1
gnCountDown=60 && allows you to set the grace time for users to gracefully close if they are at desk
Endif
* start your main app now and it watches for the closedown signal
where closedown looks for existence of file

e.g.

Procedure closedown
If File(exe_path+'\unplug.txt') And Not glQuit
Acti Screen
? "We apologise for any inconvenience ... "
? "Stock System will close down in approximately ..."
glQuit=.T.
Endif

If File(exe_path+'\unplug.txt')
Acti Screen
? Transform(gnCountDown)+' seconds'
gnCountDown=gnCountDown-1
If gnCountDown <1
On Shut
On Error Quit
stoptimer(1)
Keyboard "{ESCAPE}" && to clear any old get fields
Keyboard "{ENTER}" && to clear any messagebox in focus
Clear Events
Keyboard "quit"
Endif
Endif
Endproc

 

[clipper01]

by the way , the above timer file is vintage 1998 !! , FREE and still does the biz on VFP9 , cannot get better than that

 

[Mike Lewis]

Clipper01's code reminded me of another factor: Once you have issued your warning message (to tell users that the application will close in xx minutes), you have to take steps to prevent other users from logging in during that period. (This is the "grace period" that Clipper refers to.)

And here's something else:

You need to allow the administrator (the person who initiated the forced shutdown) to change his mind and cancel the shutdown (during the grace period). But what if the administrator himself came out of the app during the grace period, then tried to go back in to cancel the shutdown, but can't do so because users are barred from logging in at that time? You need to keep track of who initiated the shutdown, and make an exception in his case.

I think you'd agree that it's all a can or worms.

Come to think of it, I once wrote an article for FoxPro Advisor which addressed all these issues, and included a complete "forced shutdown" class to solve them. I wish I could point you to that article, but unfortunately it's gone into the big FoxPro Advisor bit bucket and will never be seen again.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

For the problem of an admin being able to still use the application I used the same solution as for forcing out users: a File. In that case it must be local instead of central, and of course that filename has to remain secret.

It does also make sense to have a seperate tool to lock and unlock the usage of an application.

Bye, Olaf.

 

[clipper01]

interesting that every one happened on some variation of same idea

by "grace" period I meant if say user is in middle of doing some transaction , you dont really want to dump him without warning , so the code writes to the main screen , while he is doing whatver he needs to close off

We apologise for any inconvenience ...
Stock System will close down in approximately ..."
60 seconds
59 sseconds
...
2 seconds
1 seconds

in the meantime , he has time to close gracefully . Other users are barred FOR AS LONG as the signal file is these . The admin can never get into catch-22 , all he has to do is rename the signal file

 

[Mike Lewis]

Yes, that's what I understood by grace period - except that I would prefer to give them ten minutes or more, rather than, say, 60 seconds.

Clipper, I take your point about no Catch-22 if you use a semaphore file. In my own applications, I provide an interface within the app to allow the administrator to start and stop the process - he doesn't know anything about the file (but I suppose he can always delete the file manually if things go completely wrong).

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Koen Piller]

Mike,

"FoxPro Advisor" Forced shutdown article.
Do you have a recall around which year you have written this article? I still have lots of old issues in my library.

Regards,

Jockey(2)

 

[clipper01]

Mike , ditto , got 'em all back to about 2000 , when they started to get interesting , be happy to scan/pdf/share anything/anytime

regards . Sean M

 

[Mike Lewis]

Regarding the FoxPro Advisor article:

I don't have any way of searching for it. I would have to manually parse the pile of around 120 copies. I'll do that as soon as I can grab some time.

Sean, thanks for your generous offer of scanning / sharing the article. Unfortunately, is is still the copyright of Advisor Publications, and I can't say if they would give permission for that. If it was up to me, I'd be only to happy to share the article (for what it's worth).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[dbMark]

Mike Lewis' Foxpro Advisor article on forced shutdown was January 2007.