Advise to skip wxDPIChangedEvent when handling them in the manual
Not skipping them is almost invariably a bug, as shown by the grandparent commit.
This commit is contained in:
parent
2cae38502f
commit
f5e0076f04
@ -3426,6 +3426,11 @@ public:
|
|||||||
all program windows on the given display if its DPI changes due to a change
|
all program windows on the given display if its DPI changes due to a change
|
||||||
in the system settings.
|
in the system settings.
|
||||||
|
|
||||||
|
If you define an event handler for this event, you should almost always
|
||||||
|
call @c event.Skip() in it in order to allow the base class handler to
|
||||||
|
execute, as many controls rely on processing this event in order to update
|
||||||
|
their appearance when the DPI changes.
|
||||||
|
|
||||||
Currently this event is generated by wxMSW port if only and only if the
|
Currently this event is generated by wxMSW port if only and only if the
|
||||||
MSW application runs under Windows 10 Creators Update (v1703) or later and
|
MSW application runs under Windows 10 Creators Update (v1703) or later and
|
||||||
is marked as being "per-monitor DPI aware", i.e. contains a @c dpiAwareness
|
is marked as being "per-monitor DPI aware", i.e. contains a @c dpiAwareness
|
||||||
|
Loading…
Reference in New Issue
Block a user