August 30th, 2010

On LockWindowUpdate: Locking the taskbar

Andy Visser posted to the Suggestion Box something that wasn’t so much a suggestion as a comment, presumably to get around the fact that comments on the original item had been closed: “I’ve found that the start bar seems to behave like it may be using this call incorrectly. I put my start bar on the left hand side of the screen. When I try to resize the bar (dragging its edge left and right), the system tray will dynamically move icons (based on tray width), seemingly disregarding the lock. The rest of the bar waits until MouseUp to redraw.” Actually, the taskbar (that’s the name of the thing you’re referring to) does not call LockWindowUpdate at all, so what you’re seeing is not the result of any incorrect use of LockWindowUpdate. I’ve also been unable to reproduce the behavior you describe. I tried Windows XP, Windows Vista, and Windows 7 both with and without Show window contents while dragging enabled, and the notification area (that’s the name of the thing you’re referring to) repaints at the same time as the rest of the taskbar. I don’t see it “bypassing” anything. This comment demonstrates one of the common problems with bug reports submitted from the field: The description of the problem rarely includes the system configuration under which the problem occurs—they often don’t even mention what operating system they’re running! The person submitting the comment generally assumes that you will somehow know how their computer is configured (or believes that the problem is not configuration-dependent). This leaves people like me trying to reproduce the problem on various systems with various configurations before finally giving up and saying “Sorry, I don’t see it.” In some cases, the configuration setting that created the unwanted behavior is a setting whose sole purpose is to establish the unwanted behavior. For example, a customer reported, “Windows Vista is not displaying the user’s picture on the Start menu or the logon screen. We discovered that the Apply the default user logon picture to all users policy prevents the user’s customized picture from being displayed. We removed that policy, but that did not solve the problem. Is there anything else that might be causing this?” I found it interesting that the customer initially wondered why the user’s custom picture wasn’t showing up, when they had explicitly set the policy that says “Do not use the user’s custom picture.” But at least they figured that part out on their own. After some more questions, the customer explained that removing the policy restored the user’s custom picture to the Start menu, but it nevertheless did not appear on the logon screen. (Thereby illustrating the problem of vague antecedents. When they wrote “that did not solve the problem”, they weren’t clear what the problem was. It turns out that they meant “that only solved part of the problem”: The user picture appears on the Start menu, but not on the logon screen.)

After additional rounds of troubleshooting, the customer eventually revealed that they had also set the policy Do not display last logged on user name. Um, if you disable showing the name of the last logged-on user, then the picture of the user doesn’t appear either. (Maybe they took too literal a reading of the policy, expecting it to hide the name but not the picture? What would be the purpose of that? Exercise: Why isn’t the policy called the more accurate Do not display information about last logged on user?)

Topics
Other

Author

Raymond has been involved in the evolution of Windows for more than 30 years. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie-jeebies. The Web site spawned a book, coincidentally also titled The Old New Thing (Addison Wesley 2007). He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information.

0 comments

Discussion are closed.