RE: setup.exe: Clues about missing scroll bar in package list

[Hugh Greene <cygw32 at tameter dot org>]

[Oops -- I first sent this reply direct to g.r.vansickle instead of to the
list.]

On Sunday 2002-11-24, g.r.vansickle@worldnet.att.net wrote:
> [Hugh Greene wrote:]
> > Hi there.
> >
> > [...]  I've seen some discussion about font size problems and losing the
> > scroll bar in the package list window, including a request for debug
> > suggestions.  Since this problem affects me, I thought I'd do some
> > digging.  [...]
> >
> > At a guess, window.cc (and maybe other places?) should be dividing the
> > result of GetDeviceCaps(hdc, LOGPIXELSY) by 96 (the naive default value
> > for dots per inch), instead of 72 (the standard-ish value of points per
> > inch).  There may be other similar scalings needed.  See
> >
> >   How to Write High-DPI Applications
> >     http://msdn.microsoft.com/library/default.asp?
> >     url=/library/en-us/dngdi/html/highdpiapp.asp
> 
> It looks like that's what I'm doing there though when I pass in this as the
> height to CreatFont():
> 
> -MulDiv (Pointsize, GetDeviceCaps (hdc, LOGPIXELSY), 72)
> 
> Albeit this essentially would be "how much to scale a design that assumes
> 72-DPI pixels".  [...]
>
> I got this from the Platform SDK's CreateFont docs, which say:
> 
> "For the MM_TEXT mapping mode, you can use the following formula to specify a
> height for a font with a specified point size:
> 
> nHeight = -MulDiv(PointSize, GetDeviceCaps(hDC, LOGPIXELSY), 72);"

Okay, a bit more digging ...

First I wondered whether you should be using the MM_TEXT mapping mode, since
it's not device independent.  I've seen other examples which use MM_TWIPS.

  Mapping Modes and Translations
  http://msdn.microsoft.com/library/default.asp?
    url=/library/en-us/gdi/cordspac_3qsz.asp

The next section

  Predefined Mapping Modes
  http://msdn.microsoft.com/library/default.asp?
    url=/library/en-us/gdi/cordspac_0vxv.asp?frame=true

gives the example of chart drawing and says that "If MM_TEXT is used instead
of [any of the other predefined mappings], a chart that appears circular on a
VGA display would appear elliptical on an EGA display and would appear very
small on a 300 dpi (dots per inch) laser printer."


I then noticed the res.rc file in the source and tried loading it up in my old
copy of Visual C++.  I had to replace a "#" with "//", where it was intended
for commenting-out but was treated as a preprocessor directive, but apart from
that it loaded fine.  In particular, the font size shown in VC++ matches what
I see when I run setup.exe, so it may not be a font scaling problem after all.
Also the size and placement of all the controls is the same.

However, the size of the dialogs in the resource file is wider than the window
I see at runtime (and possibly slightly less tall, even accounting for the
back/next/finish buttons at the bottom).

The resource size (for most windows) is 317 x 179 dialog units (dlu), which I
see in the SDK docs is the size for a "backwards compatible" wizard.  The
actual size of the window in VC++ (as shown by Spy++) is 799 x 485, with a
"client rect" size of 793 x 448, so the pixels/dlu ratio on my screen is 2.5.
However, the size of the top-level window at runtime is 751 x 592, client rect
745 x 555 -- taller and less wide.

Looking at the source, I couldn't see what, if anything, chooses the size for
the top-level window.  Is it possible that the code is choosing the wrong
size, or just using a default when it should be choosing a size?  Or maybe the
pixel size is deduced from the dlu size based on the font set for
something-or-other, but that font isn't being set to the same font as used in
the rest of the dialog, or isn't being set up early enough?


Hope that's useful,
Hugh