How your taskbar auto-hide settings can keep getting overwritten


A customer reported that they were observing that some users were finding their taskbar set to auto-hide even though the standard configuration in the company is for the auto-hide feature to be disabled. Going into Taskbar Properties shows Auto-hide the taskbar checked. None of the users had changed their setting to auto-hide manually, so the question was raised to the Windows team, "Are there any cases where Explorer will set the auto-hide setting on its own?"

Explorer does not set the auto-hide checkbox on its own. Now, the taskbar does auto-hide even when the setting is unchecked if it detects that the application is trying to go full-screen, say, in order to show a slide show or play World of Warcraft. But that doesn't check the check-box.

Further investigation revealed that the check-box was being checked programmatically by one of the programs that the company used. And it wasn't custom software but a commercial product which targets the corporate market.

The customer reported back that the problem was sporadic. They could not reproduce it consistently.

My guess is that the application in question was trying to enable auto-hide temporarily for whatever reason. At program startup, it checks the current auto-hide setting, and if it's off, it programmatically turns auto-hide on.

previousState = IsAutoHideTaskbarEnabled();
SetAutoHideTaskbar(true);

When the program exits, it restores the original setting.

SetAutoHideTaskbar(previousState);

This is a highly fragile solution for several reasons: What if the application crashes before it can restore the setting?

What if two people did this?

  1. Initially, auto-hide is off.
  2. Program A remembers that auto-hide was off and sets it on.
  3. Program B remembers that auto-hide was on and sets it on.
  4. Program A exits and restores auto-hide to off.

Oops, now we have a problem: Program B wants auto-hide on, but Program A just turned it off.

  1. Program B exits and restores auto-hide to on.

Oops, the auto-hide setting was left in the 'on' state after everybody thought they had restored it.

As a special case of What if two people did this?, the Program B could be the Taskbar Properties page itself. While your program is running, the user goes to Taskbar Properties and sees that the checkbox is set incorrectly. Maybe they go in and "fix it", and now Program A is running with a visible taskbar.

What if the application tries to restore the state after Explorer has already saved its settings? When the user logs off, all processes are told to clean up their toys and to go bed. In response to WM_ENDSESSION, Explorer saves out its settings and calls it a night. What if this happens before the application programmatically unchecks the box? Explorer says, "Okay, I unchecked the box." But Explorer already saved out its settings; these updated settings aren't going to be saved again.

This is what happens when you expose a global setting programmatically. People see the setting and think that twiddling it will solve their problem instead of looking for a local solution to their local problem, in this case creating a fullscreen window that covers the taskbar.

Comments (23)
  1. Joshua says:

    I've had to do a similar thing (not this exact thing) before. Yes, the what if is immediately obvious to me.

  2. Cesar says:

    A program I worked on changed the global menu colors so their popup menu colors matched the rest of the application color scheme. The solution I found to fix it was owner-draw menus; there seems to be no other way of changing popup menu colors locally. But implementing owner-draw popup menus on the high-level language used by the application is hard (luckly, I am a low-level programmer, so low-level stuff like that does not scare me as much).

    I can see why the original programmer went with the global solution (probably copy-pasted from some programming forum); it "works" as long as you do not notice the menu colors on other applications become slightly wrong, and it is a couple of lines of simple code instead of several hundred lines of low-level GDI drawing code.

    (To make things even more interesting, a later version of the high-level language "eats" one of the messages needed for owner-draw menus, so I had to temporarily subclass the window to renumber the message before it gets to my menu-drawing code. The fun of programming for Win32…)

  3. Anonymous Coward says:

    Of course, you could simply not have an application colour scheme to begin with. If the standard menu colours don't fit with the application, chances are the application doesn't fit with the user-selected theme.

    The only situation where an application colour scheme makes sense is in a public terminal type setting (ATM, museum info panel, …) but then there's no reason not to change the system colours.

  4. @Cesar says:

    It seems like your problem is writing bad code that uses bad libraries, rather than Win32's fault.

    Programming in Swing if you're several abstractions away from the drawing libraries where the abstraction deliberately trips you up would be just as hard to resolve. But that's not Java's fault either.

  5. Cesar says:

    It was not my code; I inherited it. Not my choice its color scheme, or its unportable high-level language. But I was not going to leave it trampling global state.

  6. Anonymous Coward says:

    Not my choice

    Yeah, been there. Just because they know how to push numbers around on paper, they think they're the final authority on everything computer related. The only hope we have is that someday we can say: look – we wasted this many man hours on doing something non-standard and unproductive.

  7. Override WM_GETMINMAXINFO, my young padawan, to get the fullscreen.

  8. dsmtoday says:

    ITaskbarList2::MarkFullscreenWindow

    msdn.microsoft.com/…/bb774640%28v=vs.85%29.aspx

    rock-solid reliable and available in WinXP

    works for applications that have to be fullscreen across multiple monitors

  9. 640k says:

    A concrete class whose name starting with "I"? Sigh, Windows' COM implementation goes against all sane OO conventions. Please purge COM from Windows ASAP.

  10. @640K:

    I think you don't understand interfaces. Go read a book, or something.

  11. Ian Yates says:

    @alegr1 is right.  There's a COM CLASS – CLSID_TaskbarList – which implements a couple of interfaces.  ITaskbarList and ITaskbarList2 (the only method on #2 is the one @dsmtoday pointed out).  It was easy to discover – look in MSDN for ITaskbarList2 and see that it's under a topic group about shell Interfaces and follow your nose from there.  The "Understanding the Taskbar" topic at msdn.microsoft.com/…/cc144179(v=vs.85).aspx has a lot of nice information.

    I wasn't aware of that particular interface myself – always good to read and learn from the comments :)

  12. Joshua says:

    @640K: COM has the unique property in that interfaces have a method in many cases to request an implementation to be instantiated.

  13. Cheong says:

    At some point, I wonder whether Windows should introduce a "This is a support tool" flag that, if not be set, all global setting written by this program will be saved into virtualized space that applies to that program only (or just ignore it if no equivalent local setting is available). This should have made most "unintentional" case of "using global solution to solve local problem" go away.

  14. Bron says:

    OK, so riddle me this.

    for the last decade, Auto-Hide has not worked correctly. Even if the taskbar *is set to audohide*, sometimes it stops doing it, for absolutely no reason. No pending notifications, no task tray attention needed.  The fix is to go in and *unset* and *reset* autohide.  This has been a known issue… oh… forever.

    So, given that autohide is inherently buggy, and that the API is exposed, why are you surprised that folks took advantage of it?

    And more, what's your moral high ground here, if the setting is already frequently ignored by Windows?

    *grabs a beer and sits back*

  15. kermi says:

    @Bron

    I've noticed the same exact thing, and it's annoying as hell. I've yet to find anyone alive who would've been able to explain this to me.

  16. kog999 says:

    @cheong00

    Then everyone would just set the "this is a support tool" flag and keep using global solutions. What is your definition of unintentional the programmer may not have intended to mess up the users auto hide preference but they certainly intended to check the auto hide box.

  17. @Bron says:

    "So, given that autohide is inherently buggy, and that the API is exposed, why are you surprised that folks took advantage of it?"

    I think you're getting confused between cause and effect:

    The autohide appears to be inherently buggy BECAUSE folks take advantage of the exposed API.

  18. @cheong00 says:

    Oh – why doesn't my app properly work? Oh it's because you need to put on the "my app is awesome flag". OK. I've put it on and now everything works. Isn't Microsoft silly for having these hoops for me to jump through?

    [Yup. Eventually, nothing is special any more. -Raymond]
  19. Steve says:

    About WoW, doesn't Blizzard not like it when you use third party tools with the client? Wouldn't any testing get your account banned?

  20. Cheong says:

    @Both @cheong00: I think for this case, the developer does not mean to change a global setting. Maybe they just ask "How to auto-hide taskbar?" on a forum and people enthusiastically show them how to do this with a global change. By silently replace them with a local change it would still keep them happy, because as far as they care, if they can autohide the taskbar "for their application" they'd have no concern what's the means be used to get there.

  21. Gabe says:

    cheong00: What happens when the magic incantation the hapless programmer finds on the forum includes setting the "I'm special" bit?

  22. Bron says:

    to @@Bron (um, that's a weird way to refer to someone who replied using the name @Bron)

    While that's a reasonable assumption,  I don't think that's the cause.  Why?  Because the auto-hide bugginess happens on *machines that are fresh windows installs* that don't have *ANY* third party software. Hmmm!

  23. Cheong says:

    @Gabe: Yup. That's why I said "At some point, I wonder…". It's not a good solution to the problem either.

    However, since Win8 and VS11 will introduce a new type of application called Metro. I think it could be a good time to introduce this flag and a new application template for that, then wait for one or two new version of VS to enforce this shim. We can also update "editbin" in SDK to include ability to set this flag so end-users of the old applications can toggle this flag themselves. (I assume here that only technical savvy enough people – read as "those can search information on web" – will use these kinds of application.

Comments are closed.