I'm not sure if this is a Windows feature or it is a part of the video driver, but when you change screen resolutions you have the option of making the font size 125% or 150% of normal. This causes me endless headaches when designing forms because one woman in the office has her's set to 125%. Before I publish I must set my development machine to match her resolution to make sure everything is visible. This means logging off and on.
Is there a way to have VB.Net ignore that so it does not increase the font size and stretch controls to accommodate? I've noticed that it does not appear all programs increase font size.
Greg
Related
Ok so i know this seems to have been asked a million times but!!!!!!
I have written an application in VB.NEt utilizing windows forms, my screen is set to 100% scaling and all works A OK!! Until a user runs the application on a PC where the scale is set at 125% or 150% and the windows form becomes too big for the screen and they can not access certain features of the form. The same applies if they have two monitors one set at a different scale to the other, if you drag it over the the high percentage screen the form becomes too big. This clearly has something to do with AutoScaleMode and DPI Aware but having tried all combinations the issue remains!!! :-( and ideas??
I have tried changing AutoScale Mode to DPI, Inherit, Font and None and i have trued changing DPI Aware to False in the Windows settings.
wxWidgets 3.1 claims to fix the Windows High DPI issues. It works too but I see blur UI (fonts/bitmaps) looks stretched.
I went through the https://learn.microsoft.com/en-us/windows/desktop/hidpi/high-dpi-desktop-application-development-on-windows
I did the manifest changes to make my application DPI-aware, it removed the blur effect but application layout went wrong, every layout looks smaller (unusable UI).
Note* issue more vigilant on 3K and 4K system. Hardcoded pixel sizes are not scaling (like 400px width button, 500pixel width panel etc).
wxWidgets gives you a (relatively simple) way to make your application work in high DPI, but doesn't -- and can't -- do it automatically for you, in particular only sizer-based layouts without hardcoded pixel sizes will work correctly and you do need to provide your own higher definition artwork.
Concerning the existing pixel values, the simplest (even though not really the best) way to make them work better is to put FromDIP() calls around them.
Also note that you don't need to do anything special for pixel values in XRC, they're already interpreted as being resolution-independent pixels and are scaled according to the DPI automatically.
I'm writing a wxWidgets (3.1.0) app that is supposed to work on windows and mac.
On windows when i set the scaling of the text to more than 100% the sizes of my controls get all messed up. I have a dpi manifest that says my app is dpi aware. I also set the font pixel size on my dialogs and that works to some extent. When i set the size of some element from code it is resized to that pixel size which is what i need, but any size that is set in the xrc file gets scaled up. Also when i try to reduce the size of any wxSpinCtrl it can be reduced normally to some point but then only the text box gets smaller and the buttons remain unproportionally large. So is there a way to tell my app not to scale any sizes and just let everything be exactly the same pixel size as it would be on a normal dpi (despite the fact that my app will look small on higher resolutions)?
There is no way to prevent the proper scaling from being applied using wxWidgets API and I don't think this is going to change because it just doesn't seem to make any sense.
However rebuilding wxWidgets with wxHAVE_DPI_INDEPENDENT_PIXELS defined should trick the library into thinking that the underlying graphical toolkit already scales the pixel values and so prevent it from doing it on its own. I've never tested this but, AFAICS, this should result in what you want.
Nevertheless let me reiterate that what you want is totally wrong and the real fix for this problem is to explain it to whoever decided to do it.
Cocoa uses a drawing system (user coordinate space) measured in "points" which are resolution independent...sounds great
While we need to be concerned with our app running in many resolutions, Cocoa is going to take care of that for us in (1) above...sounds too good to be true!
It does scale our controls as resolution changes...this is good.
BUT the screen size increases as my resolution increases...this is not good, I though we had a drawing canvas that was independent of the resolution!
What if the controls shrink to silly small levels as the resolution increases - should I be concerned about this?
To summarize: is their a "standard" resolution I should design for and then all automatic scaling by Apple will automatically look fine?
[Confused while reading the Apple Progammer Guide on the topic of Drawing]
You do not need to be concerned about this. The user is only allowed to select resolutions which make sense given the physical size of the display, so the standard controls will always be "large enough". You just need to test your app on Retina and non-Retina displays (and ideally both at the same time, with an external 1x monitor plugged on a 2x machine ; move your windows between the two screens and check that your images update accordingly).
I just got to test IE10 on a Surface Pro with 1920*1080 display resolution where "make text and other items larger or smaller" has been set to Large.
On my website I have added the CSS+JS viewport fix in addition to the viewport meta tag, all asking for width: device-width (plus I added a "min-width: 320px;" to the #-ms-viewport definition to ensure it never gets smaller than that).
I added some javascript to display the value of window.screen.width and $(window).width to see what the browser ended up using for viewport in IE10, and to my surprise the screen size of a 1920*1080 resolution display was reported as 1280x720!
Now, I can live with with that (just like small phone screens report 320px width no matter their actual resolution, since it is a good size to make stuff human readable across devices for the same font size), but when the 'Metro IE10' is snapped to the side of the screen, the problem comes: IE10 tries to make a 320px rendering of the website, but it zooms in so the right side of it is hidden.
I tried Microsofts own test page: http://ie.microsoft.com/testdrive/Graphics/MakeItSnappy/
It does the same thing - on the Surface Pro the right side is hidden, and you need to drag left/right to see it, and you cannot even zoom out to view the full width!
But when trying the same thing on my laptop with a 'normal' 1366x768 display (rendered as 100%), the snapped IE10 display has the perfect size.
Ok, I guess this is a Microsoft Windows scaling bug - but my question is: Has anybody else experimented with changing the "make text and other items larger or smaller" to 125% or 150% and making websites adapt correctly?
Check out this fix from developer Matt Stow
http://mattstow.com/responsive-design-in-ie10-on-windows-phone-8.html