wxString is always based on std::[w]string since 2c0c727f49 (Remove wx
own wxStringImpl implementation, 2022-11-16) and all containers use
standard containers by default too now -- and there is a separate
wxUSE_STD_CONTAINERS for this anyhow.
The only remaining use of wxUSE_STL was as the default value for
wxUSE_STD_STRING_CONV_IN_WXSTRING option, but it's not really needed
for this neither, and this option can just be set to 0 by default.
Also add wxUSE_CHAR_CONV_IN_WXSTRING which can now be set to 0 too to
disable all unwanted implicit conversions (even "safe" ones, to wide
strings, in addition to the unsafe ones to narrow strings that could be
already disabled with wxUSE_UNSAFE_WXSTRING_CONV) to allow people who
don't want to have any implicit conversions at all to do it.
Keep --enable-stl configure option for compatibility, but warn if it is
used to tell people that it is not needed any longer.
This is mostly, even if not completely, compatible with the previous
default build using wxUSE_STD_CONTAINERS=0, so try enabling this by
default again. Hopefully it should work better now than the last time we
tried it, see 01871bf642 (Add wxUSE_STD_CONTAINERS and turn it on by
default., 2011-03-30) and the subsequent 7311debd0d (Don't use the
standard containers by default., 2011-05-13).
See #22718.
There was no safe way to prevent wxWindow from trying to destroy the
HWND again if it had been already destroyed, for whatever reason, as
UnsubclassWin() asserted if it was called and calling SetHWND(0) before
calling it as some (but not all) existing code did, resulted in not
removing the association using the old HWND as key.
Allow to use DissociateHandle() for safely detaching HWND from the
window, without assuming that it is valid.
This option can also be used under MSW, so move it to the common setup.h
instead of having it in setup.h.in only.
Also do the same thing for wxUSE_UTF8_LOCALE_ONLY, even if it's less
clear if this one is really useful in non-Unix environment.
This replaces the previously implemented wxWebViewWindowInfo.
It explicitly breaks the previous API to enable WebKitGTK
integration and to make the usage in application code less error prone.
A new event wxEVT_WEBVIEW_NEWWINDOW_FEATURES is added to allow
access to the window features and the child web view.
In 40ff38b63b wxWebView::GetNativeConfiguration() was
added which isn't suitable if multiple wxWebViewEdge instances are created with
different options (as they must share the same options). To prevent such errors
the previous method is replaced by the new class wxWebViewConfiguration which
can be shared between various wxWebView instances.
This explicitly breaks API to improve usage.
In the future the new class could also enable a good way to wrap various
common options/configurations available via native API.
Add new class wxWebViewWindowInfo:
This new class returned by wxWebViewEvent::GetTargetWindowInfo() allows
to get information about the window that is about to be opened and to
set the window that will be used to display the content.
We need to switch to custom-drawing the box if we stop using
WS_EX_COMPOSITED as WS_EX_TRANSPARENT doesn't work correctly without it
(the background is not being painted correctly), so do this by
overriding the new MSWOnDisabledComposited() which is now called by
MSWDisableComposited() if/when it actually does disable it.
This is useful because there is no really standard value for this colour
and the choice of grey (0x808080) is completely subjective, but also
because it may be useful to disable custom drawing of the border
entirely if it results in any problems with the future Windows versions.
See #23107.
Add MSW-specific wxDarkModeSettings class which can be used to customize
the colours used in the dark mode (and will be also used for other
customizations in the future).
This commit is best viewed using Git --color-moved option.
It didn't make any sense to have Create() functions in this class
without the default ctor as they could be never used -- calling them
would result in creating the window twice.
Add the default ctor to make this class more similar to all the other
windows.
Allows to determine if a navigation is happening in the main frame
or an embedded iframe when handling wxEVT_WEBVIEW_NAVIGATING.
Additionally implement previously missing wxEVT_WEBVIEW_NAVIGATING
events for frames with the Edge backend.
See #23238.
Additionally implement wxWebViewEdge::GetUserAgent() via SDK.
This functionality is available with the slightly newer
WebView2 SDK required by previous changes.
See #23225.
Avoid the warning and actually behave correctly when
WXWIN_COMPATIBILITY_3_2==0 by replacing the wrong "#ifdef" added in
c216744f78 (Deprecate MSW-specific wxRadioBox::Set{Label,Button}Font(),
2022-12-24) with the correct "#if".
Closes#23161.
Drop disabled by default and pretty useless memory tracing code and all
the overlapping and poorly documented build options related to it.
Remove memory.cpp entirely and update all the make/project files, but
preserve the now completely trivial wx/memory.h for compatibility and
also keep including wx/string.h from wx/object.h as it seems like a lot
of existing code actually depends on this, even if it should not.
Replace the options in the propgrid sample with a couple of other
debug-related options that were not used before to avoid leaving the
"Debugging Section" completely empty.
We don't always have a wxWindow to pass to this function, so make it
more general at the cost of being slightly more inconvenient to use.
No real changes yet.
Fix labels and highlight colour and get rid of the white line on top of
the toolbar.
Unfortunately drop-down items are still not drawn correctly as I
couldn't find any way to customize the colour used for their arrow.
The labels of these controls were unreadable because they used the same
text colour as in normal, light mode even after enabling dark mode
support for them, so fix this by explicitly setting the default (for
dark mode, i.e. light) text colour for them.
Add a new "setForeground" field to MSWDarkModeSupport struct to allow
doing this easily and in a single place in wxControl code, so that it
could be customized, or even skipped, if these controls support for the
dark mode is improved, in the future.
Overriding either MSWGetDarkThemeName() or MSWGetDarkThemeId() was a bit
confusing as doing the latter changed the theme name used by default too
and not flexible enough, so remove these two functions and add a single
MSWGetDarkModeSupport() one that returns both the theme name and ID and
can also be extended to do more things in the future.
This requires using a couple of undocumented messages/structs, which is
not ideal, but seems to be the only way to get dark menu bar and so
seems to be worth it, as white menu bar looks really out of place in
dark mode.
This allows to avoid having to use casts from RECT to POINT in the rest
of the code by encapsulating this cast, and the comment explaining it,
in this function only.
No real changes.
It was pretty confusing that WindowHDC actually used client HDC and not
the (full) window one.
Also add a helper AutoHDC class releasing the DC automatically in its
dtor and use it as the common base for ScreenHDC and ClientHDC.
No real changes, this is just a renaming/refactoring.
Extract the code setting up the header control colours for the dark mode
from src/msw/listctrl.cpp into wxMSWHeaderCtrlCustomDraw and reuse it in
wxHeaderCtrl too.
Add a helper function wrapping ::GetThemeColor() and use it in all
places where this function was used before, as it's more convenient.
Also remove wxWindow::MSWGetThemeColour() as it was only used in a
single place and doesn't seem to present any advantages compared to
using wxUxThemeHandle new method.
There should be no changes in behaviour, this is just a refactoring.
It doesn't seem to make much sense to have a completely identical
wxMSWListHeaderCustomDraw class used in wxListCtrl when we could simply
reuse wxMSWHeaderCtrlCustomDraw already existing elsewhere, so just do
this now.
No real changes, this is just a refactoring.
Override the newly added MSWGetToolTipMessage() in the controls using
tooltips and apply dark mode to the window returned by this message too
to make sure they appear correctly in dark mode.
Use "ItemsView" theme which draws the items of the control itself in the
same way as Explorer does when using dark mode.
Unfortunately this theme doesn't draw the scrollbars correctly, but this
will hopefully be fixed with another hack later.
We're going to need to use "ItemsView" theme for the header and list
controls, so replace the previously existing MSWGetDarkThemeClass() with
two functions, allowing to customize the name and the ID independently.
No changes yet.
This is not used used yet, but will be soon for getting theme data of
the header control which is part of wxListCtrl but doesn't have any
corresponding wxWindow. It's also useful for using null HWND, which
must be used with the special "ItemsView" theme when using dark mode.
This control doesn't seem to support dark mode natively, whichever theme
is used for it, so paint it in dark mode ourselves simply by inverting
its colours -- this is not great, but passable and better than leaving
it with a light background.
As this probably won't be the only control which will need this,
implement it at wxWindow level and allow the derived classes to opt-in
this "automatic dark mode support" by simply overriding the new
MSWShouldUseAutoDarkMode() function.
Currently the colours used in the dark mode are hard-coded, which
definitely isn't great, but better than nothing and at least allows
using the correct background colour for generic windows, panels and
dialogs.
Also return dark mode-specific colours from wxSystemSettings when it's
active.
This is needed for at least wxStatusBar, although the gripper is still
not drawn correctly even when this particular theme class is used -- but
at least the main part of the status bar now uses the correct colours.
This is the same as the already existing wxMSWImpl::ShouldUseDarkMode()
but has a better name for the use outside of the file implementing dark
mode support.
Use undocumented AllowDarkModeForWindow() and set the window theme to
"EXPLORER" even for the windows for which we don't normally do it (i.e.
not those deriving from wxSystemThemedControl), to show (at least some)
controls correctly in dark mode.
