How to switch between two DPI scale values via hotkey?

Try3 said:

It's never broken when I've used it. I change resolution almost every day. Neither Taskbar elements nor Notification area icons get messed up.

There's a significant difference between changing resolution and changing screen scaling. Isn't it the latter that the OP wants to change on the fly?

LesFerch said:

A quick Internet search revealed this free open source command line tool that even includes AutoHotKey (AHK) scripts:

SetDPI 1.0

I successfully tested the command line tool on my computer. Examples:

Change monitor 1 DPI to 125%:
setdpi 1 125

Change monitor 1 DPI to 100%:
setdpi 1 100

You could create shortcuts and/or AHK scripts for any combination of settings.

Please be aware that you can only use this tool to switch between the screen scaling values that are under Change the size of text, apps, and other items in Settings. You cannot use it to set a custom screen scaling value.

Also note that, just like using the Settings menu, changing DPI to one of those presets does not update the corresponding AppliedDPI registry entry (see below). That value only gets updated after a logout/login. Some apps depend on that registry value to display things correctly, so if an app does not display correctly after changing DPI, you will have to either logout/login or create an AHK script that runs the setdpi tool and sets the AppliedDPI registry value.

I think it would make sense for the developer to add that capability to the setdpi tool, so I'll look into that.

[HKEY_CURRENT_USER\Control Panel\Desktop\WindowMetrics]
"AppliedDPI"=dword:00000060

Cool. Thanks!
Sounds like just what I need.

The default values should suffice. But I guess they can be extended via registry modofications. (Even if it isn't, it's no big issue)

Note that I originally had the screen index and screen scaling values reversed. The SetDPI tool expects the screen scaling value first and the monitor index second. It will work the other way around, but if there's an error, the error message will be incorrect. Also note that the monitor index can be omitted if you're setting the scaling for the primary monitor.

LesFerch said:

Also note that, just like using the Settings menu, changing DPI to one of those presets does not update the corresponding AppliedDPI registry entry (see below). That value only gets updated after a logout/login. Some apps depend on that registry value to display things correctly, so if an app does not display correctly after changing DPI, you will have to either logout/login or create an AHK script that runs the setdpi tool and sets the AppliedDPI registry value.

Out of curiosity, do you have any examples of apps that appeared incorrectly without the registry key set?

avada said:

Out of curiosity, do you have any examples of apps that appeared incorrectly without the registry key set?

The only example I can provide off-hand is my app, WinSetView. It adjusts for screen scaling based on the primary monitor's setting (obtained from that registry value). It has no way to detect the screen scaling of other monitors. I doubt my app is unique in that regard.

Modern apps, written in languages such as C#, detect the screen scaling of each individual monitor and adjust as necessary. Such wizardry is not easily available to my simple app written as an HTML application.

LesFerch said:

The only example I can provide off-hand is my app, WinSetView. It adjusts for screen scaling based on the primary monitor's setting (obtained from that registry value). It has no way to detect the screen scaling of other monitors. I doubt my app is unique in that regard.

Modern apps, written in languages such as C#, detect the screen scaling of each individual monitor and adjust as necessary. Such wizardry is not easily available to my simple app written as an HTML application.

So I tested a bit. And it seems like some stuff won't follow the DPI changes no matter what, regardless of the registry value. Most noticeably the quicklaunch toolbar (that I still always add to the taskbar). Even tried killing DWM, thinking that maybe forces them to redraw their appearance but it doesn't work.

By the way how does the key correlate to the percentage shown? I had 144 for 150%, so it's 96*percentage?

avada said:

So I tested a bit. And it seems like some stuff won't follow the DPI changes no matter what, regardless of the registry value. Most noticeably the quicklaunch toolbar (that I still always add to the taskbar). Even tried killing DWM, thinking that maybe forces them to redraw their appearance but it doesn't work.

By the way how does the key correlate to the percentage shown? I had 144 for 150%, so it's 96*percentage?

Any time the screen scaling is changed, only some programs can dynamically adjust. Most programs have to be closed and reopened. The quick launch toolbar is part of Explorer, so it should correct itself after restarting Explorer. That can be done as part of your script that runs SetDPI. In PowerShell, I like to use:

Stop-Process -Force -ErrorAction SilentlyContinue -ProcessName Explorer

A lot of people use TaskKill /im Explorer.exe /f in batch files (or pretty much any scripting language), but I've occasionally had some problems with that method (e.g. Explorer didn't always automatically relaunch). I've never had an issue with the PowerShell command.

Note, if you restart Explorer, then there's no need to manually set the AppliedDPI registry value, as Explorer will do that for you when it reloads.

Yes, you're correct about the DPI value. The Windows AppliedDPI base value is 96, so 150% would yield an "AppliedDPI" of 144.

Techy note: The -ErrorAction SilentlyContinue option is only needed to suppress an error that occurs when the command is run on a system that has multiple accounts logged in (i.e. via fast user switching). In that case, an error occurs for each instance of Explorer that's running under a different account. Those processes can't be killed unless you're running the script elevated.

LesFerch said:

Any time the screen scaling is changed, only some programs can dynamically adjust. Most programs have to be closed and reopened. The quick launch toolbar is part of Explorer, so it should correct itself after restarting Explorer. That can be done as part of your script that runs SetDPI. In PowerShell, I like to use:

Stop-Process -Force -ErrorAction SilentlyContinue -ProcessName Explorer

A lot of people use TaskKill /im Explorer.exe /f in batch files (or pretty much any scripting language), but I've occasionally had some problems with that method (e.g. Explorer didn't always automatically relaunch). I've never had an issue with the PowerShell command.

Note, if you restart Explorer, then there's no need to manually set the AppliedDPI registry value, as Explorer will do that for you when it reloads.

Yes, you're correct about the DPI value. The Windows AppliedDPI base value is 96, so 150% would yield an "AppliedDPI" of 144.

Techy note: The -ErrorAction SilentlyContinue option is only needed to suppress an error that occurs when the command is run on a system that has multiple accounts logged in (i.e. via fast user switching). In that case, an error occurs for each instance of Explorer that's running under a different account. Those processes can't be killed unless you're running the script elevated.

Thanks again!
So I guess I'll need a script then, since I can't contrive it into a .lnk, which I did until now.