I have a program which was created in VS2008 with MFC.
Now I've modified it to make it "Per Monitor DPI-Aware", and it's almost done. I've modified the manifest and handled the WM_DPICHANGE message. But there's still one problem:
I used CFileDialog class to show Open/Save dialogs, and used SHBrowseForFolder function to show folder selection dialog. But all these dialogs are NOT "Per Monitor DPI-Aware", they won't adjust their UI when you move them between monitors with different DPI settings.
I use spy++ to monitor messages of these dialogs, I find they can receive WM_DPICHANGED message but they just don't handle it.
And I've tested the open file dialog in notepad.exe on Windows 10, it worked perfectly.
Does anyone know how can I make these dialogs "Per Monitor DPI-Aware"?
--------EDIT--------
There're two more problems:
When I move a window to a monitor with different DPI, the window resize itself, but the height of it's title bar and title font-size are not changed.
The checkbox controls' box size is not changed either.
I feel these problems may have some kind of connections, but I can't figure it out.
--------SAD NEWS--------
I compiled microsoft's "DPI Tutorial Sample" with VS2013, and it has the same problem.
https://code.msdn.microsoft.com/DPI-Tutorial-sample-64134744
The titlebar (caption bar) can be scaled by calling EnableNonClientDpiScaling which is available on versions of Windows >= the Windows 10 Anniversary Update (1607).
If you want to DPI scale an older dialog that doesn't support per-monitor DPI scaling you can use SetThreadDpiAwarenessContext (with DPI_AWARENESS_CONTEXT_SYSTEM_AWARE or DPI_AWARENESS_CONTEXT_UNAWARE) to have the top-level windows of the dialog scaled by Windows. The dialog might be blurry but it will at least be sized correctly (also only available on >= 1607 builds of Windows 10). The usage pattern is to call this API before opening the dialog and then restore the previous DPI context immediately after calling the API.
According to MSDN the window that processes WM_DPICHANGED message should return 0. However, any MFC window or control you send WM_DPICHANGED will return 0, since thay call the default window procedure for the unknown messages.
Therefore, judging if some window does process WM_DPICHANGED message by testing its LRESULT return value against zero is not accurate.
The window's title bar of a per-monitor DPI aware application doesn't scale when moving across different DPI monitors as documented on MSDN. Unfortunately, non-client area of the window never adjust the DPI.
Calculator and other per-monitor DPI aware Windows native apps have custom title bar drawing, as described here.
Related
I setup per-monitor DPI scaling in a Win32 app, and my part works fine, however opening up a dialog box created in the resource editor doesn't scale itself (I would think using dialog units, it would).
Is there a way to scale everything from a dialog resource and be compatible with, say, Win8.1, as well as Win10, and even Win7?
Per-Monitor and Per-Monitor (V2) DPI Awareness:
It is recommended that desktop applications be updated to use
per-monitor DPI awareness mode, allowing them to immediately render
correctly whenever the DPI changes. When an application reports to
Windows that it wants to run in this mode, Windows will not bitmap
stretch the application when the DPI changes, instead sending
WM_DPICHANGED to the application window. It is then the complete
responsibility of the application to handle resizing itself for the
new DPI. Most UI frameworks used by desktop applications (Windows
common controls (comctl32), Windows Forms, Windows Presentation
Framework, etc.) do not support automatic DPI scaling, requiring
developers to resize and reposition the contents of their windows
themselves.
You can resize the dialog box in the WM_DPICHANGED message.
case WM_DPICHANGED:
{
LPRECT lpRect = (LPRECT)lParam;
SetWindowPos(hWnd, nullptr, lpRect->left, lpRect->top, lpRect->right - lpRect->left, lpRect->bottom - lpRect->top, SWP_NOZORDER | SWP_NOACTIVATE);
return 0;
}
Updated:
For per-monitor DPI, v2 is the only one that can handle the dialog DPI scale., v1 does not so on WIndows 8.1 and older versions of Window 10, it has to be done manually. Windows 8.1 and older Windows 10, we don't scale controls. So the solution should be just resize the dialog. It has to enumerate all controls and resize them during WM_DPICHANGED if the dialog is not resizable.
I am making an addon for Firefox. Firefox is set to Process_System_DPI_Aware. I have handles to the monitors, is it possible to get the correct monitor rect?
All methods I tried so far are giving me the DPI of the primary monitor.
I thought to use LogicalToPhysicalPointForPerMonitorDPI as it says it should work however I don't have a window to give to the function. The second monitor has no windows on it. I'm trying to take a screenshot of that desktop.
Thanks
You are using per-monitor dpi settings but your process is not per-monitor dpi aware. Thus, your secondary monitor has dpi virtualization.
You should perform your screenshot code from a per-monitor dpi aware process.
You can create invisible window, enumerate monitors using EnumDisplayMonitors, get virtualized rects using GetMonitorInfo, move and resize invisible window fullscreen for each monitor, and get real monitor rect using LogicalToPhysicalPointForPerMonitorDPI.
I have a hidden process that waits for non-standard hardware button messages and runs an application (with CreateProcess). No problem with the user disturbing, it's an action that the user approved himself. Everything is fine when it's usual layout with taskbar shown and multiply captioned and non captioned- windows. But the situation is different in XP and 7, when the current application is full-screen. Full-screen application in this case is window without borders having exactly the same dimension as the screen. Windows hides taskbar for such application even if it's always on.
In Xp, it's ok, the taskbar is being shown in this case and appication (for example calculator) also, the full-screen app is still visible in areas other than the launched app's and taskbar'. But in Windows 7 nothing visual happens, the full-screen app is still on and if I switch to taskbar, the executed application is there. I tried to solve it with SetForegroundWindow, BringWindowToTop, even AllowSetForegroundWindow(GetCurrentProcessId()) call for a window handle found with CreateProcess-WaitForIntputIdle-EnumThreadWindows, no change. So did something change since XP related to full-screen windows that officially documented?
Thanks,
Max
I would imagine that, if you have your own hardware device, that there is some API for generating "real" user input. Clearly the legacy keyboard and mouse, and now USB HID drivers (many of which are usermode I think?) have access to an API to do so.
Synergy+ for example can generate fake keyboard and mouse events on connected PCs, and the consequence of the faked input is windows switching activation normally.
So, my initial idea is for your usermode "Device" application to synthesize actual keyboard messages - SendInput seems a likely candidate for "the API that can "fake" real user input events.
Then, use an API like RegisterHotKey in your "UI" app to respond to the hotkey combination your device app generates.
Now, (assuming that SendInput IS generating user input events at the correct level), you should (from within the WM_HOTKEY handler in your UI app) have permission (because everything was "user initiated") to change the foreground window (to yourself).
Vista introduced the desktop composition feature. In short, all windows are drawing to a memory bitmaps and the Desktop Window Manager is then composing these bitmaps and drawing on a full-screen Direct3D surface. Full-screen windows do not participate in the desktop composition and get to draw directly on the screen (mostly because the majority of full-screen apps are games that need real-time screen updates).
In particular, this means that when a full screen app is up and running, it is covering the DWM composed image and the user needs to switch to a DWM-managed window for the DWM to start drawing on top of the full-screen app.
I don't have a good solution for your problem, unfortunately. One way to solve it would be to add the WS_CAPTION style to your app and then handle WM_NCPAINT/WM_NCCALCSIZE/WM_NCHITTEST yourself. This would allow you to lie to the DWM that you are a regular windowed application, but change visually your NC area to look like you have no title. However, this does require certain amount of additional code and might be a bit more effort you want to invest.
Another way you can try to solve your problem is to explicitly minimize your full-screen application window when launching the new process. However, you will then have to solve the problem of when to maximize it back again.
Btw, you might find the comments on this post from Raymond Chen interesting.
Windows supports multiple desktops and my guess would be that the full screen up is using a different desktop than the default one (where your application will be shown). A desktop object in Windows is "a logical display surface and contains user interface objects such as windows, menus, and hooks". For example, screen savers normally are started on a separate desktop.
You can find out which desktop an application is running on using Process Explorer:
Set Process Explorer to replace Task Manager and to run always on top.
When your full screen up is shown, launch Process Explorer by pressing Ctrl + Shift + Esc
Within Process Explorer, select the full screen process and press Ctrl + H to display the handles of this process
See the value of the Desktop item in the list. Usually this would be set to Default
If you know what desktop this app is running on you can start your process on the same desktop by first calling OpenDesktop to get a handle to this desktop and then pass it into the STARTUPINFO of your CreateProcess call.
This question is more academic than practical and doesn't involve any one specific language. For the sake of discussion, we'll use Win32 API.
What is the most appropriate way to create a window with the following behavior goals:
Z-Order is lower than every other window except the desktop surface.
Cannot be made to appear on a higher z-order than other windows through mouse or keyboard clicks.
Assumption may be made that the window is borderless.
There are two basic approaches here :-
make your window the 'child' of the desktop.
make your window simply refuse to accept focus or activation :-
The wonder of the windows window manager is that there isn't one. Rather, there is an appearance of a window manager as a result of the emergent behavior of all the windows in the system - namely how they react to messages - which in 99% of cases is handeld by DefWindowProc.
Which means that you can subvert a lot of normal window manager type behaviour by handling messages before DefWindowProc. If you create a window, and position it using the relevent flags at the bottom of the z-order with SetWindowPos, and then handle messages like WM_WINDOWPOSCHANGING, you can ensure that your window never receives activation or focus and always - even when other apps call SetWindowPos - always has the z-bottom flag set.
both approaches are problematic as its very difficult to find out what the desktop window is. GetDesktopWindow returns a handle to a window that is only ever visible if explorer crashes. The rest of the time, the visible desktop is a window created by explorer - ultimately a syslistview control. Spy++ + Findwindow will get you a handle to the window you want to be above.
We noticed that on W7 with DPI set to > 125% or to > 100% with ("Use windows xp style dpi scaling") turned off, our fullscreen mode (which sets the client rect of our window = desktop rect of the main monitor) no longer hides the task bar like it does for other settings.
(The setting can be found in the Control Panel\Appearance and Personalization\Display section after clicking on the "Set custom text size (DPI)" link)
I found the following interesting article:
http://www.mathies.com/weblog/?p=908
So I set out to try to work around the bug in other means than manually hiding/restoring the taskbar visibility but so far I've failed and currently believe it's a bug in W7 (and possibly vista).
The following applications also fail to work properly in fullscreen mode (the taskbar is still visible):
* Microsoft Visual Studio 2008
* Microsoft Word 2007
* Adobe Reader 9.1.3
These apps work (probably by hiding the task bar through the WIN32 API):
* Powerpoint Slide Show
I also tried creating a brand new MFC-based app and use its "SetFullScreenMode()" functionality but it fails in the same way as all other apps on the list.
For now it seems the only temporary fix which has worked for me is to disable display scaling on high DPI settings for the program your using fullscreen with.
To do this goto properties (right-click the program's shortcut) >> compatability >> and check the option to disable display scaling on high DPI settings.
The only drawback is that you will not get the higher DPI for that program but the taskbar should hide when fullscreen is enabled.
This is a problem that I understand Windows 7 developers are aware of but have not come out with a solution.