On Wed, 29 Mar 2023 22:52:11 -0700 (PDT) AsmWarrior wrote:
A> Hi, when the application receive a wxEVT_DPI_CHANGED event, how can it
A> response to the event?
This depends on where you're handling it. If you handle it for some custom
widget, you would typically recompute any cached DPI-dependent metrics in
this handler. If you handle it for the TLW, you could redo the layout
taking the new DPI into account if the automatic layout update (basically,
scaling everything by the new-to-old DPI ratio) doesn't produce the best
A> I looked at the wxWidgets' sample code "display", it looks like it does
A> nothing, but just show some text in the status bar:
A> void MyFrame::OnDPIChanged(wxDPIChangedEvent& event)
A> wxLogStatus(this, "DPI changed: was %d*%d, now %d*%d",
A> event.GetOldDPI().x, event.GetOldDPI().y,
A> event.GetNewDPI().x, event.GetNewDPI().y);
A> But if we need to layout the UIs, do we need to call the ResetMode()
A> function of the wxDisplay class?
No, you never need to call this function nor ChangeMode(). This is about
changing the display resolution and is something you basically never do.
A> I even did some test about the DPI changing, and I think if ResetMode() is
A> not called, the layout is wrong, you can see the discussion and image shots
A> here in the:
A> How does the FromDIP function work under different DPI scaling? —
A> Any suggestions? Thanks!
I don't really understand what the problem is after looking at the
screenshots in the post above. It seems perfectly normal that a 250*50
button becomes of 375*75 size at 150% DPI scaling.
Have you read https://docs.wxwidgets.org/latest/overview_high_dpi.html ?
I've tried explaining high DPI support in wxWidgets as well as I could
On Thu, 30 Mar 2023 17:51:50 -0700 (PDT) AsmWarrior wrote:
A> OK. So, it looks like the ResetMode() function is just for debug only?
No, but it's just almost completely unrelated to high DPI support. The
"modes" shown by the display sample are different video modes supported by
the display, but you typically don't care about those, and definitely never
change them (except for demonstration purposes, like this sample does).
A> I would suggest that a minimal sample code should be put in this document,
A> so that people(like me) can understand quickly.
It's not really clear what should such sample code demonstrate. As you
wrote, in most cases you don't need to explicitly handle the DPI change at
all, and when you do need to handle it, it means something relatively
complicated (and hence difficult to show in a sample) is going on.
Please read https://www.wxwidgets.org/support/mlhowto.htm before posting.
You received this message because you are subscribed to the Google Groups "wx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wx-users+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wx-users/af6073ad-2ba0-43f8-94d2-d2c156fa6bcfn%40googlegroups.com.
Actually my comment about wxWindow::FromDIP is invalid. It shouldn't matter if you use wxWindow:: prefix.
I am not sure why using the Reset mode button results in a button with the wrong size. I cannot seem to reproduce this.
To view this discussion on the web visit https://groups.google.com/d/msgid/wx-users/70175682-4376-4f62-a22f-7aa57b54d0f7n%40googlegroups.com.
Using 0 as the window parameter will indeed cause it to use the DPI of the main display.
I think I couldn't reproduce because I moved FromDIP(wxSize(250,50)); (without the 0) to a separate line so I could debug the return values.
You are allowed to call FromDIP/ToDIP with a nullptr window, wxWidgets internally does it too.
So I'm not sure if something like wxLogDebug("Determining DPI without a valid wxWindow"); can be added.
To view this discussion on the web visit https://groups.google.com/d/msgid/wx-users/d55b16b5-2aed-462c-940b-9e0e8ea96a0bn%40googlegroups.com.
When I move the application between displays with different DPI, I only get breakpoint2 (OnDPIChanged).
When I have the application on a display, and change the DPI of that display in the Windows settings, it hits both breakpoints.
I get breakpoint2 first (OnDPIChanged) and then breakpoint1 (via OnDisplayChanged). So opposite to what you get.
(Windows 10.0.19045, latest Visual Studio 2022).
Even without breakpoints I can see this behavior, because it shows 'Display resolution was changed' in the status bar, and not ''DPI changed: ...'.
These events are direct responses to Windows messages (WM_DPICHANGED and WM_DISPLAYCHANGE).
We don't have any influence on the order of these events.