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

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" <nospam (AT) nospam (DOT) net> wrote

If your form instances are the only visible objects, then you ought to be
able to use this:

DoCmd.RunCommand acCmdWindowCascade

"Stuart McCall" <smccall (AT) myunrealbox (DOT) com> wrote


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" <smccall (AT) myunrealbox (DOT) com> wrote

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" <nospam (AT) nospam (DOT) net> wrote

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" <nospam (AT) nospam (DOT) net> wrote

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" <smccall (AT) myunrealbox (DOT) com> wrote

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