| Date: | June 4, 2010 / year-entry #165 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20100604-00/?p=13803 |
| Comments: | 23 |
| Summary: | A customer was having problems with the small icon that appears in the upper left corner of the caption: In my program, I need to enable and disable the Close button programmatically, since the program sometimes goes into a state where I don't want the user to close it. I do this by removing the... |
A customer was having problems with the small icon that appears in the upper left corner of the caption:
Okay, the first problem is that you want to disable the Close button. Usability research indicates that users really don't like it when you disable the Close button. It makes them feel trapped and uncomfortable. This is the reason why standard Windows wizards don't provide a way for you to disable the Close button. The user should always have a way out. Imagine showing a dialog box saying "By clicking OK, you agree to the following terms," and not having any way for the user to say, "No, thanks." You should leave the Close button enabled, and if the user clicks it at a bad time, you can say, "Okay, I heard you, but I'm right in the middle of something, but once that's done, I'll close." Okay, but suppose you're in one of those cases where, really, you need to disable the Close button. You've read the guidelines, you understand why they're there, but you believe that you are an exceptional case.
If you never want the Close button enabled, then you can just
specify the
To disable the Close button in the caption dynamically,
you enable and disable the
void DisableCloseButton(HWND hwnd)
{
EnableMenuItem(GetSystemMenu(hwnd, FALSE), SC_CLOSE,
MF_BYCOMMAND | MF_DISABLED | MF_GRAYED);
}
void EnableCloseButton(HWND hwnd)
{
EnableMenuItem(GetSystemMenu(hwnd, FALSE), SC_CLOSE,
MF_BYCOMMAND | MF_ENABLED);
}
The other two caption buttons are controlled by window styles:
void DisableMinimizeButton(HWND hwnd)
{
SetWindowLong(hwnd, GWL_STYLE,
GetWindowLong(hwnd, GWL_STYLE) & ~WS_MINIMIZEBOX);
}
void EnableMinimizeButton(HWND hwnd)
{
SetWindowLong(hwnd, GWL_STYLE,
GetWindowLong(hwnd, GWL_STYLE) | WS_MINIMIZEBOX);
}
void DisableMaximizeButton(HWND hwnd)
{
SetWindowLong(hwnd, GWL_STYLE,
GetWindowLong(hwnd, GWL_STYLE) & ~WS_MAXIMIZEBOX);
}
void EnableMaximizeButton(HWND hwnd)
{
SetWindowLong(hwnd, GWL_STYLE,
GetWindowLong(hwnd, GWL_STYLE) | WS_MAXIMIZEBOX);
}
Why is the close button managed differently from the minimize and maximize buttons? History.
Originally, the window caption had only two buttons in the upper
right corner, the minimize and maximize buttons,
and they were controlled with a window style.
Windows 95 added the Close button,
but then there was the question of knowing when to enable and disable it.
But wait, we already know when to enable and disable it:
The application told us when it enabled and disabled the
Exercise: What's wrong with these alternative functions for enabling and disabling the Close button:
// code in italics is wrong
void DisableCloseButton(HWND hwnd)
{
SetClassLong(hwnd, GCL_STYLE,
GetClassLong(hwnd, GCL_STYLE) | CS_NOCLOSE);
}
void EnableCloseButton(HWND hwnd)
{
SetClassLong(hwnd, GCL_STYLE,
GetClassLong(hwnd, GCL_STYLE) & ~CS_NOCLOSE);
}
|
Comments (23)
Comments are closed. |
With the alternative functions, it would also affect other windows of the same window class, even if they're in a different state? MSDN also states "it is possible to change the background color for a class by using SetClassLong, but this change does not immediately repaint all windows belonging to the class.", as an example of undesireable behaviour, so something similar may apply in this case, resulting in the close button appearing enabled/disabled until the NC area is redrawn?
Those function will enable/disable the close button for all the windows created from that window class from now, not the close button of the "hwnd" window.
The problem is that the wrong code doesn't disable the menu item on the system menu.
I should add, likewise, it doesn't work if the window class was registered initially with CS_NOCLOSE
In my time as a developer I have had a few situations where the people asking me to write the software wanted to diable the close button for whatever reason. In all cases I managed to get them to rethink the idea by doing simple things by changing the workflow, putting extra thought into what is being done or saving temporary operation data.
A lot of developers seem to forget about the end user just to make things easier for themselves. But in this situation it can end up a lot worse, because if the user feels really trapped when the window won't close then they can just end the process and that will definitely get the operation to end up in a very bad situation.
I have a list of actions which would make me not use an application if a program does. Trying to stop the application from closing is actually on that list. So if this application, with the close disabling, came out onto the market then I wouldn't be using it.
Fortunately, these tricks don't disable WM_CLOSE (or it's SC_CLOSE?) sent by Task Manager on Application->End Task button click. And the ultimate kill by TerminateProcess (Task Manager->End Process).
Doesn't MSI installer (which is a component of Windows) disable close button on the last step of uninstall operations? I believe this and similar cases are really legitimate uses of the functionality.
@Alexandre I think an application can block WM_CLOSE, but if the developer wasn't expecting it (since there's no close button) they may forget to handle it, and the DefWndProc closes the window.
@sukru I assume because closing is considered equivalent to cancel and that is done to underscore that you can't cancel at that point. Still weird though.
I don't know much about window classes but my best guess is Shaka's… the flag is only checked on window creation.
Interestingly, under 64-bit Win7, it does NOT seem to affect other windows of the same class, whether already open or not.
What Raymond was probably referring to, however, is that it disables the close button, but NOT the Close item on the system menu.
There is one very illegimitate reason for disabling the close button and the remedy is "net stop wuauserv". I heart deleting it's registry keys even allows installing additional updates without rebooting first ;-)
Yo close button, I'm real happy for you and imma let you finish, but OK is the greatest button of all time… of all time.
Or you can just drag the you-want-to-reboot window to the bottom right and reboot when it suits you.
As to why it wants to reboot, Raymond discussed that before: ‘Windows can but won't’ technet.microsoft.com/…/2008.11.windowsconfidential.aspx
On the other hand, there was an article on Slashdot some time ago about one of those old systems (think twenty years ago or something), that could achieve close to 100% uptime and get security right. I thought I bookmarked it since it was interesting from a historical perspective, but I can't find it any more.
I'd have to check but I'd think that the actual answer is slightly different from Shaka's: I suspect that SetClassLong would affect *all* windows of that class, even those already existing, and not just new ones. I don't care enough to write code to test this, but my reasoning is that the change is supposed to happen right then, so it would make sense for it to affect all windows, and this sentence from MSDN "Calling SetClassLong with the GCL_WNDPROC index creates a subclass of the window class that affects all windows subsequently created with the class" implies that by specifically calling out GCL_WNDPROC "affects all windows *subsequently* created" which implies that other values don't.
I had to disable the close button and WM_CLOSE once thanks to a third party component (not to name names here). My response to the newly created usability problem was to create a big button on the window labeled "Cancel".
As for the 100% uptime and getting security right, that is achieved on some Linux systems by patching the running kernel with binary patches.
"I heart deleting it's registry keys even allows installing additional updates without rebooting first ;-)"
Wow, and people wonder why the "required yearly re-installation of Windows" myth perpetuates. My Windows is unstable, even when I fix the registry manually!
I wonder if the EnableMenuItem method will work for minimize and maximize, too. After all, these buttons also have siblings in the Alt-space menu.
I ran into this very problem a few hours ago, when I wanted to try VC2010++Express, and its setup insisted it needed to reboot; the Close button was disabled, as was the "Restart Later" button. I of course followed the path predicted by Crescens2K…
VS2010 installs .NET Framework 4.0. I'd say that warrants an unconditional reboot.
@Marquess
Why would installation of a new component warrant an unconditional reboot?
Because it's a rather tightly integrated component.
BeOS was close, if you're flexible in your definition of "uptime." You could, for example, kill, patch, and restart the networking subsystem without rebooting the kernel or anything else on the system. (Or any other subsystem on the machine.)
But then again, if you have to kill networking, you're probably not going to count that as "uptime" except as a technicality.
>I'd say that warrants an unconditional reboot.
Nothing short of the wrath of Zeus warrants an unconditional reboot.
Even updating the OS doesn't force a reboot. If your application tries a stunt like that, it had better be *the cure for cancer* or if I ever meet you I will hit you in the face with a brick.
There are mainframe systems that pretty much have the uptime crown. So much so that a reboot is a Very Serious Deal and can take hours or days, even. Literally 5 9's uptime.
Hell, the OS won't stop even if hardware fails – the OS merely keeps on trucking avoiding the failed CPU, RAM, disk or other component. And naturally, all hardware is hot swappable.