Why does form.clientsize move my buttons in windows 10?

Question

0.00/5 (No votes)

See more:

I have a rather simple utility app originally written in VS 2010. When I updated my development machine to Windows 10, the app ran without modification, but the two buttons on one dialog moved up 23 pixels to where they get partially hidden by a label. Annoying, but tolerable for a while.
I decided today it was time to remedy that misplacement, so I moved the project to VS 2015 in Windows 10 (with still the same .NET version specified). When I open the form designer for that dialog, sure enough, the buttons are 23 pixels high. So, I moved them back to the bottom-right-anchored position they belong in and saved the form. I then compared the current and prior versions of the form's files and the ONLY line that changed is in the designer.cs file:

C#

this.ClientSize = new System.Drawing.Size(284,93);

In VS 2010 under Windows 7, the 93 was 94. If I change the 93 back to 94, the buttons jump back to their incorrect locations and VS changes the 94 back to 93. The MSDN documentation on ClientSize sounds like it should be treated as readonly and makes no mention of what effect changing it might have.
Toying around with the designer.cs file (just for grins), I found that if I correct the locations in that file, VS changes them back to the incorrect locations. The only way to put the buttons where they belong is to move them in the graphic Designer, and it then puts them in the same locations I couldn't edit them to. Go figure.
It's obvious what to do for my Windows 10 version, but my analytical brain doesn't like not knowing why this happens. It's pretty clear that it is a difference between Windows 7 and 10, but...
Why only this one dialog?
Why only those two buttons?
What does ClientSize have to do with it anyway?

What I have tried:

Searched MSDN under Form.ClientSize.

Posted 25-Jun-18 5:57am

John Whitmire

Updated 27-Jun-18 6:13am

v2

Add a Solution

Comments

Ralf Meier 25-Jun-18 15:57pm

Some questions :
- what .Net-Framework are you using ?
- at your Form : which Setting do you have at the Property 'AutoScaleMode' ?
- where are those 2 Controls located ?

John Whitmire 26-Jun-18 12:27pm

See my response to Maciej Los.

2 solutions

Solution 1

Windows controls behaviour depends on many factors, such as:
- container (TableLayoutPanel, FlowLayoutPanel, Panel, GroupBox, etc.),
- Anchor
- Margin

See:
Walkthrough: Arranging Controls on Windows Forms Using a TableLayoutPanel | Microsoft Docs[^]
Walkthrough: Arranging Controls on Windows Forms Using a FlowLayoutPanel | Microsoft Docs[^]
Walkthrough: Creating a Resizable Windows Form for Data Entry | Microsoft Docs[^]
Control.Anchor Property (System.Windows.Forms)[^]
Control.Margin Property (System.Windows.Forms)[^]
Control.Padding Property (System.Windows.Forms)[^]

Posted 25-Jun-18 20:49pm

Maciej Los

Comments

John Whitmire 26-Jun-18 12:26pm

@Ralf Meier and @Maciej Los: I was able to do a check where the only difference is the O/S. It provided some answers and opened other questions.
When I opened the VS2010 project in VS2015 under Windows 7, the same difference appeared in the form Designer. (Simply opening either the project or the form designer--I don't know which--changed the buttons' locations in the *designer.cs file.) I did the same "correction," moving the buttons back to their correct location, and saved the form. The files that were saved (*.cs and *.resx) were unchanged from how they had been before opening the project! But now, the form looked correct in VS2015.
I built the app with VS2015 and ran it on both O/S versions. It looked fine on Win7 where it was built, but moved the buttons in Win10. I tried the reverse, building in Win10 and executing in Win7, and the same thing happens.
Note again that the difference mentioned in the OP is the only difference I can find among the now three copies of the project. The app has another form with several User Controls on it. I have seen nothing else affected by swapping between the O/S versions or VS versions. The control layout and properties are the same. Margins, padding, etc. are all defaulted. Anchor is bottom-right for these buttons and for most of the others on the other form and its User Controls. The csproj file specifies .NET 4 Client in both scenarios.
So, it seems that the O/S versions have a slight rendering difference that manifests in this scenario. The new question is why the difference shows in the VS2015 Designer under Win7 until I save the form's files in VS2015. At that point, something hidden changes and the form designer then renders as expected, yet without having made any changes to the generated source code.

Maciej Los 26-Jun-18 13:48pm

John,
Seems, i can't help you ;(
I'd suggest to report this to MS.

Ralf Meier 26-Jun-18 14:39pm

Hi John,
I must say that I have had some problems in the past with anchored Controls - independant from their container. It seams to me that you are at the same point. Also for me it allways had something to do either with the OS or a changed (to greater) Screen-resolution. Depending on the OS the basic Form-Behaviour (Appearance) can change. So I decided (for me) to allways to work with fixed locations OR with calculated locations and Control-Sizes (and perhaps Font-Sizes).
Maybe this could also be a way for you ...

John Whitmire 26-Jun-18 16:32pm

Thanks for your input. I think I'll file this one in the "just because" category under Microsoft and move on.
@Ralf, I'll take your suggestion and move the anchor for those buttons to top-right since the form isn't allowed to grow vertically. It will be interesting to see if that works.

Ralf Meier 27-Jun-18 4:36am

Be so kind and tell the results of your 'researches' ...

John Whitmire 27-Jun-18 12:14pm

Bingo! Top vs. Bottom was the silver bullet.

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

John Whitmire · Accepted Answer · 2018-06-27T06:14:00

Well, well. Changing the anchoring of those buttons from bottom-right to top-right (which I could do because the form is not allowed to grow vertically) causes the buttons to stay in their rightful place in both Windows versions.
Other related data:
* The one button on the other form is top-right anchored.
* All the other bottom-right anchored buttons are in UserControls, all of which are top-left anchored.

Thanks for the suggestion, Ralf!!