Modifying the CS_NOCLOSE style does affect all windows of the class, just not necessarily in an immediately noticeable way


In a discussion of how not to disable the Close button, Rick C claims that changing the style does not affect windows that are already created.

Actually, it does. You can't see it, but the effect is there.

Take our scratch program and make these changes:

DWORD CALLBACK NewThread(void *)
{
  CreateWindow(
      TEXT("Scratch"),
      TEXT("Scratch 2"),
      WS_VISIBLE | WS_OVERLAPPEDWINDOW,
      CW_USEDEFAULT, CW_USEDEFAULT,
      CW_USEDEFAULT, CW_USEDEFAULT,
      NULL, NULL, g_hinst, 0);

  MSG msg;
  while (GetMessage(&msg, NULL, 0, 0)) {
    TranslateMessage(&msg);
    DispatchMessage(&msg);
  }

  return 0;
}

void OnChar(HWND hwnd, TCHAR ch, int cRepeat)
{
  DWORD id;

  switch (ch) {
  case ' ':
    SetClassLong(hwnd, GCL_STYLE,
                 GetClassLong(hwnd, GCL_STYLE) ^ CS_NOCLOSE);
    break;

  case '+':
    CloseHandle(CreateThread(0, 0, NewThread, 0, 0, &id));
    break;
  }
}

  HANDLE_MSG(hwnd, WM_CHAR, OnChar);

Run this program, hit the + to open another window, then hit the space bar to set the CS_NOCLOSE style.

The window that is passed to Set­Class­Long updates its close button, but the other window does not.

But this is purely a visual artifact. If you try to click on the close button of either window, it will not work.

So don't change the CS_NO­CLOSE style thinking that it affects just your window. It actually affects all windows of the class. But it may not look that way at a casual glance.

Comments (21)
  1. Joshua says:

    And here we have another case of using a global solution to solve a local problem.

  2. Andrew says:

    iOS devices have a physical "close button" that takes you back to the main screen, giving the appearance of having closed the program, and the OS and its APIs/UI guidelines were designed such that the user needn't care whether the application has actually exited or is running in the background.  It could be argued that the Windows key in Windows 8 behaves the same way, but Windows users are probably more likely than iOS users to expect to be in control of starting/closing applications, simply because it's Windows.

  3. Entegy says:

    @Anon, all Metro apps have a close button, or have a method of closing the app.

  4. Joshua25640735 says:

    Joshua (name box missing)

    [I don't think iOS has a Close button either. Or are you saying Apple got it wrong, too? -Raymond]

    I think they got it wrong. Android will auto-kill apps that don't have notifications registered if you go back to the main screen which is usually better. All apps that I've seen that need to stay alive need a rooted phone anyway. In that case, loading a process manager app is not out of the question.

  5. Nick says:

    @Anon: "Metro" apps in Windows: Drag the window from the top to the bottom and hold it there for several seconds until it flips over. That will terminate it (if you drag it back up after it has flipped over, it will restart from scratch).

    Windows Phone: Press the "Back" button from the app while the "Back Stack" is empty to terminate the app, unless the app has overridden this functionality.

  6. Having never used the Modern UI, does it by any chance close applications in a similar way to the way iOS and Android do?

  7. @Chris Crowther: It does.  You can close apps by dragging them from the top of the screen down (either with the mouse or your finger).  Windows 8.1 adds a title bar with an explicit close button and shows Modern apps on the taskbar, so you can also close them from there.

  8. @Anon: Are you talking about Windows Phone?  Windows Phone 7 doesn't have a built-in way to force-close apps, but the Lumia extensions did add task-killing.  Windows Phone 8 has task-killing built-in: just long-press on the back button to bring up the task switcher, then press the X button over the application thumbnail.  In Windows proper, dragging the app down or clicking the close button should terminate the application.  I'm not at home to verify that, though.

  9. David H says:

    @Nick

    Wow. That is both pretty cool and horribly undiscoverable. I wish I had learned that a while ago.

  10. alegr1 says:

    iOS" double click of Home button will bring a scrolling list of all "running" applications (as screenshots), and you can quickly switch to any. Sliding a screenshot up will "kill" an app - lose all run time state.

  11. Cesar says:

    @David H: "horribly undiscoverable" is IMO the main problem with Metro. For instance, how do you turn off the computer? The answer is: move the mouse to a specific corner of the screen, select one option whose name implies it's only for something else, and there you'll find the "power off" button.

    Getting back on topic, users like the Close button both because it's discoverable and because it's in the same place (and does the same thing) on every window. Without the Close button, the user has to scan your window/dialog for something which closes it, and hope that it closes the window and does nothing more.

  12. AndyCadley says:

    @Anon: They don't really "consume resources" in any meaningful way, they get no CPU time and if Windows needs the RAM for anything it will simply kill the process without notification. It's only kept in a suspended state like that in order to make switching back a much quicker process (why bother reloading and restarting an app you didn't really need to).

    Alas this is one of the most misunderstood parts of the app model and the enduring belief by users that they can manage system resources better than the system itself means we'll most likely lose the benefits of this model going forward.

  13. Kaylyn says:

    @Cesar: Isn't there a small tutorial when you login for the first time that gives a short demo of the common touch actions in Windows 8? I don't think it covers 'closing' an app, but it's not any less discoverable than the 'swipe up from task switcher' that iOS has.

    @AndyCadley: I agree that memory management is something that users shouldn't be worried about. Closing apps for me (on any OS), is more about clearing up context than freeing up resources. Windows 8 is very aggressive at curtailing resource usage of apps. You get a message from the OS that you will suspend and you have X time to do what you need to do before Windows autosuspends you (there are limited exceptions, of course). The sort of cargo cult 'knowledge' that most users have is why something like Memory Clean has been one of the highest rated apps on the Mac App Store for years.

  14. Anon says:

    From the linked post: "Usability research indicates that users really don't like it when you disable the Close button"

    @Raymond

    Maybe you could forward that to the "Modern UI" development team (and any mobile HW/SW devs you know). I have a lot of pet peeves with ModernUI and Mobile design, many of which have a root cause of "There's no way to *actually* close an app"

    [I don't think iOS has a Close button either. Or are you saying Apple got it wrong, too? -Raymond]
  15. Muzer_ says:

    A suggestion for how to implement the "encouraging developers" point; perhaps manually work out the worst offenders for this by trawling through terrible apps, then when they next update their Android IDE give them a modified version that closes itself when it's left idle for a while (without saving anything), and pops up a message box stating "See how you like it!". Google probably have everything required to perform this...

  16. Anon says:

    @Raymond

    Yes, I meant "all mobile", so 'Modern', iOS, and Android alike.

    @Everyone Else

    There's a lot of "well press the back button." That's not actually closing an app unless the app specifically implements the back button that way. The app will still be sitting in the background, consuming resources, until the OS runs out of resources and starts killing background apps. That's pretty easy to see with *any* OS monitoring tool, built-in or otherwise.

  17. Skyborne says:

    @Cesar: You should install Windows 8.1 Update 1 (I think it was) that adds Power options directly on the Start screen.

    @Raymond: iOS has close buttons.  They are not omnipresent, but they have always been there.  iOS 7+'s slide-to-close in the task switcher, and earlier versions' long-press in the task switcher to show the controls.  And Home *always* takes you... Home.  Apps do not get to say, "Never close me" nor "Ignore the home button a while."

    Although I find it ironic that Apple's approach is to auto-close things when "low on resources," and also put in so few resources that it has to auto-close things an awful lot.

  18. Anon says:

    @AndyCadley

    The Expected and Actual behaviours are two different things.

    The Expected behaviour is that those resources will be freed 'instantly' (sub-100ms), thus ensuring that no application will be unable to start because another application is consuming resources.

    The *ACTUAL* behaviour is that you will frequently have applications that stall on startup (or stall during operation -- especially noticeable with audio or video) because it takes a substantial amount of time (often up to seconds) to free up those resources.

  19. Muzer_ says:

    @AndyCadley: That may be true for an ideal world. But we don't live in an ideal world. As far as OSes with this model go, I am most familiar with Android (so maybe not all of these apply to Windows 8, but most of them seem pretty general). There, you have problems of:

    * Apps not saving their state properly and so when the cleanup does happen, you lose data (in the form of state data, which might include filled out forms, etc.). Quite common on Android.

    * Apps being broken and getting into some broken state that require closing. Either requires opening a load of apps at random just to fill up the RAM, or rebooting

    * Apps being broken and getting stuck in a state where they have the "don't close me" flag set (and before you complain, some apps do legitimately need to be kept open, eg an IRC client or ssh client).

    For all these reasons, Android gave in on not providing a way to close apps, and now does provide one. Unfortunately this doesn't fix the first problem listed, but there's not much you can do about that besides either a draconian iOS-style screening, or encouraging developers to consider this more, or just allowing the user to disable the "auto close" feature, which might indeed be a step too far.

  20. Gabe says:

    I don't have a lot of direct experience with these sorts of devices, but I have heard many anecdotes about peoples' phones getting really hot in their pockets or the batteries dying due to apps using resources the user doesn't want them to use. In the past, the only way to solve the problem was to do a reboot of the device because there was no way to tell an app to close, just a way to remove it from the display.

    However, letting the OS determine when to shut down an app is only useful when the app is just sitting there waiting for input. If the app is doing something in the background (like using your bandwidth talking to some server, or using your battery listening to GPS satellites, or just sitting there waiting for the right time to annoy you with a distracting message) then the user should be in control of when the app closes.

  21. Rick C says:

    I did actually put the word "seem" as in "does not _seem_ to" affect other windows.  Just wanted to point that out.

Comments are closed.

Skip to main content