0

This is an educational app for Win10/11. It hosts 2 app windows at all times the app is running (even if minimized).

The app auto-saves the user's work (into XML files) during the app-Quit sequence. To Quit, the user hits the Close button on either window. That triggers the auto-save.

But, the Win OS provides a GUI command down in the Task Bar, a right-click menu tied to the app icon -- Close All Windows.

How does Windows signal to the app that the User wants to close all of the app's windows? It seems that it doesn't bother, and just kills the app.

Are there hooks in Java/Swing to pick off this form of user-Quit from the TaskBar?

Closely related, there are 3 other Win OS actions that indirectly kill an app...Shut Down / Restart / Log Off User. Same question, does Java have an "OS listener" that can pick off the impending forced Quit?

pbierre
  • 276
  • 1
  • 8
  • Yes, [setQuitHandler](https://docs.oracle.com/en/java/javase/18/docs/api/java.desktop/java/awt/Desktop.html#setQuitHandler(java.awt.desktop.QuitHandler)). – VGR Sep 06 '22 at 23:45

2 Answers2

0

The Runtime.getRuntime().addShutdownHook(new Thread() } method solves the OS-linkage for Windows Task Bar "Close All Windows". In your app's launch sequence, you want to wait until everything has launched successfully, then call something like this method as the last step in the launch sequence:

'''

private static void enableShutdownHookToSaveUserPrefsAndWork() {
    //this code implants the task of recording Prefs & User Work files during the shutdown sequence.
    //Covers the cases where the OS shuts down this app: 
    // tested: 1) Win "Close All Windows", 2) MacOS menu-Quit, 3) MacOS dock-icon Quit
    Runtime.getRuntime().addShutdownHook(new Thread() {

        @Override
        public void run() {
            
            inShutdownSequence = true;
            commenceQuitSequence(); // saves user work; disposes 
            
        }
    });
}
// When this thread suspends, the DestroyJavaVM thread relinquishes all app memory, quits and hands back control to the OS.

'''

pbierre
  • 276
  • 1
  • 8
0

How did I stumble into this problem?

I had long ago implemented the ShutdownHook, and it worked fine on the MacOS, the test being if the User's most recent work is saved at Quit-time, using the Dock-icon's "Quit" feature.

On Windows10, it was a different story when using the TaskBar "Close All Windows" option....that snuffed the app without saving the user's work (even though the work is saved by the User closing either app window).

I finally figure this out. As one of those "default" decisions made going into Beta release, it was assumed that the Windows app should have a Java Console (text output) window to help with bug reporting. The plan was to quash the Console window for V1.0 release.

There is no way to wire up the Console window to have its close button tell the app to Quit...closing the Console blindly halts the JVM.

It also turns out that the TaskBar-icon "Close All Windows" feature closes the Console window first. Whoops!

Now that I've modified the Win launcher to launch the JVM with "javaw.exe" instead of "java.exe", there is no console window, and the TaskBar-icon "Close All Windows" command passes control to the JVM --> myApp windows to close themselves, and the User's work is auto-saved. This solves the OP.

The more "forceful" OS-triggered halts of the app (User Log Off, Restart, Shutdown, Task Manager kill-process) seem to call the Java ShutdownHook, but then preempt it during the file writes...resulting in an empty file being written to disk! Based on my testing, these processes do WORSE than just killing the JVM. They corrupt the file write in progress. BEWARE

pbierre
  • 276
  • 1
  • 8