Version: 3.1.0
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
__WXWINCE__ Windows CE
__WXGTK__ GTK+
__WXGTK12__ GTK+ 1.2 or higher
__WXGTK20__ GTK+ 2.0 or higher
__WXGTK24__ GTK+ 2.4 or higher
__WXGTK26__ GTK+ 2.6 or higher
__WXGTK210__ GTK+ 2.10 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 (Carbon, AppKit or UIKit)
__WXOSX_IPHONE__ OS X iPhone (UIKit)
__WXOSX_CARBON__ Mac OS X using Carbon
__WXOSX_COCOA__ Mac OS X using Cocoa (AppKit)
__WXOSX_MAC__ Mac OS X (Carbon or Cocoa)
__WXPM__ OS/2 native Presentation Manager (not used any longer).
__WXSTUBS__ Stubbed version ('template' wxWin implementation)
__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+

There are two wxWidgets ports to Mac OS X. One of them, wxOSX is the successor of the venerable wxMac, it currently exists in three versions: Carbon and Cocoa for the desktop and a very early iPhone port. And there is the Cocoa port named wxCocoa which has not been updated very actively since beginning 2008. 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 a particular GUI Mac port under OS X, use __WXOSX_CARBON__ or __WXOSX_COCOA__.
  • If you want to test for any port under Mac OS X, 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__ Mac 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 (Mac 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
_WIN32_WCE Windows CE version

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

Hardware Type

__SMARTPHONE__ Generic mobile devices with phone buttons and a small display
__PDA__ Personal digital assistant, usually with touch screen
__HANDHELD__ Small but powerful computer, usually with a keyboard
__POCKETPC__ Microsoft-powered PocketPC devices with touch-screen
__WINCE_STANDARDSDK__ Microsoft-powered Windows CE devices, for generic Windows CE applications
__WINCE_NET__ Microsoft-powered Windows CE .NET devices (_WIN32_WCE is 400 or greater)
WIN32_PLATFORM_WFSP Microsoft-powered smartphone

Compilers

__BORLANDC__ Borland C++. The value of the macro corresponds to the compiler version: 500 is 5.0.
__DJGPP__ DJGPP
__DIGITALMARS__ Digital Mars (not used any more).
__EVC4__ Embedded Visual C++ 4 (can be only used for building wxWinCE)
__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_TOOLCHAIN MinGW32 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_CHECKBOX Defined 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_OPS Defined 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_BITMAPTOGGLEBUTTON Defined in wx/tglbtn.h if wxBitmapToggleButton class is available in addition to wxToggleButton.
wxHAS_CONFIG_TEMPLATE_RW Defined if the currently used compiler supports template Read() and Write() methods in wxConfig.
wxHAS_LARGE_FILES Defined if wxFile supports files more than 4GB in size (notice that you must include wx/filefn.h before testing for this symbol).
wxHAS_LARGE_FFILES Defined 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_LONG Defined 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_FILTERS Defined if wxFileDialog supports multiple ('|'-separated) filters.
wxHAS_IMAGES_IN_RESOURCES Defined if Windows resource files or OS/2 resource files are available on the current platform.
wxHAS_POWER_EVENTS Defined if wxPowerEvent are ever generated on the current platform.
wxHAS_RADIO_MENU_ITEMS Defined if the current port supports radio menu items (see wxMenu::AppendRadioItem).
wxHAS_RAW_BITMAP Defined if direct access to bitmap data using the classes in wx/rawbmp.h is supported.
wxHAS_RAW_KEY_CODES Defined if raw key codes (see wxKeyEvent::GetRawKeyCode are supported.
wxHAS_REGEX_ADVANCED Defined if advanced syntax is available in wxRegEx.
wxHAS_TASK_BAR_ICON Defined if wxTaskBarIcon is available on the current platform.

Library Selection for MSVC

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. However sometimes linking with all the libraries 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_ADV_LIB
- 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).

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.

Miscellaneous

__WXWINDOWS__ always defined in wxWidgets applications, see also wxCHECK_VERSION
wxDEBUG_LEVEL defined 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_XXX if 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_PRECOMP is 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 and 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 neither.
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