I am trying to find the dimensions of standard caption buttons in a Win98SE system with no desktop customization of any kind (a clean installation). I have verified the caption buttons width to be 21 pixels and the height to be 19 pixels.

When I use GetSystemMetrics with SM_CXSIZE/SM_CYSIZE as parameters I get a width of 23 pixels and a height of 23 pixels. The same when I use the SystemParametersInfo API (with SPI_GETNONCLIENTMETRICS). By the way, the small caption buttons dimensions are reported to be: width-19 pixels, height-16 pixels.

I wonder whether other people also get different dimension than the ones observed.

In the NONCLIENTMETRICS reference I read that "The NONCLIENTMETRICS structure contains the scalable metrics associated with the nonclient area of a nonminimized window", so I wonder whether my different results can be attributed to a scaling factor, and if so, which one. Any ideas ?
Posted on 2002-10-27 14:49:02 by micmic
Finally I realized that all caption buttons are drawn shorter & narrower than they really are. Above & below each caption button there are 2 pixels that seem to belong to the title bar, but strangely enough you can click on them and activate the caption button. I've been trying to custom-draw a window looking & behaving exactly the same as any normal window and this was really puzzling. Not a big issue, anyway :)
Posted on 2002-10-28 06:02:51 by micmic
I see just what you have found out.
I have gone through the same things
and I have made a example of a custom
drawn window that has all the same
features of a normal window including
the system menu and the double clicking
of the titlebar to resize the window.

If you need example code just let me know.
I am not sure if that is what you was after,
or asking about, or if you was just making
a note about what you have discuvered.

The only thing I really need to add to the
example would be, to make the program
read the system metrics for the current
size settings of these buttons, but then
again, that would make it not custom then
right??


Zcoder.....
Posted on 2002-10-28 10:59:22 by Zcoder
What I was trying to do was to respect any changes the user might have made, but also to give the option to change -for example- the color of the title bar if he chooses so. It was much more complicated that I first thought, but doable. You have to respond to a lot of messages, like WM_NCACTIVATE to repaint the title bar, WM_NCHITTEST to move the window when the user drags the title bar and more... You also have to check the border size, the font and size of the title bar text, the color of the title bar and any possible gradient effect, etc. It gets even more tricky, because you may want to respond in real-time to any changes the user may make to system colors or window dimensions, which means you must also respond to messages like WM_THEMECHANGED, WM_SYSCOLORCHANGE, WM_SETTINGCHANGE and others...
Posted on 2002-10-28 11:52:35 by micmic
But no more results be found....
At lease I use a no border window and draw ownTitlebar on it.
at first program,I draw caption on the orginal Titlebar,
and draw ownborder while windows border paint.
But I found if some user change caption size and border's size in regedit or Display perenfence,
My Cool app while became so ugly...
So I chioce the noborder window.
here a demo
Posted on 2002-10-28 19:17:59 by Const.Ex
That's a beautiful window :) I think you have a common memory leakage, though. You create a new brush everytime WM_CTLCOLORSTATIC is received (which can be lots of brushes if your window stays open for some amount of time) but you never delete them. I just mention it because I see it all the time. You should create your brushes in response to WM_CREATE, delete them in WM_DESTROY and just pass their handle in WM_CTLCOLORSTATIC.
Posted on 2002-10-29 01:54:22 by micmic
You should create your brushes in response to WM_CREATE, delete them in WM_DESTROY and just pass their handle in WM_CTLCOLORSTATIC.
And in the case where you have the same message loop handling multiple static windows, store the created brush in a global variable. Upon entry to the message handler, check that variable, if it is not null then delete the brush it contains. Doing it this way means you are always cleaning up the previously used brush, and it is no problem using creating and using different brushes for different statics.
Posted on 2002-10-29 05:39:25 by sluggy
This is just a quick hack, 20 minutes
but it shows how to make fake titlebars
without bitmaps ect.


Zcoder.....
Posted on 2002-10-29 06:36:38 by Zcoder
I agree that good idea create a brush on WM_CREATE,use it in WM_CTRCOLORSTATIC,and then Destory it In WM_DESTORY....
And,The project I uploaded is always a test,I deleted it and create a new project.
In my way,I always create brush in the WM_CTRCOLORSTATIC but destory then will I finish drawing....
So I will use that Once to replace my low efficiency methods.
thanks....

BTW,zcoder 's windows is so hot,:)
Posted on 2002-10-29 07:14:53 by Const.Ex