Window and scroll bar width?

Posted by WillFa on Thu 11 Sep 2008 11:21 PM — 4 posts, 11,533 views.

USA #0
The three window width's that you can feed into GetInfo return, for example:

GetInfo(262) = 1258 , which seems to be measured from the outside edges of the world window frame.

GetInfo(264) = 1254 , which seems to be measured from the inside of the frame.

GetInfo(281) = 1240 , which is the width of the text rectangle, which at the moment fills the inside frame - the scrollbar width. But that can change if TextRectangle resizes the frame...

Is there a way to get the scrollbar width so I could consistently generate the 1240 value? (i.e. GetInfo(264) + HKCU\Control Panel\Desktop\Window Metrics\ScrollWidth )





p.s. Are we close to getting our dirty little hands on 4.37? :)
Amended on Thu 11 Sep 2008 11:22 PM by WillFa
Australia Forum Administrator #1
281 is "Output window client width".

That is, regardless of any text rectangle size, this is the client window width.

Thus the difference between 281 and 264 will be the scrollbar width (20 pixels in my case).

In case anyone is wondering what all this talk about clients is about, the client area is the area onto which miniwindows, text, background images, etc. appears.

The "non-client" area is the larger area which encompasses the title, borders, scroll bars and other "housekeeping" stuff.

However this doesn't totally account for why there is a 20-pixel difference in my case between GetInfo (264) and GetInfo (281) as both refer to "client" sizes.

I think this can be accounted for by the fact that there is a splitter window inserted into the frame client area. The splitter window owns the scroll bars, so they are part of the non-client area of the output window, but part of the client area of the owner window, which is the world window.

I hope that makes sense. :)
Australia Forum Administrator #2
4.37 should be released fairly soon - at least within about 5 days from now.

I am trying to finalize things like getting the current mouse position.
USA #3
Sweet! Thanks for the clarification, Nick. :)