I'm working on a Win32 app with multiple windows, some of which use WS_POPUPWINDOW style (no caption) and some of which use WS_OVERLAPPEDWINDOW style. The app has System DPI awareness.
When I move the overlapped windows between monitors, they scale to match the current monitor DPI as expected. But the popup windows only do this if there are no other open overlapped windows. Otherwise, they always try to match the scaling of the last active overlapped window in the same process, even if it's on another monitor with a different scale factor.
I guess this makes sense for some use cases, since you'd always want eg. a popup menu to match the scale of the current window. But I want my popups to behave as independent windows with their own scale factor.
How do I make popup windows always match the DPI of the monitor that they're positioned on?
As a quick fix before I eventually convert the app to per-monitor DPI awareness, I created an invisible overlapped owner window for the popup that tracks its position / size. This ensures that whenever the popup is active, it updates to use its owner's scaling, which always matches the current monitor.
Is there any API to retrieve a state of Windows 10 Power mode slider?
I was looking at Windows.System.Power namespace. But PowerManager class seem to provide only an immediate state of the power system, but not user preferences set by the slider.
The slider also exists somehow in parallel with previous "power plan" settings. It does not seem that the slider state is reflected directly in Win32_PowerPlan.
Change the position of the slider, and the registry key:HKLM\SYSTEM\ControlSet001\Control\Power\User\PowerSchemes\ActiveOverlayAc/DcPowerScheme will also change.
ActiveOverlayAcPowerScheme is for non-battery powered and ActiveOverlayDcPowerScheme is for battery powered.
However, Starting with Windows release 1903 the slider is available for AC only devices as an OEM opt-in feature.
The values of the key ActiveOverlayAcPowerScheme and the corresponding slider modes are as follows:
Better Battery {961CC777-2547-4F9D-8174-7D86181b8A7A}
Better Performance {381B4222-F694-41F0-9685-FF5BB260DF2E}
Best Performance {DED574B5-45A0-4F42-8737-46345C09C238}
the ActivePowerScheme will be overlaid with ActiveOverlayAcPowerScheme.
you can retrieve the key value to get the slider mode.
A user has an ability to change a scale of displayed text (via Settings → Display → Change the size of text, apps and other items on Windows 10, for example).
What window message should I process to be aware of such changes?
I have a stuff which size depends on actual font height. However, size ajustments are time consuming so I would prefer not to perform them on each WM_PAINT arrival.
Isn't it WM_DPICHANGED?
Sent when the effective dots per inch (dpi) for a window has changed. The DPI is the scale factor for a window.
- The window is moved to a new monitor that has a different DPI.
- The DPI of the monitor hosting the window changes.
When adding a system tray icon from in Windows there are two versions of API that we can pass to Shell_NotifyIcon() via NOTIFYICONDATA structure. There are subtle differences between the two API, and these are not listed anywhere on MSDN. It took me some effort to figure out some of the differences, which I am going to share now. Improvements/additions to the answer are always welcome.
PS: This question is purely for sharing what I have learnt over last few days experimenting with windows DPI scaling.
uVersion member of the NOTIFYICONDATA structure can have 3 possible values, representing the version of the API being used to create the taskbar icon.
0 Use this value for applications designed for Windows versions prior to Windows 2000.
NOTIFYICON_VERSION Use the Windows 2000 behavior. Use this value for applications designed for Windows 2000 and later.
NOTIFYICON_VERSION_4 Use the current behavior. Use this value for applications designed for Windows Vista and later.
When it comes to message handler for the tray icon, the wParam, and uParam have the differences as illustrated in the following image.
Notice that in NOTIFYICON_VERSION_4 the wParam gives X, and Y coordinates of various events, but there is no provision for getting the coordinates in NOTIFYICON_VERSION. This gives rise to an interesting behaviour (which was a cause of a BUG I was trying to solve). If you use NOTIFYICON_VERSION, and then invoke the context menu of the tray icon, then the mouse cursor, wherever it may be while you are invoking the menu, gets placed right at the center of the tray icon. Even if you use keyboard (WINDOWS+B) for invoking context menu of the icon, the mouse cursor still moves to the icon.
This may not be of particular interest to you until you look at this particular BUG I am trying to solve in Pico torrent application.
Here is the scenario.
OS : Windows 10
Application isn't per-monitor DPI aware, but is system level DPI aware.
There is an initial value of Desktop scaling set, say 150%, when the user logs in.
Pico torrent is running.
DPI scaling value is changed to, say 125%
Pico torrent's context menu is invoked
The context menu will not be displayed at its proper place, and will be displaced a little, showing a deviance.
See the following images to understand what's happening.
The problem is that although MSDN says that GET_X_LPARAM(wParam), and GET_Y_LPARAM(wParam) should give correct values in the handler of tray icon, but it doesn't, in the presence of DPI scaling (i.e. for a change in DPI scaling without doing a sign out and sign in). On the other hand the API GetCursorPos() returns the correct value of mouse cursor coordinates. Note that NOTIFYICON_VERSION_4 along with GetCursorPos() will not work, since the context menu can be invoked using keyboard, at which the mouse cursor can be anywhere on the screen(s).
So, how do you combine all the knowledge just learnt to display the tray icon's context menu correctly when DPI scaling is done in the manner above, without making you application per-monitor DPI aware (for per-monitor DPI aware applications GET_X_LPARAM(wParam), and GET_Y_LPARAM(wParam) always return correct value)?
Use NOTIFYICON_VERSION instead of NOTIFYICON_VERSION_4, this will position the mouse cursor at the tray icon when context menu is invoked, and then use GetCursorPos() to get mouse cursor's position. Display the context menu using TrackPopupMenu() with the coordinates.
PS: In the example above the DPI scaling value is changed from 150% to 125%. The context menu deviance is more pronounced when DPI scaling is done from a bigger value to a smaller value, when your tray icon area is on lower right of the screen. This is because when DPI scaling is done, and windows magnifies UI elements which are not per-monitor aware, using DPI virtualization, then things move right-wards, and down-wards. eg. if in an application a windows rectangle is (0,0,100,100) (screen coordinates), then after magnification to 150%, it may become (0,0,150,150). Now for tray icon's menu, if you specify coordinates which lie beyond bottom-right of the screen, then the OS will still display is at a bottom right position which lies inside the screen, and which ensures that menu is displayed properly. eg. if a screen is 1920x1080, and TrackPopupMenu()is given (10000,10000) for menu, the menu will still be displayed inside the 1920x1080 screen rectangle. Thus increasing DPI scaling will not move the context menu any further, if it has already reached the right-bottom most position.
#sahil-singh you are right about it, and I agree with everyone else that your application should be DPI aware, but when this is not a point here.
I had a similar issue where my application is (still) not DPI aware and GET_X_LPARAM(wParam) will return non-virtual coordinates. After passing this value to the TrackPopupMenu() I get wrong position on the screen.
The best way is to use GetMessagePos() instead of wParam. In this case, Windows will give you new DWORD with virtual coordinates and then use GET_X_LPARAM/GET_Y_LPARAM to get a values that you can pass to the TrackPopupMenu().
This seems to (2 years later in 2019) be documented on MSDN:
NOTIFYICONDATAA structure
uCallbackMessage
Type: UINT
When the uVersion member is either 0 or NOTIFYICON_VERSION, the wParam parameter of the message contains the identifier of the taskbar icon in which the event occurred. This identifier can be 32 bits in length. The lParam parameter holds the mouse or keyboard message associated with the event. For example, when the pointer moves over a taskbar icon, lParam is set to WM_MOUSEMOVE.
When the uVersion member is NOTIFYICON_VERSION_4, applications continue to receive notification events in the form of application-defined messages through the uCallbackMessage member, but the interpretation of the lParam and wParam parameters of that message is changed as follows:
LOWORD(lParam) contains notification events, such as NIN_BALLOONSHOW, NIN_POPUPOPEN, or WM_CONTEXTMENU.
HIWORD(lParam) contains the icon ID. Icon IDs are restricted to a length of 16 bits.
GET_X_LPARAM(wParam) returns the X anchor coordinate for notification events NIN_POPUPOPEN, NIN_SELECT, NIN_KEYSELECT, and all mouse messages between WM_MOUSEFIRST and WM_MOUSELAST. If any of those messages are generated by the keyboard, wParam is set to the upper-left corner of the target icon. For all other messages, wParam is undefined.
GET_Y_LPARAM(wParam) returns the Y anchor coordinate for notification events and messages as defined for the X anchor.
I have a multi-monitor Mac desktop (4 displays each of 1920x1080 arranged in a 4x4 rectangle) and can use a mouse to open a window across all monitors, filling the whole four screen desktop.
(am running Mavericks and have disabled the "Displays have separate Spaces" checkbox)
I want to be able to so this automatically, so used AppleScript. However, the window will not open to a height greater than one of the displays (1080 pixels), even though the displays are arranged in a 4x4 matrix so that the total height of the desktop is reported as 2160 pixels. Window width is no problem and the script opens nicely across displays horizontally.
Here is the key part of the AppleScript:
tell application "Finder"
set bounds of first window to {0, 0, 3840, 1800}
end tell
There seems to be some kind of limit on the vertical size of the window. Any ideas how I can achieve automation?
Googling has pulled endless gripes about multi-monitor support on Mavericks but I can't find anything related to this particular issue.
Thanks in advance
BACKGROUND
I've tried this on two multi-monitor display configurations:
Early 2014 Mac Pro.
Four external 1920x1080 monitors arranged landscape in a 2x2 rectangle.
Reported desktop size is {0, 0, 3840, 2160}
MacBook Pro Retina Late 2013:
Two external 1920x1200 monitors arranged one above the other
(and the laptop's own 2880x1800 internal display of course)
Reported desktop size is {0, 0, 3360, 2400}
I don't have multiple monitors to test this, but on my one monitor the (0, 0) point is the upper left corner of my screen. Maybe you need to adjust the second number of your bounds. My suggestion would be to open a window manually by hand. Then run this code to get the bounds. Then try to set the bounds with the returned values. Of course I still don't know if this will work but at least you'll know you're working with the proper bounds. Good luck.
tell application "Finder"
return bounds of window 1
end tell
EDIT: once you know the proper bounds, you might try using System Events to resize the window. System Events doesn't know "bounds", but it does know "position" (the first 2 numbers in your bounds) and "size" (the second 2 numbers in your bounds). Try this with your numbers.
tell application "System Events"
tell process "Finder"
set position of window 1 to {0, 400}
set size of window 1 to {800, 500}
end tell
end tell
Not to revive a dead subject, but with some external dependencies it is possible to resize larger than the monitor resolution. You need a program called MegaZoomer [https://github.com/ianh/megazoomer] ... and you need EasySIMBL [https://github.com/norio-nomura/EasySIMBL].
Install EasySIMBL first, (can be downloaded from http://www.macupdate.com/app/mac/44354/easysimbl ). Then pull down MegaZoomer from (http://www.macupdate.com/app/mac/21275/megazoomer) ... copy the megazoomer package into the EasySIMBL packages dir. You will need to enable the package in SIMBL. You may have to reboot. Then run your applescript and it should work.