Height of Title Bar
am 27.11.2007 14:20:34 von DM McGowan III recall reading somewhere about a function or property that returns the
height of a window's title bar, but can't recall. Anyone know off the top of
their head what that is? Thanks!
I recall reading somewhere about a function or property that returns the
height of a window's title bar, but can't recall. Anyone know off the top of
their head what that is? Thanks!
"Neil"
news:IRU2j.2342$C24.1420@newssvr17.news.prodigy.net...
>I recall reading somewhere about a function or property that returns the
>height of a window's title bar, but can't recall. Anyone know off the top
>of their head what that is? Thanks!
Declare Function GetSystemMetrics Lib "user32" Alias "GetSystemMetrics" _
(ByVal nIndex As Long) As Long
Const SM_CYCAPTION = 4
BarHeight = GetSystemMetrics(SM_CYCAPTION)
"Stuart McCall"
news:fih75a$kqg$1$8302bc10@news.demon.co.uk...
> "Neil"
> news:IRU2j.2342$C24.1420@newssvr17.news.prodigy.net...
>>I recall reading somewhere about a function or property that returns the
>>height of a window's title bar, but can't recall. Anyone know off the top
>>of their head what that is? Thanks!
>
> Declare Function GetSystemMetrics Lib "user32" Alias "GetSystemMetrics" _
> (ByVal nIndex As Long) As Long
>
> Const SM_CYCAPTION = 4
> BarHeight = GetSystemMetrics(SM_CYCAPTION)
>
OK, thanks. For some reason I thought I had seen a built-in function or
property in the Access help. Thanks.
"Stuart McCall"
news:fih75a$kqg$1$8302bc10@news.demon.co.uk...
> "Neil"
> news:IRU2j.2342$C24.1420@newssvr17.news.prodigy.net...
>>I recall reading somewhere about a function or property that returns the
>>height of a window's title bar, but can't recall. Anyone know off the top
>>of their head what that is? Thanks!
>
> Declare Function GetSystemMetrics Lib "user32" Alias "GetSystemMetrics" _
> (ByVal nIndex As Long) As Long
>
> Const SM_CYCAPTION = 4
> BarHeight = GetSystemMetrics(SM_CYCAPTION)
>
>
BTW, do you know which SM constant would give me the width of the window's
left border? Thanks again.
"Neil"
news:V_X2j.3277$fl7.626@newssvr22.news.prodigy.net...
>
> "Stuart McCall"
> news:fih75a$kqg$1$8302bc10@news.demon.co.uk...
>> "Neil"
>> news:IRU2j.2342$C24.1420@newssvr17.news.prodigy.net...
>>>I recall reading somewhere about a function or property that returns the
>>>height of a window's title bar, but can't recall. Anyone know off the top
>>>of their head what that is? Thanks!
>>
>> Declare Function GetSystemMetrics Lib "user32" Alias "GetSystemMetrics" _
>> (ByVal nIndex As Long) As Long
>>
>> Const SM_CYCAPTION = 4
>> BarHeight = GetSystemMetrics(SM_CYCAPTION)
>>
>>
>
> BTW, do you know which SM constant would give me the width of the window's
> left border? Thanks again.
Sure. Here you go:
Const SM_CXBORDER = 5 'Width of non-sizable borders
Const SM_CYBORDER = 6 'Height of non-sizable borders
Const SM_CXDLGFRAME = 7 'Width of dialog box borders
Const SM_CYDLGFRAME = 8 'Height of dialog box borders
As I recall, the sizeable window border is the same as SM_CXDLGFRAME,
SM_CYDLGFRAME. I could be wrong, but I can't (right now) find the full api
reference in order to check.
"Stuart McCall"
news:fihm4g$19h$1$8302bc10@news.demon.co.uk...
> "Neil"
> news:V_X2j.3277$fl7.626@newssvr22.news.prodigy.net...
>>
>> "Stuart McCall"
>> news:fih75a$kqg$1$8302bc10@news.demon.co.uk...
>>> "Neil"
>>> news:IRU2j.2342$C24.1420@newssvr17.news.prodigy.net...
>>>>I recall reading somewhere about a function or property that returns the
>>>>height of a window's title bar, but can't recall. Anyone know off the
>>>>top of their head what that is? Thanks!
>>>
>>> Declare Function GetSystemMetrics Lib "user32" Alias "GetSystemMetrics"
>>> _
>>> (ByVal nIndex As Long) As Long
>>>
>>> Const SM_CYCAPTION = 4
>>> BarHeight = GetSystemMetrics(SM_CYCAPTION)
>>>
>>>
>>
>> BTW, do you know which SM constant would give me the width of the
>> window's left border? Thanks again.
>
> Sure. Here you go:
>
> Const SM_CXBORDER = 5 'Width of non-sizable borders
> Const SM_CYBORDER = 6 'Height of non-sizable borders
>
> Const SM_CXDLGFRAME = 7 'Width of dialog box borders
>
> Const SM_CYDLGFRAME = 8 'Height of dialog box borders
>
> As I recall, the sizeable window border is the same as SM_CXDLGFRAME,
> SM_CYDLGFRAME. I could be wrong, but I can't (right now) find the full api
> reference in order to check.
>
>
>
>
Thanks. Killing me, though, that I know I saw somewhere some property that
gives you the x,y distances from the upper left corner of the window to the
upper left corner of the form -- which would basically be the height of the
title bar and the width of the border.
> Thanks. Killing me, though, that I know I saw somewhere some property that
> gives you the x,y distances from the upper left corner of the window to
> the upper left corner of the form -- which would basically be the height
> of the title bar and the width of the border.
Ah. Maybe you could use:
Forms!FormName.WindowHeight - Forms!FormName.InsideHeight
The result will be in Twips. If you need it in Pixels, multiply by 15.
I'm curious (and there's no cure for curiosity). What do you need the info
for?
"Stuart McCall"
news:fii8lv$qre$1$8300dec7@news.demon.co.uk...
>> Thanks. Killing me, though, that I know I saw somewhere some property
>> that gives you the x,y distances from the upper left corner of the window
>> to the upper left corner of the form -- which would basically be the
>> height of the title bar and the width of the border.
>
> Ah. Maybe you could use:
>
> Forms!FormName.WindowHeight - Forms!FormName.InsideHeight
>
> The result will be in Twips. If you need it in Pixels, multiply by 15.
>
>
Maybe that's what I saw. I remember reading somewhere there was a way to get
the titlebar height directly with Access properties. That looks like what I
may have read. Thanks.
"Stuart McCall"
news:fiiaea$sas$1$8300dec7@news.demon.co.uk...
> I'm curious (and there's no cure for curiosity). What do you need the info
> for?
>
I'm opening up multiple instances of the same form. I want to place the
second instance just a little down from the first, so the top left corner of
the window sits right at the top left of the form in the previous window,
and so on.
> The result will be in Twips. If you need it in Pixels, multiply by 15.
>
I think you meant divide by 15.
I think Access 2002 and later have a twipsperpixel property, or something to
that effect. For Access 2000, I found some functions at MSDN that provide
the value, as follows:
Declare Function GetDC Lib "user32" (ByVal hwnd As Long) As Long
Declare Function ReleaseDC Lib "user32" (ByVal hwnd As Long, _
ByVal hdc As Long) As Long
Declare Function GetDeviceCaps Lib "gdi32" (ByVal hdc As Long, _
ByVal nIndex As Long) As Long
Const HWND_DESKTOP As Long = 0
Const LOGPIXELSX As Long = 88
Const LOGPIXELSY As Long = 90
'--------------------------------------------------
Function TwipsPerPixelX() As Single
'--------------------------------------------------
'Returns the width of a pixel, in twips.
'--------------------------------------------------
Dim lngDC As Long
lngDC = GetDC(HWND_DESKTOP)
TwipsPerPixelX = 1440& / GetDeviceCaps(lngDC, LOGPIXELSX)
ReleaseDC HWND_DESKTOP, lngDC
End Function
'--------------------------------------------------
Function TwipsPerPixelY() As Single
'--------------------------------------------------
'Returns the height of a pixel, in twips.
'--------------------------------------------------
Dim lngDC As Long
lngDC = GetDC(HWND_DESKTOP)
TwipsPerPixelY = 1440& / GetDeviceCaps(lngDC, LOGPIXELSY)
ReleaseDC HWND_DESKTOP, lngDC
End Function
Anyway, using these functions returns 15 for the twipsperpixel value, for
both x and y. So twips/15=pixels. But I don't think 15 would work in all
cases, with all resolutions.
Neil
> Anyway, using these functions returns 15 for the twipsperpixel value, for
> both x and y. So twips/15=pixels. But I don't think 15 would work in all
> cases, with all resolutions.
>
> Neil
Yes it would. That's precisely _why_ the twip was 'invented'. It's a
device-independent measurement unit.
(And yes I did mean divide. Duh! :)
"Neil"
news:Pd23j.3311$fl7.883@newssvr22.news.prodigy.net...
>
> "Stuart McCall"
> news:fiiaea$sas$1$8300dec7@news.demon.co.uk...
>> I'm curious (and there's no cure for curiosity). What do you need the
>> info for?
>>
> I'm opening up multiple instances of the same form. I want to place the
> second instance just a little down from the first, so the top left corner
> of the window sits right at the top left of the form in the previous
> window, and so on.
If your form instances are the only visible objects, then you ought to be
able to use this:
DoCmd.RunCommand acCmdWindowCascade
"Stuart McCall"
news:fiijak$7mc$1$8300dec7@news.demon.co.uk...
> "Neil"
> news:Pd23j.3311$fl7.883@newssvr22.news.prodigy.net...
>>
>> "Stuart McCall"
>> news:fiiaea$sas$1$8300dec7@news.demon.co.uk...
>>> I'm curious (and there's no cure for curiosity). What do you need the
>>> info for?
>>>
>> I'm opening up multiple instances of the same form. I want to place the
>> second instance just a little down from the first, so the top left corner
>> of the window sits right at the top left of the form in the previous
>> window, and so on.
>
> If your form instances are the only visible objects, then you ought to be
> able to use this:
>
> DoCmd.RunCommand acCmdWindowCascade
>
>
Thanks for the tip, but, no, they're just pop-ups on top of a main form.
Interesting: I applied the Forms!FormName.WindowHeight -
Forms!FormName.InsideHeight method, and it works fine -- except there's
about an eight of an inch gap between the title bar and left border and the
left/top edge of the next form. I expected them to be exactly lined up, as I
had seen in some other applications. It's not a big deal. And, actually, I
kind of like it. But it's just strange that that 1/8 inch gap would be
there......
"Stuart McCall"
news:fiifjj$4lj$1$8300dec7@news.demon.co.uk...
>> Anyway, using these functions returns 15 for the twipsperpixel value, for
>> both x and y. So twips/15=pixels. But I don't think 15 would work in all
>> cases, with all resolutions.
>>
>> Neil
>
> Yes it would. That's precisely _why_ the twip was 'invented'. It's a
> device-independent measurement unit.
>
> (And yes I did mean divide. Duh! :)
>
>
Well, with all due respect, I believe you're wrong here. The twip isn't a
device-independent measurement unit. It may be regionally-independent (i.e.,
isn't inches or centimeters), but it's not device-independent. "twip" =
"twentieth of a point" (should probably have been spelled "twep" -- but that
just sounds *wrong* :-) ). A point is defined as 1/72 of an inch. Thus, a
twip is a fixed value: 1/1440 of an inch.
The number of pixels per inch, on the other hand, depends on your monitor.
Thus, since twips are fixed to inches, and pixels per inch varies, twips per
pixel will also vary. Granted, pixels per inch will not vary much (which is
why you could get away with using a set number, like 15). But, as monitor
technology changes, the number of pixels per inch may increase, and, hence,
the number of pixels per twip may increase.
Or, if that were not the case, why would all of these code samples use API
calls to convert twips to pixels? They could just divide by 15 and be done
with it, right? :-)
Neil
"Neil"
news:iub3j.3341$fl7.2809@newssvr22.news.prodigy.net...
> Well, with all due respect, I believe you're wrong here. The twip isn't a
> device-independent measurement unit. It may be regionally-independent
> (i.e., isn't inches or centimeters), but it's not device-independent.
> "twip" = "twentieth of a point" (should probably have been spelled
> "twep" -- but that just sounds *wrong* :-) ). A point is defined as 1/72
> of an inch. Thus, a twip is a fixed value: 1/1440 of an inch.
>
> The number of pixels per inch, on the other hand, depends on your monitor.
>
> Thus, since twips are fixed to inches, and pixels per inch varies, twips
> per pixel will also vary. Granted, pixels per inch will not vary much
> (which is why you could get away with using a set number, like 15). But,
> as monitor technology changes, the number of pixels per inch may increase,
> and, hence, the number of pixels per twip may increase.
>
> Or, if that were not the case, why would all of these code samples use API
> calls to convert twips to pixels? They could just divide by 15 and be done
> with it, right? :-)
>
> Neil
That's at odds (I think) with what I read here:
"In VB 6 and earlier, all form measurements defaulted to a measurement
called the twip. A twip (twentieth of a point) is really a measure more
useful in traditional printing because it represents absolute distance. A
twip is 1/1440th of an inch or 1/567th of a centimeter. That is, there are
1440 twips to an inch or 567 twips to a centimeter.
If you're saying, "Huh?" in confusion, you're not the first. This archaic
measurement has been giving VB programmers fits for years.
(In fairness to Microsoft, some of their justification is that the twip is a
device-independent unit of measurement and in VB 6, two properties of the
Screen object, TwipsPerPixelX and TwipsPerPixelY, can be used to determine
the size of the display at run time. Using these properties, it's possible
to write code to make your forms more device independent.)"
I can't remember where that came from; I got it ages ago (could have been
from the vb.net site [as was])
Maybe I've interpreted it incorrectly. Not sure now.
"Neil"
news:iub3j.3341$fl7.2809@newssvr22.news.prodigy.net...
> Well, with all due respect, I believe you're wrong here.
Forget the due respect. I am wrong.
I did some googling this morning and found quite a lot of hits supporting
your take on it. It has been (for me) one of those 'first glance'
interpretations, where you accept something at face value and don't think it
through. Something I'm often guilty of.
I stand corrected. Thankyou for pointing it out.
"Stuart McCall"
news:fijik7$6ug$1$8300dec7@news.demon.co.uk...
> "Neil"
> news:iub3j.3341$fl7.2809@newssvr22.news.prodigy.net...
>> Well, with all due respect, I believe you're wrong here. The twip isn't a
>> device-independent measurement unit. It may be regionally-independent
>> (i.e., isn't inches or centimeters), but it's not device-independent.
>> "twip" = "twentieth of a point" (should probably have been spelled
>> "twep" -- but that just sounds *wrong* :-) ). A point is defined as 1/72
>> of an inch. Thus, a twip is a fixed value: 1/1440 of an inch.
>>
>> The number of pixels per inch, on the other hand, depends on your
>> monitor.
>>
>> Thus, since twips are fixed to inches, and pixels per inch varies, twips
>> per pixel will also vary. Granted, pixels per inch will not vary much
>> (which is why you could get away with using a set number, like 15). But,
>> as monitor technology changes, the number of pixels per inch may
>> increase, and, hence, the number of pixels per twip may increase.
>>
>> Or, if that were not the case, why would all of these code samples use
>> API calls to convert twips to pixels? They could just divide by 15 and be
>> done with it, right? :-)
>>
>> Neil
>
> That's at odds (I think) with what I read here:
>
> "In VB 6 and earlier, all form measurements defaulted to a measurement
> called the twip. A twip (twentieth of a point) is really a measure more
> useful in traditional printing because it represents absolute distance. A
> twip is 1/1440th of an inch or 1/567th of a centimeter. That is, there are
> 1440 twips to an inch or 567 twips to a centimeter.
> If you're saying, "Huh?" in confusion, you're not the first. This archaic
> measurement has been giving VB programmers fits for years.
>
> (In fairness to Microsoft, some of their justification is that the twip is
> a device-independent unit of measurement and in VB 6, two properties of
> the Screen object, TwipsPerPixelX and TwipsPerPixelY, can be used to
> determine the size of the display at run time. Using these properties,
> it's possible to write code to make your forms more device independent.)"
>
> I can't remember where that came from; I got it ages ago (could have been
> from the vb.net site [as was])
>
> Maybe I've interpreted it incorrectly. Not sure now.
>
Re. "device independent," I was wrong in saying that a twip isn't device
independent. It *is* device-independent, just like an inch or a centimeter
is. They're all the same regardless of which device you use. I was thinking
of "device-dependent," meaning it's a value that comes from the device
driver, and would be specific to that device.
Thus, I agree with the above that twips are device-independent, and was
wrong for saying they're not. But, that nomenclature gaffe aside, I believe
the rest of what I wrote was correct.
As for what MS is trying to say here: you got me. :-)
Neil