Shutdown isn't called when OS is shutdowning?

Windows
1

Ola Jules,

I suspect that JUCEApplication::shutdown and also JUCEApplication::systemRequestedQuit() are not called when OS is about to shutdown.

I append some code in jucedemo like;

void shutdown()
{
 File test(File::getSpecialLocation(File::userDocumentsDirectory).getFullPathName() + File::separatorString + T("foo.txt");
if(!test.exists()) test.create();
test.appendText("Test");

delete theMainWindow;
theMainWindow = 0;
}

void systemRequestedQuit()
{
 File test(File::getSpecialLocation(File::userDocumentsDirectory).getFullPathName() + File::separatorString + T("bar.txt");
if(!test.exists()) test.create();
test.appendText("Test");

quit();
}

I quitted OS while keeping running this jucedemo app.
Then I started OS, but I could not find foo and bar text files in my document dir.

I’m using Juce rev. 689 on Windows XP SP2.

Even in this case, I want to call shutdown func… Is it possible?

2

Interesting question… Looking at the code, maybe try this tweak, in juce_win32_Windowing.cpp:

case WM_QUIT: if (JUCEApplication::getInstance() != 0) JUCEApplication::getInstance()->systemRequestedQuit(); return 0;

Previously it bypassed the virtual methods and went straight to quit(), but thinking about it, this is probably better.

3

WM_QUIT was not sent to my app when OS was shutting down.
I found WM_QUERYENDSESSION and WM_ENDSESSION were sent to all the windows instead of WM_QUIT at that time.

Here’s the inserted code in juce_win32_Windowing.cpp:

case WM_QUERYENDSESSION:
 if(JUCEApplication::getInstance() != 0)
  JUCEApplication::getInstance()->systemRequestedQuit();
return TRUE;

This works fine to call shutdown func.

Thank you!

4

And I hope you commit such kind of code in the trunk…

5

Ok, I didn’t know about that message. Maybe it should also give the app a chance to bail out of the shutdown?

case WM_QUERYENDSESSION: if (JUCEApplication::getInstance() != 0) { JUCEApplication::getInstance()->systemRequestedQuit(); return MessageManager::getInstance()->hasStopMessageBeenSent(); } return TRUE;

6

Ah… yes. It would be better!

7

Will this change works when the app is killed using the task manager.

8

No, it’s nothing to do with killing an individual app, it’s when the whole OS is shutting down.

9

So what can be done in such a circumstances.

10

Surely if the user is resorting to the task manager to kill an app, the app should really be taking the hint and just get the hell out of the way! Trying to be clever at that point sounds like a recipe for disaster IMHO.

11

User Might not intentionally killed the app. He just wanted to kill one app and by mistake i would have killed the other one. So we can give some provision to clean up right!!!

12

If you close an app via Task Manager, the OS will try to close it normally first. If the app won’t respond to the normal close message, then it is forcibly killed. That is, by definition, an abnormal situation that means your app is already not functioning correctly.

13

I have been having issues with the WM_QUERYENDSESSION handler. When I end up my user session on windows, the JUCEApplication::shutdown() is called, but it gets killed before completing (and this is very painful to debug since I have to close/reopen the session to trigger this). After some tracing I found that the calls to ::DestroyWindow that are done after WM_QUERYENDSESSION has been received are just killing the application (and they are numerous during the shutdown since I destroy the main application window, the tooltip window etc). I’m pretty sure there is a logical explanation, but I’m far from figuring it !

I ended up toggling a global flag when WM_ENDSESSION is received, and when this flag is toggled, the call to DestroyWindow in destroyWindowCallback() is just skipped. Of course, this is extremely ugly, but at least my shutdown completes…

14

Tricky.
Are all the destroywindows being called actually during the WM_QUERYENDSESSION event, or by events that arrive after it?

15

I think they are called after, because when you call JUCEApplication::systemRequestedQuit it is asynchronous, isn’t it ? Anyway, I also tried to call directly JUCEApplication::getInstance()->shutdown() when receiving the ENDSESSION event, but it did not change anything. However I know almost nothing about windows message queues etc so I really don’t know how all those events are supposed to fire