#if defined(WX_CPU_AMD64)
#if defined(cbDPI_AWARE_ON)
wxMANIFEST_ID RT_MANIFEST "amd64_dpi_aware_on.manifest"
#warning Manifest: amd64_dpi_aware_on.manifest
#else
wxMANIFEST_ID RT_MANIFEST "amd64.manifest"
#warning Manifest: amd64.manifest
#endif
For C::B to react to the DPI change it should handle the wxDPIChangedEvent (https://docs.wxwidgets.org/latest/classwx_d_p_i_changed_event.html#a1dbcf256f7fd54cd70773e0795b678f5), new in wx3.1.3 and, AFAIK it is not handled currently. Also, it is only generated on Windows 10 1703+
In the link there is more information about DPI handling and manifests.
EDIT: Dragging the window will not generate this event, we could generate it programatically.
For C::B to react to the DPI change it should handle the wxDPIChangedEvent (https://docs.wxwidgets.org/latest/classwx_d_p_i_changed_event.html#a1dbcf256f7fd54cd70773e0795b678f5), new in wx3.1.3 and, AFAIK it is not handled currently. Also, it is only generated on Windows 10 1703+
EDIT: Dragging the window will not generate this event, we could generate it programatically.
For C::B to react to the DPI change it should handle the wxDPIChangedEvent (https://docs.wxwidgets.org/latest/classwx_d_p_i_changed_event.html#a1dbcf256f7fd54cd70773e0795b678f5), new in wx3.1.3 and, AFAIK it is not handled currently. Also, it is only generated on Windows 10 1703+
In the link there is more information about DPI handling and manifests.
EDIT: Dragging the window will not generate this event, we could generate it programatically.
Thanks, I believe it is a bit hard to fix such issue.
One issue I see from the cc_manager is that the tip window shown on the screen has the different font size as the editor's font.
Here is the screen shot of a PC running Win11 with DPI setting as 150%. It also happens on other Win10 with DPI setting of 125%.
My experience is that this problem goes away when the Editor/OtherEditorSettings/Technology is set to DirectWrite.Hi, Pecan, thanks. Yes, enable DirectWrite can solve calltip font size issue, but the DirectWrite cause other issue. The main problem is that it will crash if you use C::B from remote desktop. I have report this crash issue long time ago(either in wxWidgets' github or in our C::B forum), it was not fixed yet. Not sure how complex to handle it correctly, the main point is the Direct Draw surface should be cleared once an editor get closed.
IME, moving a window between monitors with different DPI does generate wxDPIChangedEvent, as long as the application is marked as PMv2 aware.
Is any of this true (I'm always skeptical of ChatGPT), and if so, is it of any use to us?For my experience: Sometimes, ChatGPT can give you a sample wx code. Most of the time, the code can't be built, it has many build errors.