Newer standard library headers should only be included when the compiler
is targetting that standard, otherwise some compilers (like MSVC) will
warn that you are using a newer C++ include on an older version.
This key produces events with different key codes in wxMSW (WXK_CLEAR)
and the other ports (WXK_NUMPAD_BEGIN), so add a new constant to allow
to refer to it under the same name everywhere.
Also generate a key event for it in wxOSX where it previously wasn't
generated at all.
Closes#23478.
Closes#23491.
This was used by wxGTK 1, which is not supported any longer, and wxX11,
which now always uses Pango instead, so all this code became completely
unused and can be removed to simplify things.
Closes#23442.
This function was not called any longer after 35a8d0f908 (Fix building
wxPropertyGrid with v3.0 compatibility enabled, 2023-03-22), which
silently broke any applications resulting on this to happen, so call it
again, even if it's rather painful and ugly to do.
Also add wxDEPRECATED_BUT_USED_INTERNALLY_MSG() and use it instead of the
plain wxDEPRECATED_MSG() for the deprecated overload of this function to
avoid warnings when calling it from wxWidgets itself.
Finally, document the change to DrawCaptionSelectionRect() as this
wasn't done back in c63b1604b3 (Use native renderer to draw rectangle
indicating that wxPG category property is selected., 2015-08-30) when
its signature was changed.
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.
This macro was still used with clang because it also predefines
__GNUC__, contradicting its name and purpose, as it was always identical
to just wxGCC_WARNING_SUPPRESS.
Only make it do something for gcc now and nothing for clang.
This style never did anything useful in wxMSW and did nothing at all in
all the other ports, so always was rather useless, but became actively
harmful not that WS_EX_COMPOSITED is used in wxMSW because using it and
WS_EX_TRANSPARENT, enabled by wxTRANSPARENT_WINDOW, together doesn't
work and results in an endless stream of WM_PAINT messages being sent to
the _siblings_ of the window with wxTRANSPARENT_WINDOW style.
Assume they are always 1 now, there is no good reason to ever set them
to 0 any more.
Note that we still keep wxUSE_STD_IOSTREAM for now, but we can drop
wxUSE_STD_DEFAULT as it's not worth having it just for this single
option (previously it was used as the default value for 3 of them).
Add wxNODISCARD macro which is defined as [[nodiscard]] if supported,
or the compiler-specific equivalent if one exists or nothing if not
available.
Start using it for some places with a risk of memory leak.
Closes#22943.
The reserved wx IDs were previously in (wxID_LOWEST, wxID_HIGHEST]
range, which was very unusual, as C++ always uses intervals half-open in
the other direction, i.e. [begin, end).
It also conflicted (in theory, if not in practice, as wxID_HIGHEST
wasn't actually used for anything) with the common practice, used even
by wx own samples, of starting the custom IDs at wxID_HIGHEST rather
than wxID_HIGHEST+1.
So change this to use the standard convention, retroactively making all
the code using wxID_HIGHEST valid -- this seems better than insisting on
starting the IDs from wxID_HIGHEST+1.
Closes#22909.
This is a combination of running clang-tidy with modernize-use-nullptr
check for some ports (GTK, X11, OSX) and manual changes to the ports for
which it couldn't be used easily (MSW, DFB) and also manually updating
the docs.
Also replace NULL with null or nullptr in the comments as this is more
consistent with the use of nullptr in the code and makes it simpler to
grep for the remaining occurrences of NULL itself.
And also use null in the assert messages.
Only a few occurrences of "NULL" are still left in non-C files, mostly
corresponding to unclear comments or string output which it might not be
safe to change.
Remove the port files and references to it from the common headers and
elsewhere.
Also remove GPE (GNOME PDA Environment) support as libgpewidget is
unmaintained since 2006 or so and has never been really used.
Use __WXGTK__ to test for any version of wxGTK now. Still define
__WXGTK20__ for compatibility, but always define it now and don't test
for it in the library code.
This port hasn't been updated for ages and is not used by anybody any
longer, so remove its code to facilitate maintenance.
Also remove references to this port from the documentation and most of
the other places (VMS-specific descrip.vms files still check for it
because it's not clear how to update them all), including configure.
Regenerate the latter and rebake all makefiles.
Finally document that this port is not available any longer.
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.
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.
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.
This completes the changes of 5477d4faa8 (Avoid warnings when combining
wxStaticText styles with C++20, 2022-07-20) which, in turn, was based on
3d278ee75f (Avoid warnings about operations on different enums in C++20
mode, 2021-04-25).
Also add a test checking that no warnings are given for all possible
enum values combinations (but this test is only useful when using
C++20).
See #22681.
Because wxStaticText can contain arbitrary combinations of both
alignment and border flags, we need to allow using "|" on them, just as
it was done for a few other enums in 3d278ee75f (Avoid warnings about
operations on different enums in C++20 mode, 2021-04-25).
See #22656.
Closes#22657.
We don't need to declare CGFloat and NSInteger in our own headers when
we can just use double instead of the former in our public headers and
the latter wasn't used in them at all.
Note that this requires including CoreGraphics/CoreGraphics.h from the
private wxOSX headers as several of them do use CGFloat, which wouldn't
be defined otherwise.
Unlike direct tests of __cplusplus, using this macro also works with
(recent enough, i.e. MSVS 2015.3 or later) MSVC versions, even if
/Zc:__cplusplus is not used.
This simplifies some checks and makes some other ones (notably the check
for C++20 used before wxALLOW_COMBINING_ENUMS macro definition) work
with MSVC versions with C++20 support as intended.
Instead of defining a manifest for each individual CPU architecture, use
a single manifest with an asterisk for the architecture.
Should have been part of 77d8926126 (Simplify Windows application
manifests, 2021-12-17).
Closes#22376.
Since VS 2015 Update 3, the C++ standard targeted by the compiler can be
detected through _MSVC_LANG. This macro is like __cplusplus, but reflects the
actual standard understood by the compiler, unlike __cplusplus which by default
is left to an ancient value for compatibility.
Closes#22099.
Add new macros wxDECLARE_DYNAMIC_CLASS_NO_ASSIGN_DEF_COPY() and
wxDECLARE_NO_ASSIGN_DEF_COPY() and use them instead of
wxDECLARE_DYNAMIC_CLASS_NO_ASSIGN() and wxDECLARE_NO_ASSIGN_CLASS()
respectively to ensure that we declare a (default, if possible) copy
ctor in the classes declaring an assignment operator to avoid clang
warnings about not doing it.
No real changes, but don't complicate the constants definitions
needlessly just to avoid changing the numeric value of WXK_LAUNCH_APP
constants as nobody should rely on them anyhow.
Not doing it simplifies things and allows to condense the mapping from
GDK keys to wx ones.
X11 defines Xf86Launch[0-9a-f], which are then also defined as
GDK_KEY_Launch[0-9A-F].
Unfortunately, keys which are not mapped are just plain ignored and the
application is then not able to receive these keyboard events at all.
The original PR https://github.com/wxWidgets/wxWidgets/pull/157 mapped
only LaunchA/B to WXK_LAUNCH_APP1/2, this patch adds the whole range of
keys and keeps LAUNCH_A/B as aliases for WXK_LAUNCH_APP1/2
Move definitions of wxTE_XXX flags that can be used with the controls
other than wxTextCtrl to wx/defs.h, as wxFormBuilder generates code
using them without including wx/textctrl.h, so that this code doesn't
compile.
This was already addressed in 2970f22a89 (Include <wx/textctrl.h> from
<wx/combobox.h> for compatibility., 2012-03-25) for wxComboBox, but it
also happened for wxSpinCtrl, so fix it once and for all by always
defining these styles.
This partially reverts the changes done in c57e33394c ([...] moved
wxTextCtrl-specific stuff from defs.h/event.h to textctrl.h, 2001-07-29)
as it turns out, 20 years later, that this wasn't such a great idea.
See #14132.
Closes#19225.
This gcc version claims support for this attribute, but actually doesn't
support it and returns unclear errors when it is used, e.g.
$ echo '[[deprecated]] int x;' | g++-5 -fsyntax-only -x c++ -
<stdin>:1:1: error: expected unqualified-id before ‘[’ token
so disable its use with gcc < 6.
Add yet another wxDEPRECATED_XXX macro, this one simply expanding to
C++14 [[deprecated]] attribute if it's available and nothing otherwise.
It's a bit ridiculous to have so many different macros for deprecating
things, but the new one is useful because the standard attribute can be
used to deprecated enum elements, which is impossible with MSVC-specific
__declspec(deprecated).
Disabling -Wsuggest-override inside macros is broken in gcc, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55578, and has started
affecting wxWARNING_SUPPRESS_MISSING_OVERRIDE since gcc 11, i.e. this
macro doesn't have any effect any more and the warning is still given.
Avoid it by actually specifying "override" for gcc 11 (as doing it for
all compilers would result in -Winconsistent-missing-override from
clang) and check that we don't get this warning in the allheaders test.
Also don't use wxDECLARE_ABSTRACT_CLASS() inside wxObject itself, now
that it uses "override", which is not appropriate for the base class
version. This is arguably more clear and should have been done like this
since the beginning anyhow.
Arithmetic operations on the elements of different enums are deprecated
in C++20 and the latest compiler versions warn about them.
While individual warnings could be fixed in wxWidgets itself (although
it would be quite an effort to do it for all ~500 of them), it wouldn't
help with the same warnings in the applications using wx, so prefer to
do it by explicitly defining the operations on the enums that can be
combined with each other by using wxALLOW_COMBINING_ENUMS() macro,
except for a single warning in wxTar code where it's easier to just not
use an anum at all.
C++20 deprecates arithmetic operations with the elements of different
enums and at least clang 10 and MSVS 2019 already warn about this when
compiling in C++20 mode, so avoid such operations at least in the public
headers to avoid warnings in the applications using wxWidgets and C++20.
