I have a desktop app that is developer for Windows operating Environment.The App was developed on a 1,280x720 Monitor.It works very well on most systems with normal screen resolutions.Including 1080P and old 17 and 15 inch monitors.
The thing is when it comes to Laptops with 15" screen and 1080P resolution,the App shows up correctly at first but after using a control,the window gets smaller.The Text gets larger and some controls fall on top of others.
Another issue is that when the user has adjusted this size setting to High
The app window gets Cut and it does not show the complete content.The Application is not full screen.
One user was using a Windows Surface Pro and to get the Application Fit,the above setting was reduced.But this made the App too small,so the user ended up getting a refund.
I'm not targeting Tablet(Surface Pro) users.The intended audience is desktop Users.
What is the best way to tackle this issue keeping winforms GUI.
Please advice.
It seems you're looking for the AutoScaleMode property. This will allow your controls to change size according to the zoom level of your users' PCs (which you pictured above).
There is some really good advice in this answer to 'Creating a DPI aware application'. But basically:
Set the AutoScaleMode of your base control (the Form) to Font or Dpi
Remove as many custom font settings from your controls as possible (this will restore them to the default MS Sans Serif at ~8pts)
Develop the app at the standard zoom level and then test it on larger screens with higher zooms, see how it goes.
Hope this helps
Related
I use C# Winforms in Visual Studio 2010. Since I've upgraded my laptop from the old 1366 x 768 resolution laptop to a new laptop with a 1920x1080 resolution, I noticed a problem when continuing development on the new laptop. I isolated the issue down to the new 150% Windows OS-wide scaling (Windows on the old laptop used 100% scaling). When I run the program, the right side of the window is strangely chopped off.
Here's the working version on the old laptop (1000 pixels wide, or 1500 pixels in 150% scaled Windows mode):
And here's the new version on the new laptop with the chopped window (1286 pixels wide, when it should be 1500 due to the 150% scaling).
Upon immediately loading the project into the new 150% scaled Windows setup and running the program, it appears to work fine, but as soon as you move one of the buttons so that VS updates the designer code (button 5 was moved as you can see), and then run, the window is chopped.
Even when manually going into the Form1.Designer.cs code, and adjusting the ClientSize to a stupid high horizontal value like ClientSize = new System.Drawing.Size(3000, 709); results in a window width that is limited to 1286 pixels at most. (Not so) coincidentally, 1286 is around 1920 / 1.5.
Basically, what the heck is going on? This appears like a bug with VS's scaling management. To be clear, the problem occurs when moving development from a 100% Windows scaled screen to a 150% Windows scaled screen, on any system. You don't need two laptops to reproduce the problem, it can all be reproduced on a single laptop (but make sure you log out and into Windows after switching from/to 100% or 150%).
Finally, to be clear, I know about setting the DPI-aware setting to true using an app.manifest file. Although this allows clearer text and solves the chopped window problem, I do NOT want to go this route due to inconsistent changes in my program's GUI such as overlapping controls and misplaced items on some setups.
I've found two half-solutions so far:
First is upgrading to Visual Studio 2017 (which allows you to force 100% scaling in VS Forms designer even in 150% Windows scaling)
Second is keeping with an earlier version of Visual Studio (including VS 2010), but making sure Windows is set to 100% scaling. If you've only just changed the scaling setting, make sure to log out and in of Windows to ensure the scaling is applied appropriately.
A relatively simple workaround is to create a Panel Control that is the size you desire for the window, send it to the first layer (right click the control in the designer> send to back). Then set the form to AutoResize to fit that control. (also set AutoSizeMode to GrowAndShrink in case the form appears larger than it should)
This works great if you need Fixed forms but for Resizable forms you might want some extra code that resizes this panel when the form's resize event happens.
I had been developing WinForm apps in a long time. I just recently bought a Surface Pro 3 to serve as my new development PC. Unfortunately I noticed an issue with the GUI editor. The some of the sizes of the controls don't match with what appears in the GUI editor and with what appears in the actual running application. For example, the sizes of my panels don't follow what it looks like in the GUI editor when I run the app. They usually increase in dimension. I am not really sure if it is a VS issue or maybe it has something to do specifically with using Surface Pro 3?
To demonstrate what I mean consider the following screenshots. Notice the difference in the size of the Menu Bar in the GUI Editor and in the actual application.
If you want to prevent your app from changing size, you can make it independent of DPI settings. Your app will be pixel perfect but on high resolution screens may be too small.
All you have to do is to change AutoScaleMode property of the main form and set it as None.
I know this is an old thread but I was experiencing the same issue... I found a workaround which you may find useful...
After trying a few things it became obvious to me that windows 10 was attempting some "intelligent" resizing of forms under Windows 10 on the surface pro (I am using a surface pro 4)... I am not sure if it is a win10, high-res or surface pro issue.... whatever it is it was messing up my control sizing, placement, anchors and resolution.
I found that if I made a note of the intended size of my form in the designer and then manually set this in code at the end of my Form_Load event, it would override this unintended behaviour and I ended up with my originally intended form size and control placement, I also needed to re-center the form in the parent/screen to get the desired result (of course only if that is the intended start-up position for your form)
The code that worked for me (at the end of the Form_Load event) is...
this.height = 800;
this.width = 600;
this.CenterToScreen();
I hope this helps somebody, I was pulling my hair out for a while!
It has been a while since I posted this question and I kinda forgot about it. I thought I should share my recent findings for those who will find themselves in this same predicament.
I learned that the discrepancy between the GUI editor and the actual running app was because of the super high DPI scaling of my Surface Pro 3. Visual Studio was automatically running at 216 DPI (225% display scaling) compared to the usual 96 DPI (100% display scaling) of common computers. My workaround back then was to simply adjust my controls accordingly thru trial and error and to anchor most of them between the GUI editor and the running app. Eventually, it became less of an issue since I moved on to a normal desktop with a normal screen for my regular software development. Moving forward, I recently stumbled upon a Microsoft documentation regarding Automatic Scaling in Windows Forms. It explains the issues with multiple DPI scaling for Windows Forms. It also includes this bit about the DPI scaling issue of Visual Studio:
With the extreme differences in display DPIs, especially in modern 2-in-1 devices, this can still happen with the most current versions of the .NET Framework and Visual Studio. To address this in a team using different DPI displays, make sure Visual Studio always starts in a non-DPI-aware mode, so the Windows Forms designer always bases the layout calculation on 96 DPI.
The solution they suggested is to add or import a registry value that disables Visual Studio's High DPI awareness:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\devenv.exe]
"dpiAwareness"=dword:00000000
I tried it and it definitely works. I hope it helps you too. :)
I have a Winforms application that is working correctly on various versions of windows and various resolutions. When the application runs on a Motion CL900 tablet, however, the layouts are completely messed up; mainly caused by panel controls that are perfectly sized on other computers now being too small and causing scrollbars. The Motion devices are running Windows 7 Professional.
I have read on a few posts on stackoverflow that Windows machines have a standard DPI of 96, but this device clearly isn't 96 DPI. Is the fact that this device is "non-standard" a result of it's screen or is it caused by a setting in it's OEM version of Windows 7? I have read that I must set AutoScalingDimensions for my form to reflect the DPI of the PC I am developing on. But how do I even know what DPI my machine/screen is that I am developing on?
I have the following in my designer file for the form that has the layout issues:
this.AutoScaleDimensions = new System.Drawing.SizeF(96F, 96F);
this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Dpi;
I would appreciate anyone who has had experience with working with Winforms at various DPI resolutions shedding some light on this question, and maybe give some guidelines for .Net developers how to successfully handle non-standard DPIs.
There's indeed two different uses of the term here:
The display device's native resolution. This is actually how many pixels are within 2.54 cm. Larger values mean obviously a clearer, but smaller picture overall.
The OS' scaling of fonts and widgets. 96 dpi is the "native" size for Windows for example. That is, if you have a display that also has 96 dpi, then the controls are the size they should be when you look at them. Also point sizes for fonts are exactly the right size, then. If you have a display with, say, 120 dpi and set the OS to that measure too and then put both side by side you could measure with a ruler and find widgets and fonts in both cases to be the same size.
Nowadays the second measure mostly controls widget size if your eyes are not capable of working with too small controls. And plenty of applications have problems displaying correctly if you change it, although it's far better since Vista.
Dot per inch are related to the monitor/video card/resolution and just means how many points (or pixels) are shown in the length unit (inch).
Clearly is not related to the OS because you can have same values in all OS (Windows, Linux, Mac)...
DPI is dots per inch and it is a setting you can set in your OS. However, it is a characteristic of the monitor.
Since you are on Windows 7, to change DPI settings, you would want to do:
Control Panel
Appearance and Personalization
Display
Set Custom Text Size (DPI) - (on side bar)
Just change it till you get to 96 DPI (100% usually).
Windows 7 has an option in the Display properties called "Set custom text size (DPI)" if this is set to more than 100% it can impact how elements appear in an application, and can cause layout problems. I'd recommend keeping this at 100%, which is 96 DPI in Windows terms.
Note: the actual DPI resolution is determined by your monitor.
I have a Windows (XP/Vista/7) application implemented in C# using .NET 3.5 and I have a weird resize problems on a small number of Windows XP machines (I haven't been able to reproduce the problem myself).
The application uses a System.Windows.Forms.Form with a System.Windows.Forms.Panel which holds sub-views. Each sub-view is in itself a System.Windows.Forms.Form. During initialization each sub-view is added to the panel (panel.Controls.Add(sub-view)) and the controller selects sub-view by playing with the Hide and Show-methods of each sub-view.
Figure 1 shows how the application normally looks. The panel is the part with the lovely waterdrop-background-image.
But on some Windows XP machines the application looks like figure 2. The entire application has been resized (weird in itself since I have static Max/Min attributes) and the panel is bigger (and has dropped slightly). The background image repeats and any text on the panel is also resized.
Any ideas what this can be? Can it be a .NET-related problem? I do not have access to the problematic machines so all have to go on at the moment is some blurry screenshots.
Update
It is a DPI problem. Changing the DPI setting (on Windows XP) and the application will be resized (but on Vista/7 it stays correct). Thank you for the speedy response guys.
Isn't this a result of DPI settings which was one of the key things WPF tried to address with it's ability to auto-resize, move, wrap, etc?
There are some similar questions around that involve issues caused by changing DPI:
WPF DPI issues
C# Scaling UserControl content to match users Dpi/Font Size
How to prevent font resize when changing the DPI of the system
high DPI problems
I have a WPF application rendering fonts to a larger size than I expect.
The catch is that only WPF applications I write seem to have this effect, and the problem happens only on one computer. The effect also happens with all WPF programs I write (not just one), and all windows exhit the effect.
I am using Visual Studio 2008 with .NET 3.5 SP1; all programs written in WPF.
The operating system is Windows XP with the latest service packs.
The screen resolution is 1680x1050.
Windows and buttons using Windows XP style.
Font size is Normal.
DPI setting is normal size (96 dpi).
I tested my applications on a two other computers with same OS and settings and it looks fine. My programs run on dozens of other computers and I do not see this problem.
Here is a window that looks good:
Here is a window that shows the problem (notice the button on the lower left, and the font size):
I know I can increase the width and add margin to compensate, but I need to understand why this happening.
I am close to a release and I want to make sure my users do not see this effect.
All ideas appreciated.
I'm not running XP right now, but I thought you could customize the size of the text that appears in window captions (and buttons) via the Display Properties (right-click desktop, select Properties, and it's the 3rd or 4th tab, I think). It lets you select colors for selected items, background colors of windows, etc.
That would be separate from setting the DPI settings.
This looks like an unholy XP feature. It had the option to change the size of the system font independently from the video adapter DPI setting. Very convenient to XP users living in Easy Asia where glyphs that make up the letters are very intricate and need all the pixels they can get to make their script legible.
It is covered by Windows Forms with the Form.AutoScaleMode property, which defaults to Font instead of Dpi. WPF is however strongly biased to Dpi, the normal way of scaling.
I don't think the twain shalt ever meet. Tell your user to reset the XP setting. It is buried somewhere in the Control Panel + Display setting, I don't have it anymore to tell you exactly where to look. Or the logical alternative, changing the video DPI setting to match the font size. That's was in the Adapter tab, IIRC. Changing it from 96 to 120 DPI would be a good guess.