Date: | April 8, 2010 / year-entry #108 |
Tags: | history |
Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20100408-00/?p=14373 |
Comments: | 11 |
Summary: | There are six styles available to the static controls which draw frames and rectangles in one of three fixed colors: SS_BLACKRECT SS_BLACKFRAME SS_GRAYRECT SS_GRAYFRAME SS_WHITERECT SS_WHITEFRAME But if you actually create a static control with one of these styles, you'll find that the color isn't actually black, gray, or white. So why are they called... |
There are six styles available to the static controls which draw frames and rectangles in one of three fixed colors:
But if you actually create a static control with one of these styles, you'll find that the color isn't actually black, gray, or white. So why are they called black, gray, and white? Because they used to be black, gray, and white. Knowledge Base article 125684 gives the history behind these styles. Back in the 16-bit days, these styles really did give you black, gray, and white, or at least they did if you used the default color scheme. Windows 95 shifted from using the window colors to the 3D colors, presumably to give the system a less harsh look. |
Comments (11)
Comments are closed. |
Is there any defined replacements with better names?
As the linked article explains, yes. Yes there are.
@Trevel: No, it doesn’t.
The linked article explains what colors the SS_XXX color styles map to, but you cannot use those colors in place of the SS_XXX style flags themselves. There are no alternative SS_XXX styles defined along the lines of SS_3DHILIGHTRECT, SS_3DSHADOWRECT and SS_3DDKSHADOWRECT, for example.
(Or if there are, the linked article does not identify them)
I’m not sure if this is very relevant, but it is slightly. What colorful pattern do most property dialog boxes on XP have? What I mean is if you flood-fill the screen-shot of My Computer -> Properties dialog box in mspaint in the grey central area, is does not work. The reason is clearer if you tilt laptop screen, or zoom in 8 times, or the best way is to auto-level adjust the same screenshot in paint.net.
@Dean Harding, about theme API. Yes and no. You should use the theme API when themes are present, but if the OS runs in classic mode the theme API doesn’t work. Unless you want to force your users to run Aero (or Basic), you should support the old-style look as well.
Well, for any new development you should be using the theme API, so it’s kind of moot now anyway.
Besides, while they’re not *actually* white, grey and black, they’re (usually) white-ish, grey-ish and black-ish. So it’s not like the colours are totally off.
Safe mode also requires old apis. And will continue to require it for the foreseeable future in coming windows versions.
Of course, in Windows 95’s default color scheme, the ‘black’ was still black, the ‘white’ was still white, and the ‘gray’ was (darker than before) gray.
They have been replaced with something else. Would probably be a good time to ‘deprecate’ the names. Use a pragma or just remove them from the SDK and doc it.
‘But that would require changing lots of code’. Yes but you are recompiling it anyway. You are at least somewhat close to the code. With pragma you just get a warning. With removing it would not compile.
Leaving leftovers in the code lead to bugs. With an SDK as old as the windows one I would bet there are hundreds of instances of this sort of thing. It is also not without precedence where a bunch of the old CRT calls were ‘deprecated’.
“Back in the 16-bit days, these styles really did give you black, gray, and white, or at least they did if you used the default color scheme. Windows 95 shifted from using the window colors to the 3D colors, presumably to give the system a less harsh look. “
Don’t forget NT 3.x.
"Would probably be a good time to ‘deprecate’ the names. "
Yep, unlike function names like OpenIcon and CloseWindow that are set in stone, constant names are just names of #defines, which can easily change without changing the actual value which is the one actually used in the binaries.