Hi

Visual Basic changes the display according to the fonts in system control
("small fonts/large fonts"). The best to deal with this problem I have found
until now is go through all controls on the gui and change their positions
if large fonts are used. Does anybody know of a better way (e.g. use a
property to switch between small and large fonts)?

Changing the settings on the computers of our users is no option.

Thanks
  Stefan

Stefan



The preferred solution is to find users with large fonts selected and hunt
them down like dogs then terminate them with extreme prejudice. Regrettably
this is not always a viable option.



How you approach this depends on how your forms are laid out and what
elements are found on your form, you'll find if you have pictures on your
form they will normally not resize, while everything else does which can
make it all look awful.



The method (I think) you are using is probably the best solution, but it
gets worse, much worse, many graphics cards allow users to set a custom font
size which can be anything at all so you may want to find the true
twips/pixel value as it can be values other than 15 or 12. It does not even
have to be an integer even though screen.TwipsPerPixelX (& Y) always returns
a whole number. My method of getting the true value for this is to get the
screen width (& height) in pixels and in twips and divide one into the other
and then use those values.


Best Regards
Dave O.

Show quoteHide quote

Too bad, because... http://www.divsoft.com/lfs

Yep. I've seen that before Jeff. It is a little bit contrived though, and
there is a fair bit more to it than the author expresses. When I say
"contrived" I don't mean that the author deliberately chose values that
tended to prove his point, but simply that the values he happens to have
used did that for him purely by chance.

The effects vary from one machine to the next of course, but generally in
Windows all True Type fonts (including the Verdana 8 point he is using) are
required to be "whole pixel" values, so that on most machines if you ask for
8 point Verdana you will actually get 8.25 points. With some fonts there are
also other considerations, but the "whol pixel font size" one is always
present. If you ask for 10 point Verdana (25 per cent bigger) you will
probably get 9.75 points. So, the relationship between the fonts you
actually get is not the same as the relationship between the fonts you asked
for.

Similar considerations also come into effect when you switch between
"Windows small fonts setting" (96 dpi) and "Windows large fonts setting"
(120 dpi). So in the author's specific case (8 point Verdana) he would quite
probably see the effect he described (the size of the "container" or button
or whatever expanding by a larger percentage than the size of the font which
it contains). If he had instead chosen 9 point Verdana then he might not
have seen a difference at all, and for 10 point Verdana he would probably
have experienced the opposite (where the font size increased by a larger
percentage than its container). For example, on my own system I see
something like the author himself describes when using 8 point Verdana. In
my case the height of a Command Button increased by 25 per cent, as
expected, when changing from 96 dpi to 120 dpi, but the height of the font
increased by only 12 per cent (similar to the author's description), but at
9 points there was virtually no difference at all between the two, and at 10
point Verdana I had the opposite effect, where the height of the Command
Button increased by 25 per cent but the height of the font increased by 33
per cent.

In fact, on one of my WinXP SP2 systems a standard Command Button using the
standard 8 point MS Sans Serif changed the size of the Command Button by
exactly 25 per cent when changing from 96 dpi to 120 dpi, and the size of
the font changed by about 18 per cent (8.25 actual to 9.75 actual). This is
what you would normally expect, and the Command Button's text would of
course still fit onto the button. However, on my other WinXP SP2 system
(using a different graphics card) the change from 96 dpi to 120 dpi refused
to take effect at all as far as the size of Forms and Buttons (and other
stuff) is concerned, so that the Command Button was the same size in both
cases. This might not seem too bad at first, because you would expect that
if the Form and Command Button sizes were not changed then the font sizes
would not change either. This wasn't the case though, simply because at that
dpi setting the 8 point (8.25 point) font size for MS Sans Serif became
unavailable, and so the system had to choose the first available
alternative, which was 10 point (9.75 point actual). This caused the Command
Buttom to remain the same size at both the 96 dpi and the 120 dpi settings,
but the font size to increase by about 20 per cent, sao that the text in my
specifric case no longer fitted onto the button.

I do agree with the author on one point though, and that is I think there
are better ways for people with poor eyesight to change their system than
simply changing the dots per inch setting. However, it doesn't really matter
what we say as programmers, it is a fact of life that some people, no matter
how much you dislike it, will use a different Windows font size (by that I
mean a different pixels per inch setting), and I think you should write your
code to accommodate them. In fact, I know of people with perfectly good
eyesight who use something other than the standard "96 dpi Windows small
fonts setting". They do it because they use drawing or publication
applications which do not allow then to choose any "display sizes" they
wish. For example, an application might only allow the user to choose a
"zoom" of page width, full page, 25 per cent, 50 per cent, 100 per cent,
etc). Some applications do not allow you to use user specified
magnifications of (say) 78.5 per cent, but virtually all of themn allow you
to use 100 per cent. So, if those people want a document to be exactly the
same size on the display as it is in real life (so they can hold a page up
to the screen, for example) then they must choose 100 per cent (or some
other fixed magnification). In such cases they can use the Windows "dots per
inch" stuff in Control Panel to select a dots per inch setting where (on
their specific monitor) a "page" shown at 100 per cent is exactly the same
physical size (on the monitor) as a real piece of similarly sized paper held
up against the screen. This helps some people. In fact if to facilitate this
if you choose "custom size" Windows will present you with a ruler (I keep
getting told off for calling a "rule" a "ruler"!) that you can simply "drag
to different sizes" until it matches a real ruler held against the screen.

Anyway, what I'm really saying is that if you're writing a VB (or whatever)
application then you shouldn't really expect your users to comply with your
own rulings in these respects. You should instead allow them to do whatever
they want to do and your application should modify itself accordingly. To do
this you really need to add code that examines everything at run time to see
what it is set to and then modifies its own screen output accordingly.

Life would be much simpler if there were no adjustable display settings in
Windows, but sadly (at least sadly for VB6 programmers) that isn't the case.
VB6 stores all of your settings (positions and sizes of controls, etc) using
twips (in both the project and the form etc files and also in the exe
files). It does this regardless of ther various ScaleModes you are using. In
fact in the frm files, for example, it stores most settings using *both*
your own Scale values and twips, but it uses the twips when it comes to draw
your Form. You need to account for it. Other applications (Delphi, for
example, and VB.net as far as I know) do not do this, but even they can be
upset by the various things that can happen differently on different
systems. So, I'd advise run time examination in all cases.

Mike

Form_Load and SetFocus
What line does the error start on?
Setting background in vscrollbar to gray
How many ActiveX processes can I have?
Center text with PRINT
Visual BASIC has encountered a problem ...
ADODC control - form settings
File System Object
My screen stays on background
need help with how to format a cell in Excel with VB6