You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
XrmToolBox on this branch asks Windows for per-monitor-v2 awareness for the first time. Its manifest has always said Per-monitor, which is not a value Windows parses, so the process has been DPI-unaware and every window in it bitmap-stretched above 100%.
At 100% scaling nothing should move at all. This ticket is the sweep that proves it.
What is already measured
Built upstream master and this branch, opened the same tool at the same window size, and compared the two screenshots pixel by pixel:
0 of 1049600 pixels differ (0.00%)
That covers the main window with one tool open and nothing else. The rest of the app is what needs a pair of eyes.
Setup — build and run it in a sandbox
The /overridepath: switch keeps settings, connections and plugins out of your real XrmToolBox, so nothing here can disturb the one you use for work. Delete the folder to undo everything.
cd C:\Users\kk\Code\XrmToolBox
git checkout high-dpi-opt-in
# first time only
C:\Users\kk\AppData\Local\Temp\nuget.exe restore XrmToolBox.sln
&"C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\MSBuild\Current\Bin\MSBuild.exe"`
XrmToolBox.sln -p:Configuration=Debug -m
# a sandbox with one tool in it$sandbox="$env:TEMP\xtb-dpi-sandbox"New-Item-ItemType Directory -Force "$sandbox\Plugins"|Out-NullCopy-Item .\Plugins\MsCrmTools.SampleTool\bin\Debug\MsCrmTools.SampleTool.dll "$sandbox\Plugins\"-Force
.\XrmToolBox\bin\Debug\XrmToolBox.exe/overridepath:$sandbox
The first start asks "Settings found!" — click OK.
To compare against today's XrmToolBox, git checkout master, build again, and run the same way.
The sweep
Tick each one. Anything that looks different from the same screen on master is a finding, however small — a control a pixel out of place is the symptom this change would produce if it were wrong.
Start page — layout, the two columns of links, the tile images
Tools list — tile sizes, the images on them, the category counts, search
Tool Library — opens, lists tools, the images and buttons in it
Connection dialog — Connect → a new connection; the wizard's pages and its embedded Microsoft controls
Open a tool — from the list, and from the Start page's recently-used
Open four or five tools at once — the document tabs, the tab overflow arrow
Drag a tool out into a float window, and dock it back
Close a tool, and close them all
Settings (Configuration → Settings) — every page of it
The status bar, and a tool that writes to it
Themes, if you use one
The About box, the update dialog if it appears
Error dialog — the sample tool has Do something wrong, which should look exactly as it does today
What to report
For anything that differs: the screen, a screenshot of both, and whether it also happens on master. A difference that is also on master is not this branch's.
If the whole sweep passes, say so on the ticket and close it — that is the result this ticket exists to record.
XrmToolBox on this branch asks Windows for per-monitor-v2 awareness for the first time. Its manifest has always said
Per-monitor, which is not a value Windows parses, so the process has been DPI-unaware and every window in it bitmap-stretched above 100%.At 100% scaling nothing should move at all. This ticket is the sweep that proves it.
What is already measured
Built upstream
masterand this branch, opened the same tool at the same window size, and compared the two screenshots pixel by pixel:That covers the main window with one tool open and nothing else. The rest of the app is what needs a pair of eyes.
Setup — build and run it in a sandbox
The
/overridepath:switch keeps settings, connections and plugins out of your real XrmToolBox, so nothing here can disturb the one you use for work. Delete the folder to undo everything.The first start asks "Settings found!" — click OK.
To compare against today's XrmToolBox,
git checkout master, build again, and run the same way.The sweep
Tick each one. Anything that looks different from the same screen on
masteris a finding, however small — a control a pixel out of place is the symptom this change would produce if it were wrong.What to report
For anything that differs: the screen, a screenshot of both, and whether it also happens on
master. A difference that is also onmasteris not this branch's.If the whole sweep passes, say so on the ticket and close it — that is the result this ticket exists to record.