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.
PNG is a custom clipboard format but images stored in this format are supported by e.g. MS Excel, MS PowerPoint, GIMP (including image transparency).
See #17631.
WKWebView replaces
WebView on macOS (available since 10.10, deprecated since 10.14) and
UIWebView on iOS (available since 8.0 deprecated since 10.0).
Using WKWebView ensures future compatiblity and unifies the interface
used for iOS and macOS.
Allow applying gcc "format" attribute to other functions and do apply it
to wxStrftime().
Also suppress -Wformat-nonliteral inside wxStrftime() itself, as it's
now supposed to be checked when calling it.
When the original wxGCC_WARNING_SUPPRESS was added, clang understood all
gcc warnings, so it made sense to also apply it when building with
clang, but recent gcc versions have added warnings not available in
clang any more, so we now need a macro for disabling warning the
warnings for gcc only.
Perhaps we should rename the existing wxGCC_XXX macros to use
wxGCC_OR_CLANG prefix.
This was already done for clang -Winconsistent-missing-override, but
gcc has a similar warning since 5.1 and, moreover, latest versions of
clang support this gcc warning as well, so add a special macro which
handles both compilers and use it in all wx macros defining virtual
functions instead of just disabling one of the clang warnings.
Closes https://github.com/wxWidgets/wxWidgets/pull/2000
We probably could drop support for some gcc 4.x versions too, but we
definitely don't need to support gcc 3.x any longer and not doing it
simplifies the code a bit, so just assume gcc >= 4.
Closes https://github.com/wxWidgets/wxWidgets/pull/1943
Apply the utility from https://github.com/codespell-project/codespell/
to fix spelling issues in the headers under both include and interface
directories and add a file with a couple of exceptions.
The exact command line used was:
$ codespell -w -I misc/scripts/codespell.ignore -i 3 in*
Define it in wx/defs.h directly instead of conditionally including
wx/windowid.h from there just in order to get this type definition.
This has several advantages:
- wxWindowIDRef is not defined in (maybe) non-GUI code including
wx/defs.h, as it should be the case for this class defined in
core library only.
- wx/windowid.h becomes a normal header, including wx/defs.h as
(almost) all the other ones instead of being exceptional.
- wx/windowid.h doesn't need to be included by wx/utils.h at all
just to get wxWindowID definition.
Closes https://github.com/wxWidgets/wxWidgets/pull/1850
