Overriding Windows display settings - vb6
Brigand
Basically, I am using a form and printing characters at specific
locations on the form:
eg
form1.currentx = 10
form1.currenty = 10
form1.print "text"
This works perfectly fine 90% of the time. The problem occurs for
users who have changed the dpi settings, or turned on some of the ease
of access settings that make the fonts biggers, or raise the contrast
or whatever. As far as my program goes, the end result is the text no
longer appears where I want it to. The relative positions of the text
are ok, but the drawn graphics do not get
Is there some way to override these settings in your programs, and
force them to display in a constant font and size??
Mike Williams
news:62ddb9d6-ee83-4100...@c29g2000yqd.googlegroups.com...
> Run into a minor problem that I'm not sure if I can fix easily.
> Basically, I am using a form and printing characters at specific
> locations on the form:
> form1.currenty = 10
> form1.print "text"
> This works perfectly fine 90% of the time. The problem occurs for
> users who have changed the dpi settings, or turned on some of the
> ease of access settings that make the fonts biggers, or raise the
> contrast or whatever. As far as my program goes, the end result is
> the text no longer appears where I want it to. The relative positions
> of the text are ok, but the drawn graphics do not get
>
> Is there some way to override these settings in your programs, and
> force them to display in a constant font and size??
It looks like some of your intended post is missing there (the bit after the
'graphics do not get' phrase) but I think I can see what you are saying. The
very first thing you need to do, before you even consider doing anything
else, is to make sure that your program is not messed up when it is run on
Vista and Win7 machines where the user has set a large dpi setting (usually,
but not always, larger than 120 dpi) and where they have not placed a tick
in the box 'Use WindowsXP Style DPI Scaling'. In such cases, unless you do
something about it, Windows will lie to your VB program about the dpi
setting and it will lie extremely convincingly, affecting not only VB
properties and methods but also any GDI function you might be using. It will
tell your VB program that the machine is running at 96 dpi, even though it
is not! So, your VB code will run and do its stuff just as though there were
96 dpi on the machine (even though it is not true!) and Windows will draw
all your program's output into a hidden backbuffer, from where it will then
stretch it onto the actual display so as to enlarge it to suit the actual
dpi setting of the machine. This not only produces fuzzy text and other
things but it can also cause all sorts of other problems.
In order to prevent the above stuff from causing problems you need to make
sure that your VB program declares itself as being DPI Aware. This will tell
Windows not to mess about and not to lie to your program about the dpi
stuff. You also need to make sure that you write your code in such a way
that it actually is DPI aware of course (that it checks the dpi setting of
the machine and acts accordingly when it feels the need to do so), but from
the tone of your post I think you are probably already doing that. There is
an API function called SetProcessDPIAware which you might come across, but
this function is in many cases not reliable because (and I think this is the
case with VB programs) a program caches lots of information about the
machine's dpi and other settings /before/ the very first line of the actual
code is executed, so by the time your code calls the SetProcessDPIAware
function it is already too late. You can overcome this problem by instead
using a manifest, because Windows acts on the contents of the manifest
before it even starts running your program code. The manifest needs to
declare that your program is DPIAware. The manifest can either accompany
your program as a seperate file, or it can be embedded into your .exe file
(the latter is the best way in my opinion). There is a program out there
called MMM which will do this stuff for you (and a lot more) automatically
(as long as you set it up accordingly). You can download it at:
It is quite a while since I used MMM and the last time I did so I noticed
that the SetDPIAware section which it embedded into the manifest worked fine
On Vista but did not work at all on Win7. I posted a comment and a fix about
this problem on the MMM site some time ago but I have not since been there
and so I do not know whether their current version has been fixed.
Basically, my fix was as follows:
1. Replace the line:
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
. . . with the line:
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"
xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" >
2. Replace the section:
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings
xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</windowsSettings>
</application>
. . . with the section:
<asmv3:application>
<asmv3:windowsSettings
xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
Anyway, there are various other things I think I should mention regarding
your apparent quest for text which aligns and sizes and positions correctly
in relation to other graphics which you are drawing (point sizes versus
pixel sizes and all sorts of things), but I think it might be wise to leave
that until you have sorted out the DPI Aware stuff. Post again when you have
done that.
Mike
Mike Williams
news:62ddb9d6-ee83-4100...@c29g2000yqd.googlegroups.com...
> This works perfectly fine 90% of the time. The problem
> occurs for users who have changed the dpi settings
Incidentally, further to my previous response, when you have created your
manifest (either as a separate file alongside your VB compiled exe or
preferably embedded into your exe) you need to check that your manifest is
actually working before you go any further. Do not just assume it is
working. You can check it by temporarily adding the following line into your
Form load event or wherever:
MsgBox Me.ScaleX(1, vbInches, vbPixels) & " dpi"
Then temporarily set both a Vista and a Win7 machine to a Custom 150% (144
dpi) setting making sure there is NOT a tick in the box against "Use XP
Style DPI Scaling". If the above code still reports 96 dpi on either of
those machines then your manifest is not working properly and you'll need to
fix it. It is not worth providing a solution to your current problem until
you have done those things.
Mike
Ivar
Nice to see the old graphics guru is still reading this NG.
I've used GDI's a lot in various apps and always taken the DPI Setting in to
consideration and always worked well.
I'm now using Winders 7 64 bit ultimate and I can't find any way of
adjusting the DPI to anything other than 96 or 120
Can you please explain how I can screw things up in Winders to see how the
old apps handle Winders 'Lying' to me.
Anticipating a long winded waffle of a reply :-)
Ivar
Mike Williams
"Ivar" <ivar.eks...@ntlworld.com> wrote in message
news:WuN1q.144227$Sr.7...@newsfe12.ams2...
> I'm now using Winders 7 64 bit ultimate and I can't find any
> way of adjusting the DPI to anything other than 96 or 120
> Can you please explain how I can screw things up in Winders
> to see how the old apps handle Winders 'Lying' to me.
First make sure that your machine is actually currently running with an Aero
desktop (so that the borders of open folders and other windows have that
glossy translucent look). Then right click the desktop and select
Personalize and then click the little Display link (usually near the bottom
left of the dialog window). In the Display dialog you should see some option
buttons (typically three of them for setting the dpi to small, medium and
large). Ignore those buttons and instead click the little Set Custom text
Size (DPI) link at the left. You should see a quite large drawing of a ruler
displaying inches (my wife always tells me off for calling them rulers, she
says rulers are Kings and Queens!). Just above the ruler there should be a
little drop down Combo with various options, typically 100%, 125%, 150% and
200%. Select the 150% option, which is the equivalent of 144 dpi. If you
cannot see a 150% option then instead click the ruler and drag it left or
right, periodically releasing the mouse button, until the text underneath it
reads 144 pixels per inch. Now, and this is a very important step, make sure
there is NOT a tick in the box against Use Windows XP Style DPI Scaling. If
there is a tick in that box then remove it. Click OK and then Apply and then
click the button to allow Wimdows to either log off or restart.
Mike
Ivar
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.
Thanks Mike
Ivar
Mike Williams
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
GS
Thanks so very much for sharing this! This is absolutely the most
detailed and well written content I've ever read on this subject!
It certainly does explain a lot of display behaviors I've seen on the
newer machines (laptops specifically). I'd be very interested in
knowing the 'how to' and 'what' of the solution you suggest. (I know
nothing about using manifests)
--
Garry
Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Nobody
> Mike,
> Thanks so very much for sharing this! This is absolutely the most detailed
> and well written content I've ever read on this subject!
>
> It certainly does explain a lot of display behaviors I've seen on the
> newer machines (laptops specifically). I'd be very interested in knowing
> the 'how to' and 'what' of the solution you suggest. (I know nothing about
> using manifests)
He already explained how to add the manifest in his first response.
GS
Thanks! I missed reading that one...
Brigand
the time to respond in such detail :)
Mike Williams
>> Nobody submitted this idea :
>> He already explained how to add the manifest in his first response.
>
> Thanks! I missed reading that one...
Just one final note regarding the required modification of the manifest
which I mentioned in my first response in this thread. Personally I have had
limited success with some manifests when the manifest file accompanies the
compiled exe file. I've had times when the manifest clearly does not work,
even after making sure that it is named correctly and that it lives in the
same folder as the exe. This problem can often (but not always) be fixed
simply by creating a new folder and then by copying both the exe file and
the manifest file together into the new folder. It sounds rather weird I
know because clearly the content of the files themselves is not changed
during a simple copy process, and the only thing I can think of, which is
just a wild guess, is that the Windows Explorer extended file properties are
changed by this behaviour, for some reason causing the copies to work even
though the original did not. Anyway, there is no point in spending time on
trying to solve that problem because you can instead embed the manifest into
the exe. So far, in all the various tests I have carried out, the suitably
modified MMM dpiAware embedded manifest works fine.
I don't actually know how to correctly embed a manifest into an exe myself
(maybe someone else here does?) but the MMM program which I mentioned and
which you can get from http://mmm4vb6.atom5.com/ can do it if you click the
appropriate checkbox. The only problem is, as I mentioned in my first
response, the DPI Aware section in the MMM produced manifest does not work
reliably or at all in Windows7 as it stands and needs to be modified in the
way I have already explained. The data used by MMM is in a resource file and
so before you can use MMM to create and embed a modified manifest into your
compiled exe you need to edit the resource file. Fortunately the author,
Robert Riemersma, has released the source code for MMM and has granted a
licence which will clearly allow you to make changes to it for your own use.
If you open up the MMM VB project, and if you have the VB6 Resource Editor
Add-In enabled, you will see that the resource file contains about ten
resource items and if you look in the MMM Res folder you will see ten .txt
files which match them. You need to manually edit and save the
manifest.apphead.txt file and the manifest.dpiaware.txt file so that
together they will produce the suitably modified manifest. Then you need to
click the Add Custom Resource button in the VB6 Resource editor and load in
the modified manifest.apphead.txt file from the MMM Res folder. Then right
click the existing APPHEAD resource item and delete it and right click the
newly additem item in the Resource Editor and select Properties and set its
Type to "TEXT" (including the quotes) and its ID to "APPHEAD" (including the
quotes) and its language to English (United States). Then carry out a
similar process to add the modified the dpiaware.txt file, using the Type
"TEXT" and the ID "DPIAWARE" and the language English (United States).
Finally compile MMM so that it overwrites the existing MMM.exe file.
When you run the modified MMM.exe file on your first test project make sure
you place a tick in the Include dpiAware checkbox but that you do /not/
place a tick in the Embed Manifest Into EXE checkbox. This will enable you
to use NotePad to examine the manifest file so that you can make sure you
carried out the above process properly and that it actually does produce the
correctly modified manifest file. Thereafter you should make sure that you
do place a tick in the Embed Manifest Into EXE checkbox.
Mike
-mhd
>I don't actually know how to correctly embed a manifest into an exe myself
>(maybe someone else here does?) but the MMM program which I mentioned and
>which you can get from http://mmm4vb6.atom5.com/ can do it if you click the
>appropriate checkbox
I use Manifest Creator but not sure if it helps with the DPI issue.
http://www.vbforums.com/showthread.php?t=606736
-mhd
Mike Williams
"-mhd" <not_...@invalid.com> wrote in message
news:pmfl4713p2h4d873q...@4ax.com...
I use Manifest Creator but not sure if it helps with the DPI issue.
http://www.vbforums.com/showthread.php?t=606736
Thanks, I'll have a look at that later. I've already solved the manifest DPI
Aware issue though and at the moment the only manifests I really use are
those to create portable apps and which also include a fully working DPI
Aware section that works in both Vista and Win7, and my own copy of MMM
which I have modifed in the way I described allows me to do that with just a
few mouse clicks. I'll definitely have a look at your Manifest Creator link
though, which I assume will allow me to create my own manifests in NotePad
and which Manifest Creator will then embed in the compiled VB6 project for
me. Thanks.
Mike
Tony Toews
<Mi...@WhiskyAndCoke.com> wrote:
>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!
Hehehe Thanks for the lengthy posting. Much appreciated.
Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Deanna Earley
> Run into a minor problem that I'm not sure if I can fix easily.
>
> Basically, I am using a form and printing characters at specific
> locations on the form:
>
> eg
>
> form1.currentx = 10
> form1.currenty = 10
> form1.print "text"
A quick fix if you're working around fixed pixel size objects, you will
need to switch to using pixels in your form (setting scalemode to vbpixels).
If you've already set this, then you've most likely hit the "odd stuff"
the VB runtime/windows is doing at unusual (e.g. 112%) DPI settings
which seems to break user control sizing (among others).
Without going the whole hog and using Windows 7 DPI aware, I found no
immediate fix for this.
--
Dee Earley (dee.e...@icode.co.uk)
i-Catcher Development Team
http://www.icode.co.uk/icatcher/
iCode Systems
(Replies direct to my email address will be ignored.
Please reply to the group.)
Mike Williams
news:j30c3u$hd2$1...@speranza.aioe.org...
> A quick fix if you're working around fixed pixel size
> objects, you will need to switch to using pixels in
> your form (setting scalemode to vbpixels).
When is a pixel not a pixel, that is the question. Was it Shakespeare who
said that?
Mike
ralph
Not sure, but I believe it was Freud who said "Sometimes a pixel is
just a pixel".
-ralph
-mhd
Paraphrasing Winston Churchill responding to Bessie Braddock "I may be drunk now
but you will still be a pixel in the morning".
Schmidt
Hmm, could very well be...
... googling ...
Found it:
According to Swami X, this is indeed the question,
and he says: "'Yes' is the answer."
Olaf
ralph
Hmmmm, I came up with "42".
-signed
Stuck in the Eighties
Schmidt
If you want to look at the problem in that larger context,
then of course: "Yes, indeed - no question!" is my answer. ;-)
Olaf
Dr J R Stockton
v...@4ax.com>, Sat, 27 Aug 2011 11:58:19, -mhd <not_...@invalid.com>
posted:
>Paraphrasing Winston Churchill responding to Bessie Braddock "I may be drunk now
>but you will still be a pixel in the morning".
Scan the Wikipedia pages on Bessie Braddock and Nancy Astor for
"Churchill".
--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike 6.05 WinXP.
Web <http://www.merlyn.demon.co.uk/> - FAQ-type topics, acronyms, and links.
Command-prompt MiniTrue is useful for viewing/searching/altering files. Free,
DOS/Win/UNIX now 2.0.6; see <URL:http://www.merlyn.demon.co.uk/pc-links.htm>.