Rif.: delay Windows shutdown request

[Wolfgang]

Hi,

How do I properly delay a Windows shutdown request in order to clean up things first?

At present, in my time consuming callback (TCC) I repeatedly query a Cancel button to allow for a manual abort. If cancel==true, I skip some routines. I also have some ProcessDrawEvents to update the UI. At the end of this callback, I check for a shutdown flag.

While this TCC is running, the main callback (MC) may receive the EVENT_END_TASK. Right now, in MC I set the global cancel==true and I also set another global flag, shutdown==true, such that TCC, after finishing its (possibly cancelled) task, is aware to quit, or not to quit.

In MC, I have to swallow the END_TASK event in order to keep the program running until TCC has finished. Then I would like to honor the shutdown request. How could it be implemented?

Sounds simple, but I got my wires crossed ...

Thanks!

Wolfgang

[Kobi_K]

It's just am idea i don't really know if it's possible :

maybe changing the kill value ?

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\WaitToKillServiceTimeout

[Kobi_K]

One more thing is , i know there is a function RequestAdditionalTime() mabye it can help.....

[RobertoBozzolo]

Wolfgang,

responding to a system shutdown is not a trivial task: here is an old thread in which I was asking more or less a similar question: you may find bilalD aanswers useful.

A good source of reference of course is MSDN: here the master page for reference on shutdown process. As said in the thread I linked previously, responding FALSE to WM_QUERYENDSESSION message should postpone system shutdown for a while (5 secs) giving you enough time to close you app correctly.

The symmetric part of the question (your app launching a shutdown) can be handled by "Shutdown" command native in Win XP: this command can be instructed to issue a logoff/shutdown/restart of the system with several additional parameters. Open a dos window and type "Shutdown /?" for reference on this command.

[Wolfgang]

Toda and thanks for the hints, I'll have a closer look.

My initial idea was not to extend the shutdown time by a fixed time of few milliseconds (which might not be sufficient in all cases), but to re-issue the shutdown request after TCC has finished. If I arrive at a solution, I'll let you know 🙂

[RobertoBozzolo]

In this case AbortSystemShutdown should help you block the process.

[Wolfgang]

Now it's getting a bit confusing - well, Roberto warned me that it's not a trivial task

1) Roberto, I do not want to abort / block system shutdown, only temporarily; this can be accomplished within CVI (i.e. without SDK functions) by swallowing EVENT_END_TASK. All that is needed then is to re-issue the shutdown and for this purpose I will investigate the SDK function ExitWindowsEx

2) EVENT_END_TASK can also be triggered by closing the application via the taskbar: So I thought to issue QuitUserInterface in my maincallback which usually would lead to calling all functions after RunUserInterface in main, i.e. discard menu bars and panels.

If I press a 'Quit' button and call QuitUserInterface, this sequence works, however, if I receive the EVENT_END_TASK, things are different, menu bars etc. are not discarded. In consequence, if a user quits the application via the task bar, there is a memory leak... Is it the intended functionality?

[RobertoBozzolo]

Well, let's share some ideas more.

• Swallowing EVENT_END_TASK seems to me a way of (permanently) blocking a request for shutdown. Am I wrong?
• ExitWindowsEx: good luck! You'll have to fight against windows messaging, rights, privileges... . LaunchExecutable ("shutdown -s -f -t 0"); seems a lot simpler
• Not sure about the taskbar button: please share your experience with us. This will permit all of us to make our applications more robust

[LuisG]

Wolfgang,

The way QuitUserInterface works is by setting an internal flag that notifies the RunUserInterface event loop that it should exit and return from the function.

What you need to know is that when you return from EVENT_END_TASK without swallowing the event, your application is pretty much going to exit immediately. In that case, calling QuitUserInterface is moot, since the RunUserInterface loop is aborted anyway, and your thread is not going to return from RunUserInterface, nor is it going to continue executing the clean-up code that you have after the RunUserInterface call.

If you want to process the EVENT_END_TASK, you'll have to call your clean-up code directly from inside the main callback, instead of calling QuitUserInterface.

Luis