Override the processing of the Close All Windows taskbar command

Question

I have a WPF application with several unrelated Windows, i.e. There is always one MainWindow, and possibly many others without an owner. If these windows are grouped in the taskbar, the windows will provide the "Close All Windows" action in the context menu of the taskbar. If you click on it, each window of my application will receive a separate command command in the order in which I cannot control.

Problem: Some of my windows may request before closing if pending changes can be undone. This is annoying and confusing if there are a lot of them.

I want: if MainWindow is asked to close, I want to request once if this is normal. If so, all windows should close silently, otherwise stay open. But my MainWindow is not the first to handle the closing procedure.

I already figured out that I probably need to check the Message Message Loop line of my MainWindow for some WM_SYSCOMMAND with wparam SC_CLOSE. (see How can I distinguish between “Close all windows” and “Close” individual windows in MFC with Windows 7?)

But how can I evaluate this before closing for any other window? ComponentDispatcher.ThreadPreprocessMessage in my mainwindow arrives too late, it starts after some other window has started the closing procedure.

This question has something to do with this: Odd closing form when using taskbar Close all Windows

Answer 1

Personally, I would just leave things as they are. I see how a few tips for saving / reverting changes can be annoying, but it doesn't seem confusing to me. And while annoying, this seems like a minor annoyance, and frankly, it can teach the user not to use the "Close all windows" option when they left a bunch of these windows open. It is said & hellip;

As the question has already pointed out, there is no built-in way to distinguish "Close all windows" from the usual "Close window" command. The system simply sends messages to windows in sequence.

In MFC (i.e. in the context of another question) you can call AfxGetCurrentMessage() to get information about what the SC_CLOSE message actually caused. If it was user input that was transferred to the close command, some user input (keyboard, mouse, etc.) will be entered as the current message. Otherwise, you will see only WM_SYSCOMMAND .

But you cannot apply the same approach in WPF because WPF does not provide the GetCurrentMessage() method or its equivalent (as far as I know). The only access to window messages that you receive is to override the Control.WndProc() method, and by the time you receive the close command, the last window message will always be SC_CLOSE .

It seems to me that it is best to use the WndProc() override to track incoming messages so that you can reset the flag when incoming messages do not close.

Then, when you get the close command and display the user's prompt, you can check this flag. If true, you can ignore the prompt and just use whatever was last selected. Since you clear the flag when messages arrive without closing the command, the first close command received always displays a prompt.

Another alternative would be to proactively close all other windows. Here you still have an invitation for some type of "applies to all other windows" for the user, but instead of just relying on the flag, you can explicitly close all other windows.

None of them are perfect in terms of user interface. The main problem is that the user is trying to close only one window. In the first approach, the user will see the "apply to all other windows" option in the prompt, even if there are no other windows to close. The second approach is a little more self-consistent, but adds a function that you may or may not want: the user can close all windows in the program at any time when they close only one window.

None of these actions are standard user behavior in the Windows user interface. That is, trying to save the user some annoyance (and confusion, although, as I said, I don’t see this part taking place), you introduce something that can be potentially confusing for the user.

Given that it includes additional work coding and can simply exchange one annoying / confusing result for another, the best solution might simply not be to try to solve the problem at all.