Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.basic.visual.misc > #366

Re: Overriding Windows display settings - vb6

Show all headers | View raw

"Ivar" <ivar.ekstromer000@ntlworld.com> wrote in message 
news:jKP1q.161371$Z04.100311@newsfe07.ams2...
> I did what you said, and yep, there is an issue with scaling under
> those circumstances. Not a biggie, things don't look to bad but I
> can see some (not all) incorrect scaling But, If anyone wants to
> set up their screen to look so hideous then they deserve ugly
> looking apps. That's my excuse for not looking through how
> ever may thousands and thousands of code lines looking for
> the scaling subs.

You might not need to do that Ivar, depending on how you have written your 
code. The thing is, there are three main things at work here. Firstly, 
display technology has rapidly advanced over the years and the pixel density 
of screens has become much greater. Secondly, the physical size of a screen 
has not changed a great deal in the same time period. Okay, it has done so 
with desktop monitors but most computer users these days have laptops, and 
laptop screens of today are physically no larger than the desktop displays 
of old. Thirdly, the average age of a typical computer user has increased 
significantly, with even people of my own advanced years (!) regularly using 
them, many of whom do not have the eyesight of the typical spotty teenage 
computer user of years gone by ;-)

This has resulted in the physical size of desktop elements in Windows itself 
and in most applications being far too small for comfort for an ever 
increasing number of users. I know there are numerous ways of increasing the 
size of specific elements, icon size and icon font and all sorts of other 
things, but none of those methods are really effective for everything on the 
display. One thing that does have an effect on the entire display for all 
applications and which does make everything larger for the user is to change 
the desktop pixel resolution in the graphics card driver. Most displays 
these days are LCD which have a clearly defined hardware resolution, and if 
an LCD display has a hardware resolution of perhaps 1680 x 1050 pixels then 
you can if you wish use Control Panel to change the resolution to perhaps 
1152 x 720. This does not of course change the actual hardware resolution on 
the machine, but it changes the software resolution, with the graphics card 
sorting it out for you. As far as pixel area is concerned, this would result 
in everything on the display being twice the size it was before (each 
software pixel would be twice the area), which would be much more 
comfortable for many people. The graphics card would effectively create the 
1152 x 720 software pixels using the available 1680 x 1050 hardware pixels.

However, in the above case each software pixel would be a bit fuzzy and they 
would of course be larger than the hardware pixels. So, although everything 
on the display is now large enough to be comfortably seen by someone to whom 
the original display was difficult to see, all the 'crispness' would be gone 
and they would have effectively swapped one problem for another!

That's why many people these days, quite sensibly encouraged by Micro$oft, 
use an alternative method of increasing the size of everything on their 
display. That of course is the thing we have been talking about, which is to 
change Windows dots per inch resolution (or rather dots per logical inch 
resolution) from the standard 96 dpi to something larger, perhaps 120 dpi or 
144 dpi (or one of the many other available values). This is becoming more 
and more common these days, and you really do need to write your VB code so 
that it deals with it properly. Anyway, changing the software resolution in 
such a manner has the effect (or is supposed to have the effect, if 
everything is written properly) of increasing the size of all screen 
elements. The idea is that the display continues to run at its full crisp 
native 1680 x 1050 hardware resolution and any program which (for example) 
wanted to draw a 12 point font would effectively ask Windows how many pixels 
there are in a point on this specific machine and it would draw the font at 
the appropriate pixel size (this is what VB6 does for example). On the 
Windows 96 dpi machine it would be told that there are 1.33 pixels in a 
point (since there are always 72 points to an inch) whereas on the Windows 
144 dpi machine (where the user has used Control Panel to run his system at 
150%,) it would be told that there are 2.00 pixels in a point, and so it 
would draw the font at an appropriately larger pixel size.

Similarly, a program which wanted to draw a 0.9 logical inch wide button 
would draw it at a width of 86 pixels on the 96 dpi machine but would draw 
the same 0.9 inch button at a width of 130 pixels on the 144 dpi machine. 
Again, this is what VB6 itself does. In this way, if all programs behave 
properly and if they check the system's current dpi setting, everything on 
the user's machine will be larger and much easier for them to see. VB6 
itself does this, and the only thing that messes it up is when programmers 
do not take account in their code of what VB6 has done and if their code 
does not behave accordingly.

The thing is, even though everything on the display is larger the display is 
still running at its full native hardware pixel resolution and so the user 
has got exactly what he was after (larger stuff on the screen which he can 
more easily see) but it has been achieved by keeping the software pixel 
density the same as the hardware pixel density (text and buttons and things 
just use more pixels), and so he has got an easy to see display but without 
any of the fuzziness of the older method of changing the screen resolution.

So, even in WinXP there was a need to make sure your VB6 code behaved 
properly in accordance with the current dpi settings of whatever machine 
your code was running on, and which complied with what VB6 itself was doing, 
and you really would be well advised to write your code accordingly. Some 
programs of course did not do this, unbelievably including some of Micro$oft's 
own programs and even some of Micro$oft's own Windows dialogs!!

So, in order to attempt to fix this 'unbehaving programs' problem, Vista and 
Win7 'muddied the waters' a little and Micro$oft, in their infinite 
wisdom(!), decided to 'help the poor idiotic programmer' (including 
themselves incidentally!) and to have Windows attempt to 'do the things that 
the idiotic programmer had failed to do' !!!! What they did was to introduce 
a new setting (user configurable) which allowed the user to select a larger 
dpi size (perhaps 144 dpi instead of the standard 96 dpi) but to give the 
user an additional choice which instructed the Windows operating system to 
attempt to fix the things that the idiotic programmer (including some 
Micro$oft idiotic programmers!) had failed to do. They did this by 
introducing a new 'dpi virtualization' mode which the user could either 
select or not select (this is the 'Use Windows XP Style DPI Scaling' 
checkbox that I mentioned in my previous post).

If the user had specified something larger than 96 dpi and if he had NOT 
ticked the 'Use Windows XP Style DPI Scaling' on his machine then the system 
would use the new Vista and Win7 'dpi virtualization' mode for the display. 
In effect, on such a machine when your VB6 compiled exe started (or when any 
other program started) then Windows would start off by examining that exe 
and it would effectively ask that exe whether it was already 'dpi aware'. If 
the exe reported that it was in fact 'dpi aware' (in other words if the exe 
said that it knows all about this dpi stuff and was going to behave 
accordingly) then Windows would run that exe as normal (on the 'greater than 
96 dpi' machine). However, if your VB6 compiled exe (or any other program) 
failed to report that it was 'dpi aware' then Windows would (as far as that 
specific exe is concerned) decide to 'lie to that program' about the machine's 
dpi setting. It would in fact tell that program that the machine was running 
at 96 dpi, even though it was not! This lie would be done very convincingly, 
and all your VB6 methods and all the GDI routines which you used would take 
part in this lie.

The result of course would be that all the graphic output of your program 
would be drawn as though there were 96 dpi on this machine, even though the 
machine might actually be set to 120 dpi or 144 dpi. That of course in 
itself would not be helpful at all, because the output from your program 
would not be 'expanded' in the way that the user expected the output of all 
programs to be (because he had set his machine to 120 or 144 or whatever 
dpi). However, and here is how the trick works, under these circumstances 
Windows would actually draw all your program's graphic output to a back 
buffer in memory, instead of drawing it straight to the display. It would 
then 'stretch' that back buffer (in much the same way that StretchBlt is 
capable of) onto the actual real display so that its pixel size was larger 
on the actual display than it was in the back buffer, thereby making your 
output a larger pixel size on the display (in the ratio of 120/96 or 144/96 
or whatever suits the user's dpi setting).

Anyway, the above 'lie to your program and draw its output into a back 
buffer and then stretch that buffer onto the display' is what you want to 
avoid, because it results in fuzzy text and all sorts of other problems, 
even in code that has been written with no knowledge of dpi setting and 
stuff, and it can cause even more problems with code that has been written 
properly!

So, what you really need to do is write your code in such a way that it 
actually DOES take account of the user's dpi settings (96 dpi or 120 dpi or 
144 dpi or whatever) and you ALSO need to make your exe 'tell' Windows that 
you have done so, and that your app is actually 'dpi aware'. This will 
prevent Windows from doing any of the 'lie to this program' stuff. It can 
only be done effectively in a manifest (either embedded into your exe or as 
a separate manifest file), because the alternative of using the API 
SetProcessDPIAware function does not usually work because Windows has 
already cached lots of this dpi stuff before even the first line of your 
code gets executed, whereas Windows examines and deals with the manifest 
before it goes anywhere near your code. You really do need to include this 
manifest, Ivar. Your program will be at the mercy of Micro$oft, and your 
output will be 'fuzzy' and lots of other problems will occur on lots of 
machines if you do not.

Actually, Ivar, I really did not intend to write all this long winded stuff, 
but you were right when you implied that I would not be able to resist doing 
so! The upshot of it all of course is that, despite your protestations, I 
really do think that you need to add the appropriate 'I am dpi aware' 
manifest to your program. When you have done it then you need to check how 
your program runs on various machine, including the machines we have already 
talked about which run at perhaps 120 or 144 dpi and which do NOT have a 
tick in the box 'Use Windows XP DPI Scaling".

Anyway, having produced all this 'waffle' which you were half expecting, I'll 
leave it to you decide what to do. If you want an example of a suitable 'dpi 
aware' manifest that you can create in NotePad and that you can include in 
the same folder as your compiled VB exe file then post again. If you do 
decide to go this route then it is possible to embed such a manifest into 
your compiled exe to avoid the need to distribute separate files.

Mike

Back to comp.lang.basic.visual.misc | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Overriding Windows display settings - vb6 Brigand <markashall@hotmail.com> - 2011-08-12 12:01 -0700
  Re: Overriding Windows display settings - vb6 "Mike Williams" <Mike@WhiskyAndCoke.com> - 2011-08-12 21:23 +0100
    Re: Overriding Windows display settings - vb6 "Ivar" <ivar.ekstromer000@ntlworld.com> - 2011-08-14 11:33 +0100
      Re: Overriding Windows display settings - vb6 "Mike Williams" <Mike@WhiskyAndCoke.com> - 2011-08-14 13:30 +0100
        Re: Overriding Windows display settings - vb6 "Ivar" <ivar.ekstromer000@ntlworld.com> - 2011-08-14 14:06 +0100
          Re: Overriding Windows display settings - vb6 "Mike Williams" <Mike@WhiskyAndCoke.com> - 2011-08-14 23:36 +0100
            Re: Overriding Windows display settings - vb6 GS <gs@somewhere.net> - 2011-08-14 20:03 -0400
              Re: Overriding Windows display settings - vb6 "Nobody" <nobody@nobody.com> - 2011-08-15 09:30 -0400
                Re: Overriding Windows display settings - vb6 GS <gs@somewhere.net> - 2011-08-15 10:58 -0400
                Re: Overriding Windows display settings - vb6 Brigand <markashall@hotmail.com> - 2011-08-16 05:42 -0700
                Re: Overriding Windows display settings - vb6 "Mike Williams" <Mike@WhiskyAndCoke.com> - 2011-08-16 14:01 +0100
                Re: Overriding Windows display settings - vb6 -mhd <not_real@invalid.com> - 2011-08-16 15:04 -0400
                Re: Overriding Windows display settings - vb6 "Mike Williams" <Mike@WhiskyAndCoke.com> - 2011-08-16 22:02 +0100
            Re: Overriding Windows display settings - vb6 Tony Toews <ttoews@telusplanet.net> - 2011-08-19 15:34 -0600
  Re: Overriding Windows display settings - vb6 "Mike Williams" <Mike@WhiskyAndCoke.com> - 2011-08-13 15:27 +0100
  Re: Overriding Windows display settings - vb6 Deanna Earley <dee.earley@icode.co.uk> - 2011-08-23 15:05 +0100
    Re: Overriding Windows display settings - vb6 "Mike Williams" <Mike@WhiskyAndCoke.com> - 2011-08-26 17:48 +0100
      Re: Overriding Windows display settings - vb6 ralph <nt_consulting64@yahoo.net> - 2011-08-26 22:06 -0500
        Re: Overriding Windows display settings - vb6 -mhd <not_real@invalid.com> - 2011-08-27 11:58 -0400
          Re: Overriding Windows display settings - vb6 Dr J R Stockton <reply1134@merlyn.demon.co.uk> - 2011-08-28 18:48 +0100
      Re: Overriding Windows display settings - vb6 Schmidt <sss@online.de> - 2011-08-27 19:23 +0200
        Re: Overriding Windows display settings - vb6 ralph <nt_consulting64@yahoo.net> - 2011-08-27 16:56 -0500
          Re: Overriding Windows display settings - vb6 Schmidt <sss@online.de> - 2011-08-28 01:33 +0200

csiph-web