How do I programmatically show and hide the Quick Launch bar?

That's not something a program should be doing. Whether the Quick Launch bar is shown or hidden is an end user setting, and programs should not be overriding the user's preferences. Explorer consciously does not expose an interface for showing and hiding taskbar bands because it would just be a target for abuse. Much like the program that wants to uninstall other programs, the taskbar would become a battleground among programs that each wanted to force themselves on and force their opponents off.

The user is the arbiter of what goes into the Taskbar.

I'm told that Windows Vista added a new ITrayDeskBand interface that does indeed let you turn taskbar bands on and off. (I don't know whether it works for Quick Launch. Heck, I don't even know if it works at all! Not my area of expertise.) The story I heard was that so many programs were doing exactly what they shouldn't be doing—namely forcing their feature on, overriding the user's preference—that the Taskbar folks decided, "If you can't stop people from doing a bad thing, at least make them do the bad thing under your supervision. That way you have just one evil thing to support instead of everybody's home-grown undocumented hack." It's sort of the Taskbar Needle Exchange Program.

It so happens that we spent most of last week solving this exact problem: forcing one of our application’s deskband on a user’s taskbar on Windows XP.

It was a request from our customer, a large corporation, who didn’t want to have its users’ turn-on the deskband on their own. As a matter of fact, they even have a group policy to prevent them from adding/removing taskbar bands through Explorer’s menu.

At first we told them Windows XP just didn’t support this operation, only to receive the reply: "But <Competing Product X> does it! Do it too!". And thus we dived into undocumented interfaces, and eventually found a way around this limitation.

It’s really depressing to think that because of those who would abuse such an API, we had to go through all of this trouble to fulfill a very legitimate demand from a customer who just wanted to make its deployment on a large number of machines easier.

Hmmm… who’s going to write the first utility that intercepts this (as well as the writes to the registry) and exposes a handy interface to the user that gives back control, wresting it away from such programs?

And who’s going to write the first piece of crap code to undermine that again?

Just the fact that I thought of that the moment I read this article probably means somebody already did write it…

Administration shouldn’t be an application’s task, but often becomes one because of things like this. It’s funny, though, how things evolve and happen because of money. Someone throws a few dollars your way and suddenly those undocumented interfaces don’t look quite as scary as they did a few minutes.

That said, just because you have no choice to fulfill a demand doesn’t make it automatically legitimate.

I’m honestly surprised that the application I work on hasn’t implemented this "Feature". I suppose it’s possible that it’s only a matter of time if there’s now a documented interface.

I recently needed to find a way to programatically hide the whole taskbar. I was installing kiosks that had to have a full-screen app, and had to do it within the framework of the required group policy.

Somehow the fullscreen window would always get resized to reveal the taskbar, and the only way to stop the behavior was to set the taskbar to hide. Group policy doesn’t allow the user to change this setting, so I had to find a way to do it with a program.

I managed to find the setting buried in some binary registry value, but it only takes effect when Explorer starts, and gets rewritten whenever Explorer closes. The only way to make it happen was to write a script to kill Explorer, write the registry key, then restart Explorer!

Perhaps a better solution (though more work, obviously) would be to provide an API but also provide the user with a “no thanks” option/policy which disables it. Then corporates are happy and end users are happy, too (if they can find the switch, natch).

A bit like the notification icons now have, I suppose. Or like the way in the browser I use I can disable certain potentially annoying javascript features like resizing the window, but they’re enabled by default.

[That pair of settings just escalates the war. “How do I force my taskbar band on all my computers even if the employee checked ‘no thanks’?” -Raymond]

I agree with Raymond on this. I wish more programmers would realise what settings and features they shouldn’t be touching. My pet peeve, are programmers that think it’s ok to use the clipboard for data conversion and the like. It’s user space, stop using it unless it’s part of a legitimate copy and paste opperation.

Of course, the arms race has a parallel in group policies: I often have to find obscure tricks to reverse the group policies which get rammed down per-user at work. (Centrally managed user accounts, department managed systems, mandatory user profiles – with the Windows user accounts being dynamically created and deleted locally, no domains in sight. Stomping the Policies registry keys just after login takes care of most of the problems, but not all.)

I’ve never liked the idea of trying to limit what programmers "can" do by restricting the API – I think it’s clear by now that all that will achieve is sending programmers down back routes, making assumptions and guesses because there isn’t a properly documented route to achieve what they want. I hope this change in thinking is behind the addition of ITrayDeskBand – too late for Quick Launch, but with a bit of luck it might prevent some programmer out there going "hm, no documented way to toggle echo control on the voice control API … but if I XOR byte 17,176 of whatnot.sys with the value 0x98, that seems to disable it".

I think I am starting to side with James. As long as code is running with the necessary privileges, it’s going to be able to do "bad" things; not exposing a public API to do those things is just a little speed bump. Ultimately it comes down to trust. Do you trust Adobe/HP/Microsoft to do the right thing? Unfortunately, the answer is more often "no" than "yes". But we continue to let them get away with it, so there are no consequences to be paid.

It’s interesting that the OS is making an assumption that applications will be at war with each other and using that assumption to limit what APIs are exposed (as well as assuming that users should be able to set OS preferences). Sure, this is often the case. But Windows is also used in many closed environments where the installed applications are locked down (and where it is not desirable to let users fiddle with the OS settings).

It seems the solution would be to offer an administrative kit that allows you to install Windows and enable/expose interfaces that allow applications to do certain customizations which we typically think of as user-preferences.

“[If you couldn’t follow the sample program, then at least use the documented interface instead of borking around undocumented binary data and killing Explorer. -Raymond]”

As I said, the full-screen window was being resized shortly after being created. If there wasn’t something causing this problem, I wouldn’t have had to resort to extreme measures.

As for using the documented interface, that’s like using regular expressions — then I would have two problems. :) Seriously, why go through all the hassle of corporate bureaucracy to create a small custom app when a 3-line batch file would work just as well?

[Um, because one of them is supported and the other isn’t? Then again, if I have to explain this, I’ve already lost. -Raymond]

Mark Steward: You don’t need to run elevated because the control panel the configures UAC is not elevated.

(It does use elevation to make settings changes but the actual user interface windows/process is not elevated, so anything can drive it. Since it is on the UAC whitelist it can elevate without prompts. Oops. Still there are even bigger problems because things like RunDll32 are on the whitelist too…)