Form controls displaced when installed on another computer - c#

I know there will be folks who will vote this question down or ask for close. But if there is any kind of information or code I can provide you to know more about my program I will let you know. So please keep reading and see if you have had a similar problem.
I am running a Win7 64bit with .Net Framework ver 4.5.
I have created a Winform application. And to create my form elements I have taken advantage of a library called Metroframework that gives the program a metro look and feel. It contains some standard controls and as well as user controls that inherit from the original Form class. This is the opening view of my program.
However, for some strange reason, when I came to install my program on two other computers (one running Win7 and the other Win8), I noticed that some of my form elements have changed their location and some have just disappeared or just have been displaced. This has frightened me knowing the amount of time I have spent to put this elements in place.
Everything looks fine on my own computer both in dev environment and after building my application in release version. At first I thought this is a screen resolution problem on the other two devices, but that was not the case either. And even if it was, why should this happen?
Can anyone please help me solve this problem? I will share any part of my code you need. But I really have no idea where the source of this problem is!

The main influence on the layout variations on different machines is theForm.AutoScaleModeproperty.
In theory the default setting should work fine but I found that sometimes it is best to switch it off completely, that is going from Dpi or Font to None..
MSDN explains a little about the intended effect.
BTW: The is also a ContainerControl.AutoScaleMode property, so you could choose different modes for some parts of your forms as described here:
The AutoScaleMode property specifies the current automatic scaling
mode of this control. Scaling by Font is useful if you want to have a
control or form stretch or shrink according to the size of the fonts
in the operating system, and should be used when the absolute size of
the control or form does not matter. Scaling by Dpi is useful when you
want to size a control or form relative to the screen. For example,
you may want to use dots per inch (DPI) scaling on a control
displaying a chart or other graphic so that it always occupies a
certain percentage of the screen.
To remain true to the pixel-precise layout use:
this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.None;
The last value in the AutoScaleMode enumeration is Inherited which most often would be chosen for nested containers.
Update: The choice of ContainerControlsis rather limited:
System.Windows.Forms.Form
System.Windows.Forms.PropertyGrid
System.Windows.Forms.SplitContainer
System.Windows.Forms.ToolStripContainer
System.Windows.Forms.ToolStripPanel
System.Windows.Forms.UpDownBase
System.Windows.Forms.UserControl
Maybe the most useful is the UserControl. Note that it doesn't expose the AutoScale property in its instances but only in the class definition. Also note that you can't add controls to an instance in the desiger, but you could assemble them in maybe a Panel and then set a UserControl (with AutoScale=Font) to be the Panel's Parent.. You'll need to allow for some extra space in any case, though..

Related

Form size in design mode is not the same when run

I have been developing winform applications for a long time and I've never noticed something very simple, almost basic so I went back to the basics, I made a big form with a button on the extreme and I noticed that the size of the form changes completely when run:
design
run
As you can see the form size gets smaller and the button is hidden.
The properties are the default ones AutoSize false and AutoScaleMode Font.
This question is similar to this but unfortunately the answer there is not useful since the recommendation is the default.
Note: This is automatically solved when my notebook gets connected to another display
Below are some steps you can try if one of them can solve your issue:
If the problem occurs only when you connecting with other monitor, try to change the settings when connecting, does this happens to other PCs too? Or try to use another PC or install a VM (Virtual Machine) to run it there.
Check your DPI settings, for example in Windows 7, is that Smaller - 100% (default), or Medium - 125%, or Larger - 150%?
Try to set Form's property AutoScaleMode to Dpi or Font for each case.
If the problem still persists, try to create the sample form with the help from Creating a DPI-Aware Application.
I once tried to use FlowLayoutPanel control to arrange some identical elements such as buttons, pictureboxes. If possible, try to use it when applicable.
Last one, try WPF instead, it seems complicated at first, but you will get used to it soon and find out interesting things that Winforms doesn't have. You can arrange control to a grid (similar to a table), then put your controls to each cell with no problem. My suggestion if you plan to learn from ABC: WPF Tutorial.
Leave comment if you need more help, I will come back to see if any further I can provide. Because I've come into this obstacle when creating an app before :)
Set button "Anchor" (Right*, bottom) in property window

How to make a Windows Form to change it height adaptively as controls get added/removed or hidden/shown?

What I need can probably be described as "reverse-anchor", "reverse-dock" or something like that (I have chosen to mention this just because "reverse-anchor" happened to be the first thing to come into my mind as a keyword candidate when searching for questions and answers that might already have been submitted discussing this subject, perhaps this will help people thinking a similar way to find this one in future). WinForms controls implement the Anchor property to set up adaptive resizing on containing control/form size change but I need the opposite - the form to resize adaptively to the controls.
A thing adding a minor bit of complexity to the task is that the controls meant to be added/removed/shown/hidden/enabled/disabled (and resized perhaps - this functionality is not really needed directly so far but I suspect it can turn to be required for compatibility with non-default Windows visual styles and themes that have potential to affect controls sizes unpredictably and can change at any moment of the app running) are not going to be the last ones on the form - a row of buttons will always be in between of the last control of the volatile group and the window lower border.
The actual task is to design a form that will display a collection of objects with a row of controls (a label, a text box and 0-2 buttons) corresponding each of them and it is strongly preferable to use just the very basic "common controls" avoiding grids, lists and stuff like that in this case (wrapping them in an additional container controls like panels is perfectly acceptable though, abstracting them in a separate "user control" can be considered too if this can really make the solution easier, more reliable or otherwise better, using hand-written code manipulating controls and form sizes is perfectly acceptable too (I can hardly expect a "set a magic property and it's done" kind of solution to exist for this task) but I haven't found a reliable algorithm so far (when to change what properties and what formulae to calculate new values with)).
The maximum capacity can be safely limited to something near 10 (or 20, perhaps, but not more - more would be just absolutely unreasonable to display on one form (provided scrolling is not an option)) so both ways are acceptable: to add/remove the controls in runtime or to put them on the form in the designer and just manipulate Visible and/or Enabled properties in the code. By the way I have found a problem with Visible - it gets switched off and back on by the framework internals before the form is rendered and other controls Anchor properties come in the game but I don't think it's a good idea to rely on this to happen always and the same way so just adjusting the form Size property on a control Visible property change does not feel really convenient).
What might be some good ideas relevant to implementing this behaviour?
PS: As far as I know this is a natural feature of WPF but I am to use WinForms to make the app runnable on Macs and, perhaps, other non-Windows platforms with help of Mono.
I'll tell you about some clues may help you:
1- correct to build your own Procedure for manipulating all the matter.
2- i advice to use a Wizard methodology (Next / Back buttons) so if the plate form is small like tablet or smart phone, so the mentioned procedure will decide how many Controls combinations (Label, text box, option button...) will be in each frame of that wizard and keep the remaining for Next button.
3- By the way if you will hide some controls use the original event fires to run the mentioned Procedure. (like a basic button to start the form so don't depend on visible / resize events).
4- Resize the size of each form of the wizard in the last part of the mentioned procedure.
If still a problem exists tell me and i hope i can help :-)

Why is Visual Studio altering my Winforms when editing them on another computer?

I am having a rather odd issue that I have been unable to find the answer to. I have 2 PCs that I am doing coding on - one a desktop PC and one a notebook (QuadHD resolution). Each has Windows 8.1 & Visual Studio 2013 Update 5 installed.
I have localized all my Forms and it seems that when I edit the Winform on my notebook, it causes very odd resizing issues to occur. For example, if I simply change the "Language" property from one language to another (that I have already translated), the entire form is skewed and re-sized, completely destroying all the layout of the form in the selected language. On another form, the "ImageScaling" property is erroneously changed from 16x16 to 40x40.
The issue seems to be related to the changing of the 'Language' property. Almost like there's some sort of resizing logic & layout logic being applied when this property is changed.
When I perform the same operation on my desktop PC, I get no such odd modifications (as I'd expect). This obviously renders my notebook completely useless for being able to do any WinForms work!
I initially thought this might be related to some quirk with the QuadHD display (i.e. 3.2k x 1.8k). I have tried to reduce the screen resolution to a regular HD quality, however this doesn't seem to resolve the issue.
Does anyone have any hints about what I could try to fix this problem?
Thanks.
The only workaround I have been able to come across so far is to ensure that your Windows Settings->Display->Scaling is 100% BEFORE making any modifications to the form (including changing any seemingly innocuous properties such as 'Language').
On high-resolution screens, this unfortunately makes the content almost unreadable but at least the forms are not completely ruined/resized when you edit them.
You will unfortunately need to do all your edits in this mode and commit them before reverting your scaling back to its original setting.

My Windows Form keeps on shrinking/resizing on build

I am working on a Windows Forms project. It contains a tab controller with multiple pages and multiple controls on each.
It appears that relatively recently, after some form changes, that each time I build and run the solution the form resizes/shrinks.
So if I set the size of the form height to 768, once I click 'Start' to build and run it, I can actually catch a glimpse of it resizing itself during the process and then the form loads 21 pixels shorter than the height value it was at build for.
If I then keep building and running my project, the form will decrease by 21 pixels each time, making it smaller and smaller with every build.
We think it might have been introduced when we added the 'DataGridView' controller to one of the tabs, but we have yet to prove if that's the case.
Is there a reason why this would be happening, and what could be doing this?
Why would it resize itself during build run time?
This is an annoying bug, and I have suffered similar behavior myself. However, there maybe a couple of workarounds, however be warned though, these may or may not help and sound a little hacky.
Solution 1
If your control isn't docked, docking may help.
Solution 2
You might be able to change your DPI settings to eliminate the problem, i.e.:
Display Properties → Settings tab → Advanced. In the the Advanced dialog I changed the "DPI Settings" from Large (120 dpi) to Normal (96 dpi).
Solution 3
This is maybe due to AutoScaleMode-property. Your forms may have been designed with a different DPI or font settings than you have now in Windows display settings. Try setting the AutoScaleMode-property to None in your form and offending controls, and they won't be automatically re-sized anymore.
The Problem
Apparently there is a bug in Visual Studio 2015. It is not calculating the Size properly when certain circumstances are met. In my case I was using the following...
(Name): Form1
AutoScaleMode: Font
AutoSizeMode: GrowOnly
DoubleBuffered: True
Font: Verdana, 8.25pt
FormBorderStyle: FixedDialog
Icon: (Icon)
MaximizeBox: False
MinimizeBox: False
MinimumSize: 600, 170
Size: 600, 170
StartPosition: CenterParent
Text: MyTitle
Now... If you close this form and open it back up the Size is still exactly the same (600, 170). If you change the following property...
ControlBox: False
Then you closes the form and open it back up you will notice the Size has now been changed to (610, 203).
My guess is that the bug is not accounting for two things. One would be the form title bar HEIGHT. The other would be the title bar icon WIDTH. This would be the offset of a WIDTH of 10 pixels and a HEIGHT of 33 pixels.
The Solution
Well you actually have three workarounds. One would be to offset the MinimumSize. Another would be to actually show the ControlBox. The last one would be to fix the issue in code by setting the ControlBox property after the form is initialized.
Offsetting The MinimumSize:
So the first option would be to offset what you want the MinimumSize to be by (w:10, h:33). So for example, If you want the MinimumSize to be (600, 170) then you need to set it to (590, 137). That would actually produce the size you expect to see.
Showing the ControlBox:
Simply change the following property...
ControlBox: True
Correcting the issue with code:
You will need to change the following property at design-time...
ControlBox: True
Then you will need to set the ControlBox property to False after the form is initialized.
public Form1()
{
InitializeComponent();
this.ControlBox = false;
}
This Works for me,
on form designer.
Copy the values of your form size.
Past it in both Minimum and Maximum Size property.
Enjoy
I had the same problem. My solution:
My PC's system is Windows 10. The resolution of the monitor was 125%, and I set it to 100%. Then I set the size of the form, not changed.
You can see the resolution settings in this picture:
In Turkish "Scale" is "Ölçekle". There are resolution options on the bottom ("ölçekle ve düzenle").
I figured it out!
If you click on the form in "Design View" → "Properties" → "MinimizeBox"
and change "True" to "False".
OK, so first in response to Saruman's suggested solutions..
None of the controllers in the application where had docked values. A good few were anchored, but none appeared docked. I docked a couple of the main containers I could find, and it didn't seem to make much difference. Admittedly I didn't dock every single controller, but I then moved onto solution 2...
I wasn't sure where to find the DPI settings. Whether somewhere in Visual Studio, or on my machine. So I moved onto proposed solution 3...
On the Form initialize, I added 'this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.None;'. This then seemed to automatically place it above a 'this.ClientSize = new System.Drawing.Size(11264,730)' method, which piqued my interest.
With a little further debugging, it appears that when the application builds and intializes, the 'this.ClientSize' property is already set at a very low, more or less, '230x200'. I am not sure where this value comes from, but I wonder if it has anything to do with the initial resizing before it then tries to set it again to something bigger...
Regardless, I came across another suggestion to possibly double check my form's minimum width and height properties, and noticed they were set to 0x0, I'm assuming by default.
So I set the minimum values to be the same as my form's size value, and on subsequent builds it appears to be keeping its size now! Or at least, it isn't shrinking any more from what I can tell.
I'm not sure if setting the minimum form size is an acceptable solution for this bizarre behaviour, but so far it seems to be keeping the application size consistent on each build we do, which is a relief at the moment.
If any one has further knowledge on the ClientSize property and if I am right to be concerned about its initial low size, would be great to hear it. :)
Upgrading to .NET framework 4.7+ will resolve the issue of text being cropped. Furthermore if that isn't applicable add the following line to the app.config file
<System.Windows.Forms.ApplicationConfigurationSection>
<add key="DpiAwareness" value="PerMonitorV2" />
<add key="EnableWindowsFormsHighDpiAutoResizing" value="false" />
</System.Windows.Forms.ApplicationConfigurationSection>
This will disable the scaling performed by windows thus the application size won't change. For more details visit Auto Scaling in Windows Forms
Faced the same problem. Fixed it by changing 'AutoSizeMode' to 'GrowOnly'
If you are experiencing this issue in Visual Studio 2019, a simple fix is to set the AutoSize property of your form to True, and then to place a small, invisible control, such as a Panel, in your form at the extreme lower-right of the form. Size the panel to something like 20,20.
When the form automatically resizes upon running, Windows will calculate the form size to include all of your form's controls, which will include the small Panel you've placed in the lower-right.
I think that this is the simplest, easiest approach to have your forms sized appropriately without fighting Windows automatic scaling.
And we have a late contribution (if someone, like me, ends up here with a problem similar to mine) :)
My problem proved to be a shortcoming in VS. Having a "high dots per inch" (HDPI) monitor as my main screen was what caused my problem. Having different zooms on different monitors messes things up for VS. Running the executable on other machines (sometimes) shrunk the form so that (roughly) the bottom quarter wasn't visible.
Read about it here: https://learn.microsoft.com/en-us/visualstudio/designers/disable-dpi-awareness?view=vs-2019
But in short - here are the three suggested solutions:
Restart Visual Studio as a DPI-unaware process
Add a registry entry
set HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers to the path to the devenv.exe (for VS 2019 normally C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\devenv.exe)
Set your display scaling setting to 100%
The first is the suggested solution in the article, but that messed up other things in the Form editor for me, so I ended up turning down the resolution and setting the zoom to 100% for all monitors.
I have just come across this problem setting up a form in Visual Basic in VS2008. I found the solution was to leave the form’s minimum size property at 0, 0 at design time and set it with code in the formload sub.

Sizing on Large Screens with Windows 7

I have a some winform applications which lose some controls when opened on a large monitor with windows 7. I created the applications in XP initially but I when they are opened in windows 7 some of the controls vanish from the screen. I set the attribute of FormBorderStyle to Sizable but I was wondering if anyone had any different or long term solutions?
As stated here, Docking may be that, what you need. I actually hadn't any problems of this matter but as an alternative, scaling the controls to a relative size may also help. See the first link for more information.
Use any kind of Container controls like Panels/GroupBox controls and properly dock your controls inside it and also containers aswell. If you have specific requirements using Anchor Property on the control also will also help.

Categories

Resources