A known hole in the change, written down before it is discovered by somebody else. Not a blocker for reading the branch, but it has to be characterised before this goes upstream.
What is covered, and what is not
WinForms fixes a window's DPI awareness when the control is constructed, and DisplayPluginControl constructs the tool's control and its PluginForm inside an unaware scope. So:
- the tool's own window, and everything it builds while it is being opened — unaware, as today ✔
- anything the tool constructs later, from its own code — a settings dialog, a picker, a second form — is constructed on a thread that is aware again, so it comes out per-monitor-v2 ✘
A MessageBox is fine either way (Windows owns it). The case that matters is a tool that opens a Form of its own, laid out in 96-dpi pixels, which will be handed 144 dpi and may come out clipped or half-size.
How to see it
At 150%, with the branch build:
-
Open the sample tool and press Open Toast Notification and Do something wrong — both are host-owned and should be fine.
-
Open a real tool that has a dialog of its own. Good candidates from the tools list: anything with a Settings button, a table picker, or an export wizard.
-
For each dialog:
-
Ask the machine while the dialog is open:
C:\Users\kk\Code\xrm-icons\tools\dpi-spike\bin\WindowProbe.exe XrmToolBox
A dialog listed as PER_MONITOR_V2 while its tool is UNAWARE is this issue.
What the answer decides
- If tool dialogs are rare and mostly look fine, this is a documented limitation and the PR says so.
- If common tools open dialogs that break, the scheme needs the inverse: leave the UI thread unaware by default and make XrmToolBox wrap the construction of its own windows in an aware scope. That is a bigger change to the host and a much safer default for tools, and it is better to know before the PR is opened than after.
I cannot judge which it is without seeing real tools at 150%.
A known hole in the change, written down before it is discovered by somebody else. Not a blocker for reading the branch, but it has to be characterised before this goes upstream.
What is covered, and what is not
WinForms fixes a window's DPI awareness when the control is constructed, and
DisplayPluginControlconstructs the tool's control and itsPluginForminside an unaware scope. So:A
MessageBoxis fine either way (Windows owns it). The case that matters is a tool that opens aFormof its own, laid out in 96-dpi pixels, which will be handed 144 dpi and may come out clipped or half-size.How to see it
At 150%, with the branch build:
Open the sample tool and press Open Toast Notification and Do something wrong — both are host-owned and should be fine.
Open a real tool that has a dialog of its own. Good candidates from the tools list: anything with a Settings button, a table picker, or an export wizard.
For each dialog:
Ask the machine while the dialog is open:
A dialog listed as
PER_MONITOR_V2while its tool isUNAWAREis this issue.What the answer decides
I cannot judge which it is without seeing real tools at 150%.