Version: 3.2.8
Loading...
Searching...
No Matches
Preprocessor Symbols

These are preprocessor symbols used in the wxWidgets source, grouped by category (and sorted by alphabetical order inside each category). All of these macros except for the wxUSE_XXX variety is defined if the corresponding condition is true and undefined if it isn't, so they should be always tested using #ifdef and not #if.

GUI system

__WXBASE__Only wxBase, no GUI features (same as wxUSE_GUI == 0)
__WXDFB__wxUniversal using DirectFB
__WXGTK__GTK+
__WXGTK127__GTK+ 1.2.7 or higher
__WXGTK20__GTK+ 2.0 (2.6) or higher
__WXGTK210__GTK+ 2.10 or higher
__WXGTK218__GTK+ 2.18 or higher
__WXGTK220__GTK+ 2.20 or higher
__WXGTK3__GTK+ 3.0 or higher
__WXMAC__old define, same as __WXOSX__
__WXMOTIF__Motif
__WXMOTIF20__Motif 2.0 or higher
__WXMSW__GUI using Windows Controls. Notice that for compatibility reasons, this symbol is defined for console applications under Windows as well, but it should only be used in the GUI code while __WINDOWS__ should be used for the platform tests.
__WXOSX__OS X GUI using any Apple widget framework (AppKit or UIKit)
__WXOSX_IPHONE__iPhone (UIKit)
__WXOSX_COCOA__macOS using Cocoa (AppKit)
__WXOSX_MAC__macOS (Cocoa)
__WXPM__OS/2 native Presentation Manager (not used any longer).
__WXXT__Xt; mutually exclusive with WX_MOTIF, not implemented in wxWidgets 2.x
__WXX11__wxX11 (__WXUNIVERSAL__ will be also defined)
__WXWINE__WINE (i.e. WIN32 on Unix)
__WXUNIVERSAL__wxUniversal port, always defined in addition to one of the symbols above so this should be tested first.
__X__any X11-based GUI toolkit except GTK+

wxOSX is the successor of the venerable wxMac, it currently exists in two versions: Cocoa for the desktop and a very early iPhone port. To summarize:

  • If you want to test for wxOSX on the desktop, use __WXOSX_MAC__.
  • If you want to test for wxOSX on the iPhone, use __WXOSX_IPHONE__.
  • If you want to test for any port under macOS, including, for example, wxGTK and also wxBase, use __DARWIN__ (see below).

The convention is to use the __WX prefix for these symbols, although this has not always been followed.

Operating Systems

__APPLE__any Mac OS version
__AIX__AIX
__BSD__Any *BSD system
__CYGWIN__Cygwin: Unix on Win32
__DARWIN__OS X (with BSD C library), using any port (see also __WXOSX__)
__DATA_GENERAL__DG-UX
__FREEBSD__FreeBSD
__HPUX__HP-UX (Unix)
__GNU__GNU Hurd
__LINUX__Linux
__MACH__Mach-O Architecture (OS X only builds)
__OSF__OSF/1
__QNX__QNX Neutrino RTOS
__SGI__IRIX
__SOLARIS__Solaris
__SUN__Any Sun
__SUNOS__Sun OS
__SVR4__SystemV R4
__SYSV__SystemV generic
__ULTRIX__Ultrix
__UNIX__any Unix
__UNIX_LIKE__Unix, BeOS or VMS
__VMS__VMS
__WINDOWS__Any Windows platform, using any port (see also __WXMSW__)
__WIN16__Win16 API (not supported since wxWidgets 2.6)
__WIN32__Win32 API
__WIN64__Win64 (mostly same as Win32 but data type sizes are different)
__WINE__Wine

Hardware Architectures (CPU)

Note that not all of these symbols are always defined, it depends on the compiler used.

__ALPHA__DEC Alpha architecture
__INTEL__Intel i386 or compatible
__IA64__Intel 64 bit architecture
__POWERPC__Motorola Power PC

Compilers

__BORLANDC__Borland C++. The value of the macro corresponds to the compiler version: 500 is 5.0 (not used any more).
__DIGITALMARS__Digital Mars (not used any more).
__GNUG__Gnu C++ on any platform, see also wxCHECK_GCC_VERSION
__GNUWIN32__Gnu-Win32 compiler, see also wxCHECK_W32API_VERSION
__INTELC__Intel C++ compiler
__MINGW32__Either MinGW32 or MinGW-w64 in either 32 or 64 bits
__MINGW32_TOOLCHAINMinGW32 only (32 bits only right now)
__MINGW64__MinGW-w64 in 64 bit builds
__MINGW64_TOOLCHAIN__MinGW-w64 in either 32 or 64 bit builds
__SUNCC__Sun CC, see also wxCHECK_SUNCC_VERSION
__SYMANTECC__Symantec C++ (not used any more).
__VISAGECPP__IBM Visual Age (OS/2) (not used any more).
__VISUALC__Microsoft Visual C++, see also wxCHECK_VISUALC_VERSION. The value of this macro corresponds to the compiler version: 1020 for 4.2 (the first supported version), 1100 for 5.0, 1200 for 6.0 and so on. For convenience, the symbols __VISUALCn__ are also defined for each major compiler version from 5 to 12, i.e. you can use tests such as #ifdef __VISUALC7__ to test for compiler version being precisely 7.
__XLC__AIX compiler
__WATCOMC__Watcom C++. The value of this macro corresponds to the compiler version, 1100 is 11.0 and 1200 is OpenWatcom (not used any more).

Feature Tests

Some library features may not be always available even if they were selected by the user. To make it possible to check if this is the case, the library predefines the symbols in the form wxHAS_FEATURE. Unlike wxUSE_FEATURE symbols which are defined by the library user (directly in setup.h or by running configure script) and which must be always defined as either 0 or 1, the wxHAS symbols are only defined if the corresponding feature is available and not defined at all otherwise.

Currently the following symbols exist:

wxHAS_3STATE_CHECKBOXDefined if wxCheckBox supports wxCHK_3STATE flag, i.e. is capable of showing three states and not only the usual two. Currently defined for almost all ports.
wxHAS_ATOMIC_OPSDefined if wxAtomicInc() and wxAtomicDec() functions have an efficient (CPU-specific) implementation. Notice that the functions themselves are always available but can be prohibitively slow to use when implemented in a generic way, using a critical section.
wxHAS_BITMAPTOGGLEBUTTONDefined in wx/tglbtn.h if wxBitmapToggleButton class is available in addition to wxToggleButton.
wxHAS_CONFIG_TEMPLATE_RWDefined if the currently used compiler supports template Read() and Write() methods in wxConfig.
wxHAS_DEPRECATED_ATTRDefined if C++14 [[deprecated]] attribute is supported (this symbol only exists in wxWidgets 3.1.6 or later).
wxHAS_DPI_INDEPENDENT_PIXELSDefined if pixel coordinates on the current platform scale with DPI, i.e. if the given length in pixels has the same apparent size on the display independently of the DPI (this symbol only exists in wxWidgets 3.1.6 or later). Note that it should rarely, if ever, be necessary to use this symbol directly, functions such as wxWindow::FromDIP() and wxBitmap::GetLogicalSize() exist to hide the differences between the platforms with and without DPI-independent pixels.
wxHAS_MEMBER_DEFAULTDefined if the currently used compiler supports C++11 =default.
wxHAS_LARGE_FILESDefined if wxFile supports files more than 4GB in size (notice that you must include wx/filefn.h before testing for this symbol).
wxHAS_LARGE_FFILESDefined if wxFFile supports files more than 4GB in size (notice that you must include wx/filefn.h before testing for this symbol).
wxHAS_LONG_LONG_T_DIFFERENT_FROM_LONGDefined if compiler supports a 64 bit integer type (available as wxLongLong_t) and this type is different from long. Notice that, provided wxUSE_LONGLONG is not turned off, some 64 bit type is always available to wxWidgets programs and this symbol only indicates a presence of such primitive type. It is useful to decide whether some function should be overloaded for both long and long long types.
wxHAS_MULTIPLE_FILEDLG_FILTERSDefined if wxFileDialog supports multiple ('|'-separated) filters.
wxHAS_NATIVE_ANIMATIONCTRLDefined if native wxAnimationCtrl class is being used (this symbol only exists in wxWidgets 3.1.4 and later).
wxHAS_NATIVE_DATAVIEWCTRLDefined if native wxDataViewCtrl class is being used (this symbol only exists in wxWidgets 3.1.4 and later).
wxHAS_NATIVE_WINDOWDefined if wxNativeWindow class is available.
wxHAS_NOEXCEPTDefined if the currently used compiler supports C++11 noexcept. wxNOEXCEPT is defined as this keyword in this case, and as nothing otherwise.
wxHAS_NULLPTR_TDefined if the currently used compiler supports C++11 nullptr.
wxHAS_IMAGE_RESOURCESDefined if images can be embedded into the program as resources, i.e. without being defined in the program text itself. This is currently the case for MSW and Mac platforms. This constant is available since wxWidgets 3.1.6.
wxHAS_IMAGES_IN_RESOURCESDefined if Windows resource files resource files are available on the current platform. Usually wxHAS_IMAGE_RESOURCES should be used instead.
wxHAS_POWER_EVENTSDefined if wxPowerEvent are ever generated on the current platform.
wxHAS_RADIO_MENU_ITEMSDefined if the current port supports radio menu items (see wxMenu::AppendRadioItem).
wxHAS_RAW_BITMAPDefined if direct access to bitmap data using the classes in wx/rawbmp.h is supported.
wxHAS_RAW_KEY_CODESDefined if raw key codes (see wxKeyEvent::GetRawKeyCode are supported.
wxHAS_REGEX_ADVANCEDDefined if advanced syntax is available in wxRegEx. This is always the case in wxWidgets 3.1.6 and later, so this symbol doesn't need to be tested any more.
wxHAS_SVGDefined if SVG support (currently only via wxBitmapBundle::FromSVG()) is available.
wxHAS_TASK_BAR_ICONDefined if wxTaskBarIcon is available on the current platform.
wxHAS_WINDOW_LABEL_IN_STATIC_BOXDefined if wxStaticBox::Create() overload taking wxWindow* instead of the text label is available on the current platform.
wxHAS_MODE_TDefined when wxWidgets defines mode_t typedef for the compilers not providing it. If another library used in a wxWidgets application, such as ACE (http://www.cs.wustl.edu/~schmidt/ACE.html), also defines mode_t, this symbol can be predefined after including the other library header, such as "ace/os_include/sys/os_types.h" in ACE case, but before including any wxWidgets headers, to prevent a definition conflict.

MSVC-specific Symbols

Microsoft Visual C++ users may use the special wx/setup.h file for this compiler in include/msvc subdirectory. This file implicitly links in all the wxWidgets libraries using MSVC-specific pragmas which usually is much more convenient than manually specifying the libraries list in all of the project configurations.

By default, the pragmas used in this file to actually link with wxWidgets libraries suppose that the libraries are located in vc_lib or vc_dll directory which is used by default. However when using multiple MSVC versions, or when using the official binaries, the libraries are in a directory containing the compiler version number, e.g. vc140_dll. To make linking work in this case, you must predefine wxMSVC_VERSION as vc140 before include wx/setup.h file, i.e. typically in the MSVS project options. Alternatively, you can predefine wxMSVC_VERSION_AUTO symbol (without any value), which means that the appropriate compiler version should be used automatically, e.g. "vc100" for VC 10 (MSVS 2010), "vc140" for VC 14 (MSVS 2015) etc. Additionally, VC 14 is a special case as it has 3 minor versions: VC 14.0, 14.1 and 14.2, corresponding to MSVS 2015, 2017 and 2019; that are ABI-compatible with each other. Due to this, it can also be useful to reuse the single build of wxWidgets with all versions of the compiler and this is supported if wxMSVC_VERSION_ABI_COMPAT is defined: the compiler prefix "vc14x" is used in this case.

If the makefiles have been used to build the libraries from source and the CFG variable has been set to specify a different output path for that particular configuration of build then the wxCFG preprocessor symbol should be set in the project that uses wxWidgets to the same value as the CFG variable in order for the correct wx/setup.h file to automatically be included for that configuration.

Library Selection for MSVC

As explained above, MSVC users don't need to explicitly specify wxWidgets libraries to link with, as this is done by wx/setup.h. However sometimes linking with all the libraries, as is done by default, is not desirable, for example because some of them were not built and this is where the symbols in this section can be helpful: defining them allows to not link with the corresponding library. The following symbols are honoured:

- wxNO_AUI_LIB
- wxNO_HTML_LIB
- wxNO_MEDIA_LIB
- wxNO_NET_LIB
- wxNO_PROPGRID_LIB
- wxNO_QA_LIB
- wxNO_RICHTEXT_LIB
- wxNO_WEBVIEW_LIB
- wxNO_XML_LIB
- wxNO_REGEX_LIB
- wxNO_EXPAT_LIB
- wxNO_JPEG_LIB
- wxNO_PNG_LIB
- wxNO_TIFF_LIB
- wxNO_ZLIB_LIB

Notice that the base library is always included and the core is always included for the GUI applications (i.e. those which don't define wxUSE_GUI as 0).

Compatibility Macros

wxWidgets always tries to preserve source backwards compatibility, however sometimes existing symbols may need to be removed. Except in exceedingly rare cases, this happens in several steps: first, the symbol is marked as deprecated, so that using it results in a warning when using the common compilers (e.g. any non-ancient version of MSVC, gcc or clang) in some wxWidgets release x.y. It can still be used, however the warnings indicate all the places in your code which will need to be updated in the future. If your code doesn't use any deprecated symbols or you have already fixed all their occurrences, you may change WXWIN_COMPATIBILITY_x_y to 0 to ensure they can't be used – however its default value is still 1 at this time.

At some point in the future, the next stable wxWidgets release x.y+2 changes the default WXWIN_COMPATIBILITY_x_y value to 0, meaning that now the symbol becomes unavailable by default and if you still want to be able to compile the code using it, you need to explicitly change WXWIN_COMPATIBILITY_x_y to 1 when building the library.

And, finally, the symbol is completely removed from the library in the next stable version after this, i.e. x.y+4. WXWIN_COMPATIBILITY_x_y itself is removed as well at this time, as it is not useful any longer.

According to this general rule, currently, i.e. in wxWidgets 3.2, the following two symbols are defined: WXWIN_COMPATIBILITY_2_8, as 0, and WXWIN_COMPATIBILITY_3_0, as 1. Please see Backwards Compatibility for even more details.

WXWIN_COMPATIBILITY_2_8defined as 0 by default meaning that symbols existing in wxWidgets 2.8 but deprecated in 3.0 release are not available by default. It can be changed to 1 to make them available, but it is strongly recommended to update the code using them instead.
WXWIN_COMPATIBILITY_3_0defined as 1 by default meaning that symbols existing in wxWidgets 3.0 but deprecated since then are still available. It can be changed to 1 to ensure that no deprecated symbols are used accidentally.
wxDIALOG_UNIT_COMPATIBILITYwxMSW-specific setting which can be set to 1 to make wxWindow::GetCharWidth() and wxWindow::GetCharHeight() more compatible with old wxWidgets versions. Changing it is not recommended.
wxUSE_UNSAFE_WXSTRING_CONVthis option determines if unsafe implicit conversions of wxString to char* or std::string (depending on whether wxUSE_STL is 0 or 1) are defined. It is set to 1 by default for compatibility reasons, however it is recommended to set it to 0 for the new projects. See also wxNO_UNSAFE_WXSTRING_CONV below for an alternative way of disabling these unsafe conversions not requiring rebuilding the library.

Miscellaneous

__WXWINDOWS__always defined in wxWidgets applications, see also wxCHECK_VERSION
wxDEBUG_LEVELdefined as 1 by default, may be pre-defined as 0 before including wxWidgets headers to disable generation of any code at all for the assertion macros, see Debugging
__WXDEBUG__defined if wxDEBUG_LEVEL is 1 or more, undefined otherwise
wxUSE_XXXif defined as 1, feature XXX is active, see the wxUSE Preprocessor Symbols (the symbols of this form are always defined, use #if and not #ifdef to test for them)
WX_PRECOMPis defined if precompiled headers (PCH) are in use. In this case, wx/wxprec.h includes wx/wx.h which, in turn, includes a number of wxWidgets headers thus making it unnecessary to include them explicitly. However if this is not defined, you do need to include them and so the usual idiom which allows to support both cases is to first include wx/wxprec.h

then, inside #ifndef WX_PRECOMP, individual headers you need.}

_UNICODE and UNICODE

both are defined if wxUSE_UNICODE is set to 1

wxUSE_GUI

this particular feature test macro is defined to 1 when compiling or using the library with the GUI features activated, if it is defined as 0, only wxBase is available.

wxUSE_BASE

only used by wxWidgets internally (defined as 1 when building wxBase code, either as a standalone library or as part of the monolithic wxWidgets library, defined as 0 when building GUI library only)

wxNO_RTTI

is defined if the compiler RTTI support has been switched off

wxNO_EXCEPTIONS

is defined if the compiler support for C++ exceptions has been switched off

wxNO_THREADS

if this macro is defined, the compilation options don't include compiler flags needed for multithreaded code generation. This implies that wxUSE_THREADS is 0 and also that other (non-wx-based) threading packages cannot be used either.

wxNO_UNSAFE_WXSTRING_CONV

this symbol is not defined by wxWidgets itself, but can be defined by the applications using the library to disable unsafe implicit conversions in wxString class. This is especially useful when using standard build of the library, e.g. installed by the system package manager under Unix, which is compiled with wxUSE_UNSAFE_WXSTRING_CONV set to 1 for compatibility reasons as -DwxNO_UNSAFE_WXSTRING_CONV can be used only compiling the application code, without rebuilding the library. Support for this option appeared in wxWidgets 3.1.1.

wxNO_IMPLICIT_WXSTRING_ENCODING

this symbol is not defined by wxWidgets itself, but can be defined by the applications using the library to disable implicit conversions from and to const char* in wxString class. Support for this option appeared in wxWidgets 3.1.4.

wxNO_INITIALIZER_LIST

this symbol is not defined by wxWidgets itself, but can be defined by the applications using the library to disable the definition of overloads accepting std::initializer_list if they create overload ambiguities in the existing code. It is still recommended to fix such problems, by explicitly selecting the wanted conversion, as this symbol is only honoured by wxWidgets 3.2 (since 3.2.5) but not by the future versions of the library.

wxNO_UNUSED_VARIABLES

this symbol is not defined by wxWidgets itself, but can be defined by the applications using the library to opt-in enabling the wxWARN_UNUSED attribute, and use it for selected wxWidgets classes to allow warnings for unused instances. This symbol only has effect in wxWidgets 3.2 (since 3.2.7); it is no longer needed with 3.3.0 and later.

WXMAKINGDLL_XXX

used internally and defined when building the library XXX as a DLL; when a monolithic wxWidgets build is used only a single WXMAKINGDLL symbol is defined

WXUSINGDLL

defined when compiling code which uses wxWidgets as a DLL/shared library

WXBUILDING

defined when building wxWidgets itself, whether as a static or shared library

wxICON_IS_BITMAP

defined in the ports where wxIcon inherits from wxBitmap (all but wxMSW currently)