| Date: | April 9, 2007 / year-entry #123 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070409-00/?p=27323 |
| Comments: | 36 |
| Summary: | Commenter Gareth asked why, when the system metrics change and the taskbar changes size to match, the taskbar doesn't return to its original size when the metrics return to their previous values. Because the taskbar doesn't remember the path of changes that led to its current state. It just knows its current state. Let's say... |
Commenter Gareth asked why, when the system metrics change and the taskbar changes size to match, the taskbar doesn't return to its original size when the metrics return to their previous values. Because the taskbar doesn't remember the path of changes that led to its current state. It just knows its current state. Let's say the taskbar is 30 pixels tall, consisting of one row of buttons. Now you change the metrics so that a button is now 60 pixels tall. The taskbar says, "Hm, I'm 30 pixels tall, but that's not tall enough to hold even one row of buttons. I'd better increase in height to 60 pixels so that the user doesn't see a row of half-buttons (ugh)." Okay, the taskbar is now 60 pixels tall. Now you change your metrics so that a button is 30 pixels tall again. The taskbar says, "Hm, I'm 60 pixels tall. That's tall enough for two rows of 30-pixel buttons. Woo-hoo!" Result: When you change a setting and then change it back, things do not return to the way they were. This shouldn't be surprising. Many parts of the world behave this way. If you take a broom and sweep the dirt into the corner of the room, the dirt doesn't "remember" that "I used to be over there in the middle of the room. As soon as that broom is out of the way, I'll go back to the way I was." No, the dirt says, "Here I am in the corner of the room, la di dah."† Nitpicker's corner †Dirt can't talk. |
Comments (36)
Comments are closed. |
I’d like to think that software can be smarter than dirt. :)
Thanks for the explanation…
I’m a bit surprised that it should even require an explanation.
Michael: The taskbar, or the dirt? I’ve known some people who wouldn’t have figured out the dirt on their own.
Now, I’ve never had this come up. But I’d kind of expect the taskbar to remember what it was if nobody explained it to me. After all, the taskbar is kinda-sorta a window and windows tend to remember their previous settings: If I un-maximize IE, it remembers how big it was and where it was on the screen before I maximized it, even if I’ve opened and closed it several times in-between.
Oh, and Raymond: I know they’re borne out of your frustration with the pedants, but I’m actually enjoying the Nitpicker’s Corners as much as the entries lately.
I’ve never encountered that, but the explanation certainly makes sense.
I question the taskbar designer’s logic though, and I would suggest that any future taskbar designers size in multiples of buttons rather than pixels to begin with.
I have to say the nitpickers corner has brought another whole level of entertainment to your postings Raymond :).
The explanation only raises more questions, about why the taskbar was designed that way. It seems like a questionable design when the taskbar is docked along the top or bottom edges; in these cases, its height is snapped such that it can show an integral multiple of buttons.
If the taskbar stored its height as this integer multiple, it would work as people expected.
I love the Nitpicker’s Corner. Especially when it succinctly explains the absolutely painfully obvious.
Seconded.
On a related note, I’ve assumed for years this lack of memory is why maximized windows sometimes keep their reduced sizes and offset locations after a DirectDraw/Direct3D change of screen resolution ends. Unlike system metrics, though, it seems like the system could compensate for resolution changes; if it’s not too big a perf hit, just make sure all maximized windows are aligned to monitor boundaries.
The Nitpicker’s Corner is funniest when it’s read using Jim Gaffigan’s side-comment voice.
<gaffigan>"Dirt can’t talk… I don’t think he knows that…"</gaffigan>
>> Now you change your metrics so that a button is 30 pixels tall again. The taskbar says, “Hm, I’m 60 pixels tall. That’s tall enough for two rows of 30-pixel buttons. Woo-hoo!”
But that’s not what actually happens. The taskbar is 30 pixels tall. You switch from Classic to XP Theme. The taskbar says “I can’t fit in 30 pixels, let me resize to 38”. Then you switch back to Classic. The taskbar stays 38 pixels. That’s not enough for 2 rows of buttons. You still get 1 row, but it is out of alignment. Why doesn’t the taskbar say “I don’t look as good at 38 pixels, let me resize to 30 (or 60) instead.”? If it is smart enough to say the first thing why doesn’t it say the second? (Not that taskbars actually talk).
Probably user error on my part, but I usually two-stack my task bar for all the various things I’m running. So I have two rows of buttons (and fits the 8 quick launch shortcuts in nicely). Yet every time I reboot (eg patches, installs, etc), the taskbar goes back to one-row in height. Seems to happen if it’s locked or unlocked, etc. Keeps me from rebooting, I guess. What’s my stupid user error here ?
[If it did, that would make it different from pretty much every other Windows program. Notepad, for example, remembers its size in pixels, not lines of text. If you change the font size in Notepad, the Notepad window doesn’t resize. -Raymond]
But the taskbar is different from pretty much every other windows program. There are times to adhere to broad standards of behavior and times to stray from them. Notepad may not resize its window when font sizes change, but many controls do as do menus. Taskbar is more akin to a menu or list/combo box than to notepad.
Raymond said: “If you change the font size in Notepad, the Notepad window doesn’t resize.”
But command prompt does :D
[If it did, that would make it different from pretty much every other Windows program. Notepad, for example, remembers its size in pixels, not lines of text. If you change the font size in Notepad, the Notepad window doesn’t resize. -Raymond]
When the taskbar is docked to the bottom, then sizing it doesn’t size it by pixel, it sizes it in multiples of button height. Therefore, it’s pretty easy to assume that the button height is the unit of measurement for taskbar height. The same is actually true of the command prompt example above – it snaps its sizes to character width/height.
With notepad, when you size it, it sizes by pixels, so that makes sense that it wouldn’t resize with the font.
Raymond said: "Woo-hoo, there are exceptions to a general statement."
Woo-hoo, command prompt is smarter than Notepad although it didn’t have to be that way.
Raymond said: "Have a cookie."
I will but after lunch, thanks :)
Raymond said: "Notice that the exception is in a geeky part of the system."
I always thought that Notepad itself was also a geeky part of the system being that lot of people use it to edit .ini files and write all sorts of code in it including .bat and .cmd files for that geeky command prompt.
I guess Notepad is an exception because it can use proportional fonts which makes it a little bit hard to calculate character and line sizes.
Nathan: My taskbar is two rows of icons high (and I widened the quicklaunch bar to show 14 things) and Windows XP Pro SP2 nicely remembers this for me every time I log on or reboot. Whether it’s locked or unlocked.
Windows is SUPPOSED to remember this.
Mr. Chen –
You are hilarious, sometimes the best part of the article (after anything technical of course) is your nit-pickers corner. I deal with the same type of people all too often myself, its nice that you can make light of it.
BTW, dirt talks to me ;)
PingBack from http://careerchangeblogs.info/why-doesnt-the-taskbar-return-to-its-original-size-when-i-return/
True enough, but then again, Notepad doesn’t change its size when you increase the font size either – even if the window can no longer display an entire character. So we have demonstrated that taskbar is already different in behavior from notepad.
I was just saying that a reasonable argument could be made for maintaining state in something other than pixels, not that this was the only reasonable behavior. I’m sure there’s quite a bit of other considerations that might go against that argument.
Dirt doesn’t talk, but maybe it speaks to you in another way, because it can make you happy. I just read an article yesterday about common bacteria in soil that act as anti-depressants. Apparently that strange group of people who eat dirt aren’t as insane as we thought.
I’ve read that some varieties of dirt are more intelligent than others.
Jack Mathews and others: The taskbar does resize itself according to multiples of button height IF no other toolbars are active. As the taskbar can accomodate a multitude of other toolbar types and sizes (some builtin in with Windows, others as addons) this is not always true.
For example: Try setting quick launch to use large icons and then placing it to the left of the running program buttons. You will be able to resize to non-multiples of buttons this way.
Funniest Nitpicker’s Corner EVER.
>> I’m a bit surprised that it should even require an explanation.
Only if you know or realize that the taskbar remembers its state in terms of pixels. I think that it would be reasonable for someone to believe that the taskbar would keep its state in terms of number of buttons in height (or width). In fact, I think a reasonable argument could be made that this is how the taskbar *should* keep its state.
My dirt very quickly returns to being spread all around the room.
My taskbar sits along the left edge of my screen so I can keep dozens of windows open at once without having the buttons clump up. Making the taskbar’s width a multiple of the "button width" would be meaningless in this case, since the buttons have no intrinsic width. Maybe the horizontal case should work differently, but I, for one, am glad the taskbar stores its width in pixels.
Meat for nitpick corner :)
“When you change a setting and then change it back, things do not return to the way they were.”
As a non-native English speaker I had a hard time understanding the above sentence — it sounded illogical. At first it implied to me that *settings* do not return to the way they were. Then I excluded “settings” from “things” and it made sense again.
Just like Mr Cranky’s, my dirt acts in exactly the way you hypothesise that intelligent dirt would.
My conclusion: one small child can make a whole houseful of dirt become intelligent.
Good point.
Hmm the obvious fix for this is to keep a value for the width of the bar (the ‘what did the user last specify they wanted to be at’ value), and the current value (that everything would see). The UI would then try to change the bar back to the desired size at the next opportunity.
Text box carets follow this behaviour for the horizontal position of the caret, so it should not be too costly to implement.
Dirt is more intelligent than the taskbar. Dirt gets the taskbar to do its talking for it:
[Units other than pixels]
The ones that use dialog units? The ones that use HIMETRIC and all that other stuff? CMD counts lines of text because it’s based on xterm.
[Other characteristics]
Bugs can’t talk. Oops, I mean seconded. And thirded. Etc. Some years ago I mentioned the most irritating taskbar bug which still continues unchanged, several times a day, only in XP, not in older versions. Haven’t tested it in 2003 or Vista though.
Another is that sometimes the taskbar resizes itself to zero rows (around two pixels, just enough to grab if you notice that it’s there). For some reason this one has a Knowledge Base article, existing since pre-XP.
I’ve experienced similar behavior to the situation described. However, what confused me most was that the taskbar and notification area/tray would remain enlarged/distorted when I reapplied the original settings through SystemParametersInfo but would correct itself when you reapply the settings through Display Properties, Appearance. Any ideas why this might be the case?
There’s something I don’t like about the taskbar if you set it to 2 button rows, and dock it to the bottom of the screen, namely this:
My start button no longer lives in the same place, it docks to the top of the start bar instead of the bottom :(
@Factory: That sort of bookkeeping doesn’t make much sense to me. To understand why, I’ll make an analogy with control panels. Suppose you have a program, and have 2 control panels for it. The first panel has its own bookkeeping, and when you press OK, it commits all the settings from its bookkeeping data. The second panel plays nice and loads the settings from the right place(s) and is careful only to commit those settings you changed. When you configure things from this panel, eveything is fine. But when you later use the first, the changes you made in the second panel are lost.
This too, could happen when you implement similar bookkeeping in the taskbar. Because /what/ would cause the bookkeeping to occur, and when should it be a store or restore? If there’s a perfectly valid answer to that question, then yes it could be implemented.
But even then, the user might not remember that there has been a previous setting. Or there might be another user (using the same account) that wants to change the font size, and then has its taskbar changed too and doens’t know why and maybe even panics.
Bookkeeping isn’t easy just because it’s done in textboxes.
In short, one’s fix is another one’s bug.
Alas, to those that apparently change system and font metrics all the time (I mean, who won’t … it’s just too fun to miss), this issue seemingly no longer persists in Windows Vista.
Drak: My task orb is floating nicely in the vertical center of the taskbar if I resize :)
Norman Diamond: CMD is not based on xterm (guess why you don’t have terminal emulation) and it is not responsible for drawing its own window.
@Johannes: But i want it at the bottom :P Nah, on my Vista my taskbar is only on row high anyway.