Is it possible to treat 'Shutdown' as an Event?

prabha_friend

Prabhakaran Karuppaih
Local time
Today, 15:18
Joined
Mar 22, 2009
Messages
934
And do programming for the same? You know... Backup the database to Onedrive before going Home. Possible?
 
And do programming for the same? You know... Backup the database to Onedrive before going Home. Possible?

It IS possible to disallow closure of your only , primary, modal Menu form by way of top right X - and require use of your programmed button, under which scenario you can include anything you want to happen at that point.

One thing I generally do there is log who has the db open or closed, last opened, etc.
 
There is no event you can hang your code it but it can easily be done. I use a startup form. It is either a logon or a menu or just a form that doesn't even become visible but just opens your opening form. It doesn't matter. The point is that this form starts the actual application, and you hide this form rather than closing it. Then in the Close event of this form, you can put your backup code or whatever cleanup you want to do. This works because forms close in the inverse order in which they were opened. So, the first form to open is the last form to close.
 
Shutdown is an event at the Windows level but at the Access level there is no explicit code for it and no specific event. What happens is (more or less) like this:

Windows detects a shutdown. Inside Windows there is a task list. Every task gets a notification to start shutting down as Windows steps through the task list one at a time to issue that notification. Because at this point the operating system is still time-sharing/time-slicing, each task has the opportunity to shut itself down in an orderly fashion.

It is up to each process, but the PREFERRED action under Windows is that every process steps through its process-local list of connections and file handles and issues a Close operation, one at a time, until each connection and each file is closed - at which time the process self-terminates. This internal situation has a formal name you can look up - "Process Rundown."

For Access, open reports and forms potentially represent open recordsets - which are connections - and those recordsets, like any OTHER connections, must be closed. (That's what Windows commanded it to do...) Therefore, Access tries to close those open objects - again, one closure at a time using the UNLOAD event, which can be canceled. You CAN intercept the closures if there is a special thing to be done - like an UNDO on a "dirty" bound form before you close it. It IS possible to cancel a form closure in the UNLOAD event, which would leave Access with no way to force the issue since it can't close as long as you cancel the unload attempt. UNLOAD precedes CLOSE. If you don't stop it at UNLOAD, the CLOSE definitely WILL occur.

Blocking the UNLOAD event on a form stops the Rundown from completing, thus leaving Access "hanging." If you DO block the Rundown operation, though, Windows has a second action. If your process doesn't shut down on its own after first notification, Windows steps through the task list a second time and issues a DELETE PROCESS against each task. The internal DELETE PROCESS call is "the hammer" and it means you are about to get nailed. This step cannot be ignored as it is done from the Windows Kernel as user SYSTEM - which has ALL repeat ALL privileges. Anything still open WILL (unequivocally) be closed as-is. If that means that an open connection cannot update a DB file (thus leading to corruption), that is exactly what will happen.

You can use the UNLOAD events to cleanly shut down things, but if Windows is shutting down, you have no choice but to comply. You can do some constructive things to preserve what you've got - but you ARE going to shut down.
 
Or, you can use an AutoExec to open the form instead of making it the opening form.
 
The internal DELETE PROCESS call is "the hammer" and it means you are about to get nailed.
So what you are saying Doc is that Windows askes nicely the first time then not nicely the second time :ROFLMAO:
 
So what you are saying Doc is that Windows askes nicely the first time then not nicely the second time :ROFLMAO:

Absolutely true.

You can actually see this behavior during a shutdown as there will be a list of tasks on screen for which Windows is waiting. I'm not going to swear on a stack of Bibles on this, but I believe that by the time that list is displayed, the tasks that would have voluntarily shut down quickly have already done so. The displayed list is the tasks that have taken the long way around. One by one as they finish their rundown, they will vanish from the screen. Depending on the shutdown and some system parameters and the privilege level of any task holding up the works, you MIGHT be asked for permission to "whack" the hung process. With the Navy-supplied laptops, NO task could hold up a shutdown because of a site policy template that got downloaded each time we connected to the Navy servers. A non-domain system sitting all by itself, not on any network, perhaps could hang in the death throes of a bad shutdown. But the ultimate shutdown comes from remembering this simple fact:

A computer's attention span is no longer than its electrical cord.
 

Users who are viewing this thread

Back
Top Bottom