| Date: | March 28, 2007 / year-entry #108 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20070328-00/?p=27473 |
| Comments: | 13 |
| Summary: | There are two ways to make a vertical toolbar. You can use the common CCS_VERT style, or you can use the TBSTYLE_EX_VERTICAL extended style which is specific to the toolbar. Why are there two ways of doing the same thing? Because we messed up. Whoever created the TBSTYLE_EX_VERTICAL extended style didn't realize that there was... |
There are two ways to make a vertical toolbar. You can use the common Because we messed up. Whoever created the What's worse, some vertical behavior is controlled by Unfortunately, the story doesn't get any better. Once this mistake was discovered, work was done to try to get the two styles in sync, so that setting one automatically set the other. The idea was to ensure that everybody got consistent behavior instead of getting half-and-half if you, say, turned on It's a mess. We're sorry. Pre-emptive snarky comment: "This is why Windows sucks." |
Comments (13)
Comments are closed. |
Apology accepted, however, I find no information or references on TBSTYLE_EX_VERTICAL when doing a web search or when searching MSDN.
So where would we find information on this mystery style flag?
I think this is an interesting topic. Care to enumerate a few key differences that brought this flag to your attention?
Yeah, with no mention of TBSTYLE_EX_VERTICAL in Google or MSDN, go ahead and finish the work of having the styles always sync up. Any program that has a problem with that deserves what it gets.
Just pretend this post was about PBS_VERTICAL instead. There is TCS_VERTICAL, but that has the same value as CCS_VERT.
Just for completeness: PBS_VERTICAL is for progress-bars, and TCS_VERTICAL is for tab controls. While we’re at it, there’s also a PGS_VERT for pager controls (the container control used to scroll a toolbar — or any other window that only scrolls in one direction) and TBS_VERT for trackbars. OTOH, pagers and trackbars also have a *_HORZ flag, and there’s no CCS_HORZ equivalent, so maybe those two need a separate "vertical" flag.
So the article could be about either of the first two common controls, or possibly the pager or trackbar, depending on what the HORZ flag on those controls is used for.
(Actually, it looks like either VERT or HORZ is zero for those two controls, so one or the other of them is maybe the default? If that’s true, the controls could have been designed so that they always go in horizontal mode, and the CCS_VERT flag could set them to the other mode. Of course the trackbar already uses CCS_VERT’s value (0x80) for TBS_NOTHUMB, so something would have to give on that control. But if TBS_VERT had never existed, that bit would have been available too. Hmm…)
ho no! sounds like you posted a problem with a flag that didn’t actually ship, and therefore isn’t an actual problem for us :)
Actually, I can’t even find TBSTYLE_EX_VERTICAL in the Platform SDK (I know its been renamed, but my DVD is in the mail so I’m still in the Win2K3 SDK).
You wouldn’t make up issues to post about would you, Raymond? Or change the name to protect the guilty? (Maybe the tab control team can get violent while the toolbar team are much more easy going… ;) )
For the life of me I can’t think why any program would *like* two different vertical toolbar styles and behaviors. Why did they do this?
Poor catching skills folks, you are no match for a real programmer like me ;)
While TBSTYLE_EX_VERTICAL indeed doesn’t exist in VS 2005 or Platform SDK, there is another flag similar to CCS_VERT and that is TCS_VERTICAL (it has the same value of 0x80L) so it can be considered the one Raymond is talking about unless he has different Platform SDK.
If you think about it, CCS_ flags are Common Control Flags and they should affect all controls that fit into that category, including Tab Controls.
[…the company PR department (who probably get the massive heebie-jeebies from this whole blog thing)]
["This is why Windows sucks."]
That sound you hear is somebody having an aneurysm :)
I admit I’m curious why someone would ever want to require them to be different. But on the other hand, that wasn’t the point of the original post – which as I read it, was to show how small, unavoidable(*) slips can result in a lasting maintenance overhead.
And for an undocumented and unknown flag, yeah, I’d personally be tempted to leave that to the team of miracle workers that do app-compat, but then, I’m lazy and passing the buck like that is easy.
(* Sure, this specific slip was avoidable, but you can’t avoid making such slips in something as large as an OS)
Wednesday, March 28, 2007 10:25 AM by richard
[
[ I don’t know. I guess I messed up by talking
[ about this flag in the first place. -Raymond]
Huh????? Richard’s question looks pretty reasonable to me. Especially, look back at the context:
But no one outside of Microsoft could get anything other than that half-and-half behaviour, and it wasn’t due to "forgetting" to set an undocumented flag. How could you find out if they really liked half-and-half better than the irreproducible results of a secret recipe?
We do need you to talk about previously undocumented behaviour because that’s the only way we can get it. Meanwhile for those of us who learned (belatedly and I apologize again) that you yourself aren’t Microsoft, it still looks pretty fair for us to blame Microsoft.
Meanwhile, the compatibility of these two flags provides a pretty striking contrast to some of the RTL flags, where setting two of them can result in them partly cancelling each other out, producing unwanted halves-and-halve-nots.
Now if you’d been in Marketing (ref a more recent entry in the blog) you’d have worked out some reason why having two conflicting ways of doing mostly the same thing was a benefit. I sentence you to a week’s corporate re-education :-)