Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Font autoscaling doesn't function in .NET Core as it does in .NET Framework 4.8. #11214

Open
swapso opened this issue Apr 14, 2024 · 11 comments · May be fixed by #11213
Open

Font autoscaling doesn't function in .NET Core as it does in .NET Framework 4.8. #11214

swapso opened this issue Apr 14, 2024 · 11 comments · May be fixed by #11213
Labels
📭 waiting-author-feedback The team requires more information from the author

Comments

@swapso
Copy link

swapso commented Apr 14, 2024

Description

I've just migrated a Winform project from .NET Framework 4.8 to .NET Core 9, following the porting instructions provided in the Windows documentation. However, I've encountered an issue with font autoscaling. When I adjust the font for the entire application, the controls on the form don't scale appropriately.

Reproduction Steps

  1. Create small Multi-windows winform application (an app which can open multiple forms in the same app) based on .NET Framework 4.8 having a single form with basic ui control like labels, buttons, textboxes.
  2. Create a form of changing font of entire application in the application.
  3. Port above .NET 4.8 project to using .NET core with latest version (Also, keep copy of .Net 4.8 version)
  4. Run both project, open a form, observe controls properties before and after changing font size.
  5. For reference, .NET 4.8 uses default 'Microsoft san serif' with 8.25 Small font size and .Net core uses 'Segoe UI' with 9 small font size.

Expected behavior

In a NET Core project, after changing the font, the properties of the controls like SizeX, SizeY, LocationX, and LocationY should be set to the same values as in the NET 4.8 project during events like onLoad, onShown, and FontChanged.

I have attached my application expected screenshot.
Correct

Actual behavior

In a NET Core project these properties are not getting set correctly, which ultimately causing winform UI to set weirdly.

I have attached my application actual screenshot.
weird

Regression?

No response

Known Workarounds

4 8 code

Above is NET 4.8 code from System.Windows.Forms->Systems->Windows->Forms->Layout->Containers->ContainerControls.cs

and below is the same code from NET Core

Core code

Look at difference, because of base.IsHandleCreated NET Core doesn't allow to take effect of FontChanged.
if we remove that base.IsHandleCreated from code and test the application it works fine.

Configuration

.NET version- 4.8 and .NET Core
Windows 10
x64 Architecture

Other information

No response
@dotnet-policy-service dotnet-policy-service bot added the untriaged The team needs to look at this issue in the next triage label Apr 14, 2024
@Suchiman
Copy link

This issue should probably be moved to dotnet/winforms. IsHandleCreated was added in this commit: 9b77d91

@jkotas jkotas transferred this issue from dotnet/runtime Apr 14, 2024
@RussKie
Copy link
Member

RussKie commented Apr 15, 2024

@swapso I believe what you're seeing is expected and by design due to the change in the default font (documented here). To ease the pain of the migration in .NET 6 we introduced Application.SetDefaultFont API and the application bootstrap (documented here, blogged here).
Setting the application default font to ""Microsoft Sans Serif, 8pt" should set your layouts back to the original.

I would also recommend reviewing the list of the breaking changes Windows Forms SDK accepted moving from .NET Framework to .NET.

@swapso
Copy link
Author

swapso commented Apr 16, 2024

@RussKie, you're spot on. It only functions correctly when the forms are already open, as IsHandleCreated returns true in that scenario. However, if the form is closed and we modify the font for the application from another part of the application, then open the form again, IsHandleCreated returns false, leading to improper scaling.

@swapso
Copy link
Author

swapso commented Apr 23, 2024

Difference between NET 4.8 & NET Core font scaling.pdf

Hi @RussKie @Suchiman
To support my statements, I have created two separate applications based on NET Core & NET 4.8. In Above documents I have provided github links to clone the repos and step-by-step workflow to reproduce the same error I am facing.

Please go through it once.
You will observe how IsHandleCreated comes false in case TabControl contained controls.

@RussKie
Copy link
Member

RussKie commented Apr 23, 2024

Thank you @swapso, that's for @dotnet/dotnet-winforms team to investigate.

@LeafShi1
Copy link
Member

This problem can be reproduced by setting a larger font size for the form and making the control layout in the Form more compact.
WinFormsApp3.zip

image

@swapso swapso linked a pull request Apr 24, 2024 that will close this issue
Open
@swapso
Copy link
Author

swapso commented Apr 24, 2024 •
edited

#11213

@RussKie @LeafShi1

In above pull request I have provided a solution to bypass this IsHandleCreated condition.
May I know how to get these changes approved ?

@merriemcgaw
Copy link
Member

@swapso thank you for raising this issue. A change in this part of the code is extremely risky and can have a lot of unintended consequences. @LeafShi1 - can your team do a deep dive into a workaround, perhaps enforcing SuspendLayout when handle is created?

@LeafShi1 LeafShi1 removed the untriaged The team needs to look at this issue in the next triage label Apr 26, 2024
@swapso
Copy link
Author

swapso commented May 3, 2024

@merriemcgaw @LeafShi1 @ricardobossan
can you provide me an update on this issue?

@LeafShi1
Copy link
Member

LeafShi1 commented May 6, 2024

@merriemcgaw @ricardobossan @Tanya-Solyanik
The reason for this problem is that PerformAutoScale is not executed, because when the Form object is created, its handle is not created immediately, this is by design.

So the way to fix this problem

  1. As a workaround, force creation of Handle before font change
    image
  2. Update judgment here so that PerformAutoScale can be executed. Can we consider the following judgment logic?
    if (AutoScaleMode != AutoScaleMode.None && (IsHandleCreated || Font != DefaultFont))

@Tanya-Solyanik Tanya-Solyanik added the untriaged The team needs to look at this issue in the next triage label May 6, 2024
@merriemcgaw
Copy link
Member

Thanks for the workaround @LeafShi1! @swapso does this solve your issue?

@merriemcgaw merriemcgaw added 📭 waiting-author-feedback The team requires more information from the author and removed untriaged The team needs to look at this issue in the next triage labels May 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
📭 waiting-author-feedback The team requires more information from the author
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fixed #11214 swapso/winforms
7 participants
@RussKie @Suchiman @Tanya-Solyanik @merriemcgaw @ricardobossan @LeafShi1 @swapso