2

I have two monitors connected to my desktop. A 3840x2160 main monitor on the left set to 150% scaling (144 DPI) and a 1920x1080 monitor on the right set to 100% scaling (96 DPI). The are aligned on the bottom edge. This is on Windows 8.1, but the same issue occurs on Windows 10.

My application is C++ using native Win32 windows. It is set at per-monitor DPI aware.

I have a dialog window that is a borderless (not title bar either) window with a custom title bar inside the client area. The user can drag this custom title bar to move the window, and internally it gets moved using SetWindowPos().

When this window is dragged from the High-DPI left monitor over to the regular monitor on the right, I get a WM_DPICHANGED message. The current RECT for the window is: curRect = {LeftTop(3527, 1099) RightBottom(4157, 2098) WidthHeight[630 x 999]}

The new suggested RECT that the WM_DPICHANGED message gives me is: newRect = {LeftTop(3527, 1099) RightBottom(3947, 1765) WidthHeight[420 x 666]}

If I pass the new RECT to SetWindowPos as the documentation for WM_DPICHANGED suggests, then the window is now considered back on my high-DPI monitor, and in the SetWindowPos() I get another WM_DPICHANGED message telling me to change the window pos/size again. This occurs before my original WM_DPICHANGED event has returned.

This makes sense based on the new suggested RECT since the left edge doesn't get moved, but the width is getting reduced. The WM_DPICHANGED message for the same window doesn't have this issue if I'm using an actual non-client titlebar. The left edge is moved in the new suggested RECT.

Any suggestions on how to handle this? Any way to minimally change the new suggest RECT such that it ensures the window w/h is as suggested, but it's positioned so it doesn't fire another DPICHANGED event (stays on the new monitor).

Thanks!

mb13
  • 139
  • 12
  • Sounds like a Windows bug to me. Is there any reason why you can't put your custom titlebar outside the client area? – Anders Mar 17 '17 at 23:05
  • See https://www.codeproject.com/Articles/18400/How-to-move-a-dialog-which-does-not-have-a-caption for two ways to have Windows handle the window dragging, which might fix your problem. – Jonathan Potter Mar 18 '17 at 07:51
  • @Anders, the UI is user-built, and they can potentially flag any part of the UI as a dragable portion of the window, even right in the middle of the UI. So I don't think that would work. Also the UI is drawn with OpenGL, which I don't think would work well for drawing to non-client areas. Thanks for the suggestion though. – mb13 Mar 20 '17 at 19:04
  • @JonathanPotter, that is very helpful, it does seem to solve the issue by letting Windows do the re-positioning instead of us doing it ourselves manually. I'll dig into that more. Thanks! – mb13 Mar 20 '17 at 19:05
  • @mb13 Did you ever manage to fix this problem? – tambre Jul 14 '17 at 17:58
  • I used the method described in the codeproject article Jonathan Potter linked to. – mb13 Jul 17 '17 at 15:31

0 Answers0