I have a form that I have sized to what I wanted, it has a few panels, some buttons and some labels on it but when I open it on a different computer, it is resized and it is larger. I am using visual studio 2008. I know this is very little detail but I thought maybe someone knows of a known issue or some troubleshooting steps that I can take.
Possible reasons for this are different screen resolution and different DPI.
Several possible reasons. First and foremost is the form's AutoScaleMode property. The default, Font, ensures that both the font and the controls get resized to leave enough room for any displayed text. Text size is measured in points, 1/72 of an inch. If you run your program on a machine with a larger dots-per-inch setting for the video adapter, the fonts grow accordingly and need more pixels. That needs the controls to be bigger as well to prevent clipping the text.
Another reason is user preferences for border width (Aero) and caption bar height. A form is sized based on its designed ClientSize, the actual Size at runtime will be determined by adding those preferences to the design size. That's very rarely a problem.
May be the computers have different screen resolution and that's why it appears small in one and large on the other computer
Diffeent resolutions, different browsers, different versions. If you want o keep this from happening, you must specify their width and height.
Related
I have created a WinForm desktop application.
I have installed it on 2 different client PCs.
On 1 PC the captions fit with their controls.
On the other the label does not resize properly.
I went to check the resolution on each Client PC expecting differences but on the resolution 1920x1080 it did not fit and on the resolution 1680x1050 it did fit.
To make things more weird on my development PC the resolution is 1920x1080 and yes the labels do fit.
AutoSize on Form and label is 'true'.
What am I missing?
On the other the label does not resize properly
No, it is the exact opposite. It did resize properly, leaving enough space for the text. Problem is, the text is too wide.
There is more than one problem going on here. Starting point is that the other machine is operating at a different DPI setting. Dots-per-inch, it determines how a font size of, say, 10 points is mapped to pixels on the screen. You have a nice monitor, a high resolution one at 1920 x 1080 pixels. To keep text readable, you wanted 10 points to take more pixels. So you increased the DPI setting. Very easy to do on later Windows versions, you probably moved to slider to 125%. Effective DPI is 120 dots per inch.
Your program however is running on an older machine, one that still has the legacy setting (100% = 96 dpi). This tends to cause accidents, you avoided the most common ones given that the form properly rescaled itself. It shrunk itself to match the lower DPI setting. The layout is still correct, the labels and textboxes have the correct size and location.
But you can see a mishap with the bitmap, it is now too big too fit the space. Not the most obnoxious side-effect here. Otherwise not that easy to fix, to see the entire bitmap it has to be shrunk as well and that causes it to get fuzzy and lose detail. The only perfectly clean fix is to have two bitmaps, each drawn to match the dpi of the target machine. Unfun and often skipped.
Moving to the problem you are complaining about, text rendering at different dpi setting can be a problem as well. At issue is that the height of text scales quite well, but the width does not. The technical term for that is that text rendering is not resolution independent. The chief issue is pixel-grid fitting, a technique used to make text more readable at low monitor resolutions. Aided by TrueType hinting, the shape of a letter is stretched so that stems of a character fall exactly on a monitor pixel. Which greatly improves readability, but of course the side effect is that text will be wider on such low resolution monitors.
But your text is off so much that another explanation is needed. The most likely mishap here is that you used a font that is not available on the old machine. The operating system now must fallback to a substitute font and it has a very different pitch from your original font. I can't see your code but I'd roughly guess at a mapping from Segoe to Microsoft Sans Serif.
There are no simple solutions to these kind of problems, it is just something you need to be aware of. A basic guideline is that it is almost never a problem to scale up, scaling down is a lot more troublesome. So running your dev machine at 96 dpi is in general a good idea, other than the inconvenience of course. Testing on older operating systems, or putting your foot down with a strongly stated prerequisite (like XP not supported), is required. Demanding a higher resolution than 96 dpi is however still unreasonable, lots of machines are still at that legacy setting. Not in the least because changing it causes so many programs to misbehave. 96 dpi has been the default setting for way too long, those days are however over and done with.
How can I make my Windows Store App look great on large resolutions? For example a Button - how can I change its font size based on the resolution? If I view my app on 13" the button looks OK, but if I view it on 27" display it looks very, very small. Isn't something to be used in the Windows store apps framework to adapt a button, textBlock, etc to the screen resolution?
Set StretchDirection="Both" & StretchProperty="Fill" in ViewBox
This is a consequence of screen scaling based on DPI... which makes your button the same physical size on both monitors, but totally ignores the fact that the user sits/stands much closer to one than the other. Maybe someday we'll have a not-stupid scaling scheme that works based on subtended angles.
Large format monitors already have larger pixels, I suggest you simply opt out of display scaling in your application. (But do respect the global system font size settings)
I'm not sure what the opt-out setting is in XAML (WPF), but in WinForms, I'd be changing the AutoScaleMode property.
So here is my form onstartUp event code:
int height = Screen.PrimaryScreen.Bounds.Height;
int width = Screen.PrimaryScreen.Bounds.Width;
this.StartPosition = FormStartPosition.Manual;
this.Size = new Size(width, height);
this.WindowState = FormWindowState.Maximized;
the code works fine and the form starts up maximized. After distributing the applications to the user. A user complained and sent a screen shot with the form buttons on the RHS not appearing on the screen!!!
I figured what the problem is, but i don't know how to fix it. The problem is with windows fonts, Control Panel\Appearance and Personalization\Display\ font size on the development machine is small, on the customers it's medium.
how to accommodate for this in code?
The problem is with windows fonts
Not exactly. It is not the font size you are changing, it is the video adapter's dots-per-inch (DPI) setting. The legacy setting is 96 dpi, since Vista it got a lot easier to change this setting. Common other choices are 120 dpi (125%) and 144 dpi (150%), they are directly accessible from the Display applet with a radio button.
Monitor resolutions have been stuck for a very long time, ducking Moore's Law for a good 30 years already. That's finally changing, in no small part due to Apple's push for "retina" displays. The latest MacBook Pro has 2560 x 1600 pixels on a 13 inch screen, about 230 dpi.
That does come with a problem, any program that creates a, say, 1024x768 window has its UI turned into a postage stamp on such a display. The UI just becomes unusable without a magnifying glass. What is needed is for such a program to become aware of the video DPI setting and create a larger window, proportionally larger by the increase of the DPI setting compared to the way the window was originally designed.
This is automatic both in WPF and in Winforms. WPF gets it by default since all of its locations and sizes are expressed in inches, with a unit of 1/96". Winforms still works with pixels, but it has automatic scaling built-in through its AutoScaleMode property.
Which is what is happening on that user's machine, he's got the video DPI setting at a larger value than your machine. However, without also having a larger number of pixels available on his screen. Somewhat typically picked by someone that has a vision impairment, a side-effect of increasing the DPI setting is that fonts get larger and thus easier to read. But with the inevitable problem that any controls that you put near the right and bottom edge of your window are going to fall off, the screen just isn't big enough.
You address this kind of problem by making your window layout adjustable. Or in other words, by making your UI design work with any window size. A very common feature of Windows programs. Just try it on Visual Studio. Drag the bottom right window corner around and observe how it deals with having less space available but still staying usable. Lots of Winforms features to help you doing this, like the Control.Anchor and Dock properties, FlowLayoutPanel and TableLayoutPanel controls, the Resize event for tough cases.
The Q&D fix for this is the Form.AutoScroll property. Set it to True to permit the UI to still be usable, the scrollbars allows the user to still get to controls that are off the window.
The code you posted has nothing to do with the problem. You designed the form in a higher screen resolution than the screen resolution of the user and didn't consider docking/anchoring the controls inside the form.
I've had a reoccurring issue with my programs' UI: they look fine in design mode and when run on my computer but look different/incorrect (e.g. squished, overlapped controls) when run on other computers.
Any idea what this could be? At first I thought it might be a 32/64-bit issue but it wasn't.
Thanks!
Users can set their text size to be larger than normal, or choose a different font for controls.
Differing DPI settings can affect how things get laid out.
This can potentially be down to several issues.
DPI. Affects the layout of form controls (Thanks to Kristopher Johnson for this one!)
Theme. (Classic, Aero, Luna)...generally speaking Microsoft themes will not have much affect from one to another and neither will well designed custom themes, but badly designed custom themes will suffer. Again as described by Kristopher Johnson, Font size settings in the theme will impact how the form renders. - Consideration: lets say you run your app on a Linux installation of Mono...will it still look the same?
Fonts. If your application uses a font that the other machine does not have, then that machine will substitute it for another "fallback" font. This can have an effect in some controls, for example a label, where the width of the label scales to the width of the text of the given font.
There is a problem with Resolution.
Your machine has a different resolution than other machine, try to make design for resolution 1024X768
How can I force a winforms app to use the fonts/fontsizes I specify on every machine?
I have a c# app where the font seem to change in size on a different machine, and it's not a resolution thig. This is on windows 7 with a c# app. Is there a way to force the font size I want or do the user os fonts always overrule?
Font sizes are specified in points. One point is 1/72 inches. The problem is that this needs to jive with the rest of Windows Forms where almost anything is specified in pixels. The issue is how many pixels make a point. That depends on your video adapter's dots-per-inch setting.
The traditional setting is 96 dots per inch. So if you ask for a 9 point font, you'll get one that's 9 / 72 * 96 = 12 pixels high. As long as the client area of a control is at least 12 pixels high, the text displayed inside of it won't be clipped.
The video adapter's DPI setting can be changed however. They made it kinda difficult in XP, you had to go into the Display applet's Advanced setting to do so. It got a lot easier in Vista, there's a direct link to it with a nice ruler and whatnot.
The next common setting is 120 DPI, 125% more dots per inch. That 9 point font now needs 9 / 72 * 120 = 15 pixels. If the original control that displays that text is still at 12 pixels, the text is going to get clipped. Basically, the descenders are sheared off.
So to fix that, the Control.Size property of the controls in the form need to change. They need to be scaled to accommodate the larger DPI setting. Windows Forms readily supports that. It is the Form.AutoScaleMode, available since .NET 2.0. When you set it to something else than None then automatic code inside Windows Forms kicks in that compensates for the difference between the machine that designed the form and the machine that displays the form. In the 120 DPI case, it will make the form and the controls bigger. So that they can display text without it getting clipped.
But, there's a complication. Changing the DPI setting is great for fonts. TrueType is awesome technology, capable of rendering good looking type at any size. But rescaling doesn't work very well for images that contain line art. They get stray extra pixels or get fuzzy when you rescale them.
Back to fonts: clearly if you change the DPI setting of the monitor, the user would expect the fonts to follow suit. That certainly worked that way back in the XP days. If you change the video adapter's DPI setting, you get a prompt to reboot the operating system. That was important back then because there were lots of program that used device fonts, not TrueType fonts. Non-scalable fonts. New fonts got activated that match the DPI setting. A larger value for video DPI is thus matched with a larger system base font size.
Around the same time, some kind of genius at Microsoft, since assassinated, came up with a Really Good Idea. People that live in East Asia have a writing system based on characters. Intricate glyphs that need lots of pixels to show the details. 12 pixels at 96 DPI does not leave a lot of room to make a good looking Chinese or Korean glyph. Increasing the DPI obviously improves that, but at the cost of having fuzzy images. The Idea: increase the system base font size but don't change the video DPI.
Now there's a new problem however: how to auto-scale the UI. You can see this back in the values you can assign to the AutoScaleMode property, either Font or DPI. Which one is correct for the target machine is not easily guessable. Font is normally the better choice since you want to make sure that text isn't clipped. However, if you want to make sure that images display at the right size, then you want DPI. When you want both then you are stuck between a rock and a hard place, one you can't get out of unless the system base font size matches the video DPI setting.
You cannot do more than specify the font size you prefer. If the user chooses to use great font sizes (125% / 150%) or the magnifier, your font size will increase.