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.

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

SystemParameters.WorkArea is broken on PerMonitorV2 environment. #10459

Open
incheon-kim opened this issue Feb 14, 2025 · 3 comments
Open

SystemParameters.WorkArea is broken on PerMonitorV2 environment. #10459

incheon-kim opened this issue Feb 14, 2025 · 3 comments
Labels
Investigate Requires further investigation by the WPF team. .NET Framework

Comments

@incheon-kim
Copy link

Description

When display setting is changed or display scale(dpi) is changed while the application is running, SystemParameters.WorkArea does not return proper value.

If you programatically change Top or Left property of Window that are relative to WorkArea.Width/WorkArea.Height, position of the Window would be absurd.
Width and Height are scaled without any problem. they will be just bigger and smaller to display ratio.

Reproduction Steps

  1. Build app with PerMonitorV2 enabled.
  2. Run app with 100% or 150% display scale ratio.
  3. Change display scale ratio 100% to 150% or 150% to 100%.
  4. Change Window's Top or Left property programatically that are relative to WorkArea's value. (i.e. right bottom corner or work area)
  5. voilà!

Expected behavior

SystemParameters.WorkArea returns proper value.

Actual behavior

awkwardly scaled RECT is returned.

Regression?

I only tested on .net framework environment that supports PerMonitorV2.

Known Workarounds

  1. Use same API that SystemParameters.WorkArea uses. SystemParametersInfo
  2. SystemParameters(SPI_GETWORKAREA, 0, ref RECT, 0)
  3. Get current display scale with VisualTreeHelper.GetDpi() or DpiChanged event.
  4. adjust value of returned RECT from SystemParameters() with DpiScale instance.
  5. RECT.Left/RECT.Right will be divided with DpiScale.DpiScaleX and RECT.Top/RECT.Bottom will be divided with DpiScale.DpiScaleY
  6. divided values are correct WorkArea information.

Impact

No response

Configuration

  • .NET framework (4.7.2, 4.8.1)
  • Windows 10/11 (x64)
  • AnyCPU builds

Other information

No response

@miloush
Copy link
Contributor

miloush commented Feb 14, 2025

Do you have a repro project?

What does the current API do differently from the workaround that makes it wrong? ("absurd" and "awkward" are not very helpful, does it give values using the old DPI for example?)

@incheon-kim
Copy link
Author

incheon-kim commented Feb 16, 2025

If I retrieve current workArea through SystemParameters with 1920x1080(FHD), 100% scaling taskbar attached side of screen(left or right), I would get 1080 as bottom coordinate of workArea. Then, I change display scaling 100% to 125% or 150%. It still gives me 1080 as bottom coordinate(height) but right coordinate(width) is changed.
The SystemParameters.WorkArea.Bottom should be 864 (125%) and 720 (150%).

@lindexi
Copy link
Member

lindexi commented Feb 17, 2025

Reference: #4127

@himgoyalmicro himgoyalmicro added Investigate Requires further investigation by the WPF team. .NET Framework labels Feb 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Investigate Requires further investigation by the WPF team. .NET Framework
Projects
None yet
Development

No branches or pull requests

4 participants