Always use std::unordered_{map,set} when we use them at all, don't
bother with checking for their availability and with tr1 or even older
alternatives.
Simplify the code checking for _MSC_VER or __VISUALC__ or using
wxCHECK_VISUALC_VERSION() macro (which is not very useful any longer,
but keep it in case we need it again in the future).
Don't bother checking for various C++11 features that are available in
all C++11 compilers.
Also assume that std::exception_ptr is available in all still supported
MinGW versions and remove checks for it too (see #16634).
Further simplifications remain possible, this is just the first step.
For no obvious reason the generic calendar control used
a read-only wxComboBox until now.
While this is more or less identical to a wxChoice on MSW,
it is somewhat different on OSX and Gtk: Whereas a wxChoice
can be opened by clicking anywhere on it, a wxComboBox requires
clicking on the arrows on the right edge. A wxComboBox
allows selecting and copying the current value, but this is
probably not terribly useful in a calendar.
See #22853.
No real changes, this is just a refactoring moving the code recreating
the native MSW combobox into wxComboBox itself, as it seems better to do
this in this class itself rather than outside of it.
This commit is best viewed with Git --color-moved option.
Using HandleWindowEvent() from the WebView2 event callbacks
is a common error source when user code does something blocking
like RunScript() or ShowModal().
Queue the events to prevent this where possible, in
wxEVT_WEBVIEW_NAVIGATING at least warn the developer instead
of hanging silently.
Closes#22834, #22744, #19075
While we selected the icon of the size most appropriate for the current
DPI when the window was created, we didn't update the icon later if the
DPI changed as we should, so do it now.
Note that we abuse the existing MSWUpdateFontOnDPIChange() to make it
simple to backport this fix to 3.2 without breaking the ABI.
See #22807, #22831.
Calling wxThreadSpecificInfo::ThreadCleanUp() in CallEntry() was
premature as thread-specific info could be recreated later, e.g. due to
any wxLogXXX() call, so don't do it there, but do it in the
platform-specific code just before exiting the thread.
As this renders CallEntry() useless, remove it entirely.
This avoids -Wuninitialized gcc warnings in wxFDIOHandlerMap expansion
when using -Og optimization level: apparently it is enough to enable
this warning but not enough to discard the function which doesn't seem
to be actually used (as it doesn't result in this warning in a really
optimized build).
Use the old names for these keys too for compatibility with the really
old GTK versions, just as we already did for a bunch of other ones.
This should have been done in 61d835d8b3 (wxKeyCode: add
WXK_LAUNCH_[0-9A-F] for gtk bindings, 2021-11-01), see #2575, but was
forgotten there.
Closes#22830.
Using NULL attributes list was not the same as using default
wxGLAttributes, but used a platform-dependent set of attributes that was
traditionally used by old wxWidgets versions for compatibility.
However these attributes didn't specify some important attributes,
notably depth buffer size, and relied on OpenGL driver using some
reasonable defaults, but this turns out to not be the case any more and
resulted in not enabling depth buffer at all, see #22787.
Fix this by using the same default attributes as were already used by
wxGLAttributes::Defaults() in this case, as this is much more useful,
even if not 100%-compatible with the old behaviour.
See #22828.
No real changes, just add a helper function and call it instead of using
m_wlSubsurface directly.
This has the advantage of reusing the same code as in CreateSurface()
and also avoids making m_wlSubsurface public unnecessarily, as was done
in the parent commit.
Check for WXBUILDING when defining wxDEPRECATED_EXPORT_CORE() and don't
actually include the "deprecated" part in this macro when building wx
itself to avoid warnings during the build (which are suppressed when
building wxGTK3 but not the other ports).
This should have been part of 2d939a3665 (Add wxDEPRECATED_EXPORT_CORE()
macro for wxTransformMatrix, 2022-09-18), see #22790.
This commit is best viewed ignoring whitespace-only changes.
See #22820.
We have to use this function for wxWindowDC implementation and setting
drag-and-drop icons, even though it is deprecated, as this API can't be
implemented otherwise, so suppress the deprecation warnings about doing
it.
Also include the private GTK header in the Cairo wxGraphicsContext
implementation just to avoid the deprecation warnings there too.
Use wrapper functions just to avoid the warnings for them, as we want to
keep calling them for compatibility, even if the functions are
deprecated in GTK since a very long time.
The new wx_gdk_device_get_window_at_position() can be used instead of
gdk_window_at_pointer() without, or with reduced number of, GTK version
preprocessor checks, while wx_get_gdk_device_from_display() is needed to
call it anyhow and also allows to avoid differentiating between GTK 3
and 4 in another place.
We don't need to flush all the displays, do it just for the one we're
working with, which seems to be relatively important when we do it in
every call to gtk_window_motion_notify_callback() (while there is a
mouse capture).
wxDEPRECATED_MSG() and WXDLLIMPEXP_CORE can't be used together in the
same declaration when the former uses the standard attribute ([[...]])
and the latter uses a legacy one (__attribute__((....))), at least not
with gcc 12.
Work around this problem by defining a special new macro that combines
both attributes in a working way.
This is rather ugly, as it would seem to be better to just always define
WXDLLIMPEXP_CORE using the standard attribute, but unfortunately this
doesn't work as the standard attribute must be placed before the
function and variable declarations, while we currently use our DLL
export macros in the middle of the declaration. Maybe we can change all
the declarations doing this later, but for now this is the simplest
solution to the immediate problem.
See #22790.
Currently custom protocols are not supported. Implement using
virtual hosts and emulate custom protocol loading in LoadURI().
While this is not a exact match it will at least work without
code changes in many common cases.
The new method an associated classes allow for a more detailed
handling in wxWebViewHandler instances.
Most notibly post data and headers from the request can be processsed.
The response can be send asynchronously.
