I am writing this application and it has a size of (800 X 400). The problem is, it resizes when I run it on different monitor resolutions and all the objects get bigger. Is there a way to fix its size for all monitor resolution without maximizing?
In general, if your form is defined with a fixed size of (800 x 400) then it will generally appear larger on the same screen if you change the resolution to say (800 x 600).
The screen resolution defines how many pixels make up the view port. changing to a high resolution will make all apps, not just yours appear smaller. Changing to a low resolution can make all apps, again not just yours appear larger.
Changing the screen resolution is changing the DPI
Windows and WinForms do provide some mechanisms for scaling your app so the interface can be more proportional on different screens, but it can be a bit more hit and miss to take advantage of in WinForms compared to other technologies like WPF/UWP, especially if you have an older application or code base.
If the scaling is not what you expect, first check that the users have turned scaling in their display settings back to 100%, many laptops and tablets have the set to 125% OOTB. When you have not correctly defined your interfaces to take advantage of font scaling it can look a bit funky.
Setting windows font scaling back to 100% means your app will only have to contend with DPI scaling issues rather than both font and DPI scaling that windows might impose.
font scaling in the display settings, in windows 10 looks like this:
Have a read over:
Automatic scaling in Windows Forms
The key to getting it right is that all forms and controls in your app must be configured to use DPI based scaling OR Font based scaling. When the two concepts are confused the UI can look like a mess as some elements will resize and others may not.
This scaling behaviour is defined in the form as the AutoScaleMode:
- This defaults to Font in new apps.
Many 3rd part components however may be set to DPI mode, especially if they have any drawing canvases or their display logic is referenced by pixels (which is pretty common in WinForms custom painting.)
For this reason, setting your forms to use DPI scaling might solve your issue
Also check out some of these posts in SO that might help explain your observations:
How to write WinForms code that auto-scales to system font and dpi settings?
How to control the font DPI in .NET WinForms app
How to configure an app to run correctly on a machine with a high DPI setting (e.g. 150%)?
Related
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
In my case, No matter how user change win7 dpi setting，I can always get the correct screen resolution via code PrimaryScreen.Bounds，just as same as what set in the control-panel-display on system of win7.
But in my colleague's computer, I run the same code just after setting his os's dpi from 100% to 150%. I get a relative bounds result.
For example, his screen resolution is 1920 * 1080 now, I ran the code after I had set his os dpi from 100% to 150%. Finally I get the resolution is 1280 * 720 by the code PrimaryScreen.Bounds.
Why this?
I did this in the same way, but I got a same resolution.
This is by design. Windows has supported changing the video adapter's DPI (dots-per-inch) setting to 96 dpi (100%) and 120 dpi (125%) for a long time. At least since XP, possibly before that. So applications are expected to know how to deal with this.
Starting at Vista, Windows now supports arbitrary DPI settings. When you go past 120 dpi, Windows takes over the job of scaling the output of your program. A feature of Aero, it lies to the app about the DPI setting and lets the app render its window content into a memory buffer. It then rescales that buffer content before it draws it to the screen.
This is an important app-compat feature, it allows old programs to still be functional on a modern machine and avoids their window from turning into an unusable postage stamp. The result is not entirely flawless, you do see the quality of text in particular being less than stellar.
The Aero lie isn't just about the DPI setting, it also lies about the screen size. Necessary to prevent the app from creating a window that is too large and won't fit the screen anymore after it is rescaled. Which is why you got 1280 x 720.
To turn off the lie, you have to tell Aero that you do support higher DPI settings, even though your program is marked to still be compatible with old Windows versions. This answer shows you how to edit the manifest of your program to add the <dpiAware> element.
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 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.
I am currently developing a Winforms Application that will run on a very specific tablet PC.
My development environment uses dual-17" monitors which are far bigger than the tablet screen size of 10.4" (1024x768).
Due to the purchasing department at my company the delivery of the tablet will not be until well into the design cycle.
Is it possible to mimic the tablet size so that I can adjust my forms to match?
You have couple of options:
set one of your screens to the tablet resolution. You might need to move your taskbar to that screen to get the proper-sized workspace.
install Virtual PC and create a VM with the tablet resolution.
set your main form size explicitly to the tablet PC resolution. For best results size it to the proper workspace size, not the desktop size.
Note that your form will have to still be relatively flexible, since users might configure their taskbar to be at a different position, or different size, thus affecting the available workspace for your app.
The fact that you have 1024x768 on 10.4" means the pixels are denser than your typical PC monitor. That means that text 10 pixels high on your monitor might look fine, but 10 pixels high on the tablet PC may be tiny and almost unreadable (even without loss of resolution).
Unless you can find a monitor with similar pixel density, I don't think you can properly mimic it. Even if you can shrink the application to a 10.4" section of the monitor, now you're probably dealing with sub-pixel shading which will look blurrier than on the tablet PC.
The best you can probably do is setting one of your monitors to 1024x768 (without stretching to fill the screen!), or just set your app to that size and eyeball it to take into account that it will actually be smaller.
You could try hosting your main form inside a user control or another form limited to the relevant size. However, the form is then not a "top level" form, but fairly closely looks and behaves like one.
You can perform normal form actions (minimise / maximise / move / resize / etc) so you can get a feel for what it is like and a certain size.
However in this instance, its best to always design the UI for the minimum resolution you have to target, and have it scale upwards on larger monitors.
very easy - if you're concerned about size, or users have to use the touch screen, start your form out with 10pt+ font
very cool - design the form size as, oh, 950x650. Experiment with the anchor property of each control. Allows you to make basically totally resizable controls (if you get creative with the anchor on groupboxes/panels and the controls inside them).
then set your form to maximize itself on the tablet PC (or e.g., if screen size is <= 1280x1024 - the Anchor property has its limitations as to what size increase looks reasonable).