Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'master' into web-request

Browse Source 
Merge with the latest master in preparation for merging into master.

Rebake to resolve conflicts in generated files.
This commit is contained in:
Vadim Zeitlin
2020-12-12 17:44:45 +01:00
parent 68cbd54db0 86a3578a11
commit 6bdab7b3c8
3934 changed files with 147571 additions and 96246 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
docs/doxygen/Doxyfile
View File

@@ -6,7 +6,7 @@
DOXYFILE_ENCODING = UTF-8
PROJECT_NAME = wxWidgets
PROJECT_NUMBER = 3.1.3
PROJECT_NUMBER = 3.1.5
PROJECT_BRIEF =
PROJECT_LOGO = logo.png
OUTPUT_DIRECTORY = out
@@ -214,7 +214,7 @@ ALIASES += rightCurly="}"
# For indicating a sample location
ALIASES += sampledir{1}="@e Location: @c samples/\1 subdirectory of your wxWidgets installation or https://github.com/wxWidgets/wxWidgets/tree/master/samples/\1"
# For refering to the corresponding sample in a class document or a overview
# For referring to the corresponding sample in a class document or a overview
# Usually placed in the queue of @see
ALIASES += sample{1}="\ref page_samples_\1"
@@ -384,6 +384,7 @@ GENERATE_CHI = NO
CHM_INDEX_ENCODING =
BINARY_TOC = NO
TOC_EXPAND = NO
TOC_INCLUDE_HEADINGS = 3
#---------------------------------------------------------------------------
@@ -534,7 +535,7 @@ SKIP_FUNCTION_MACROS = YES
#---------------------------------------------------------------------------
TAGFILES =
GENERATE_TAGFILE =
GENERATE_TAGFILE = $(GENERATE_TAGFILE)
ALLEXTERNALS = NO
EXTERNAL_GROUPS = YES
EXTERNAL_PAGES = YES

2
docs/doxygen/groups/class_help.h
View File

@@ -10,7 +10,7 @@
@defgroup group_class_help Help
@ingroup group_class
Classes for loading and displaying help manuals or help informations in general.
Classes for loading and displaying help manuals or help information in general.
*/

2
docs/doxygen/groups/class_webview.h
View File

@@ -10,7 +10,7 @@
@defgroup group_class_webview WebView
@ingroup group_class
The wxWebView library is a set of classes for viewing complex web documents and
The wxWebView library is a set of classes for viewing complex web documents and
for internet browsing. It is built around a series of backends, and exposes
common functions for them.

2
docs/doxygen/groups/funcmacro_atomic.h
View File

@@ -14,7 +14,7 @@ When using multi-threaded applications, it is often required to access or
modify memory which is shared between threads. Atomic integer and pointer
operations are an efficient way to handle this issue (another, less efficient,
way is to use a wxMutex or wxCriticalSection). A native implementation exists
for Windows, Linux, Solaris and OS X; for others, a wxCriticalSection is
for Windows, Linux, Solaris and macOS; for others, a wxCriticalSection is
used to protect the data.
One particular application is reference counting (used by so-called

2
docs/doxygen/groups/funcmacro_locale.h
View File

@@ -19,7 +19,7 @@ and keep in mind that the wxWidgets function takes as last parameter the
locale which should be internally used for locale-dependent operations.
Last, note that when the @c wxHAS_XLOCALE_SUPPORT symbol is not defined,
then wxWidgets will provide implementations of these functions itself
then wxWidgets will provide implementations of these functions itself
and that they are not granted to be thread-safe (and they will work only with the
C locale; see @ref xlocale_avail).

BIN
docs/doxygen/images/appear-propertygrid-msw.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 1.2 KiB

After

Width:  |  Height:  |  Size: 4.4 KiB

BIN
docs/doxygen/images/overview_highdpi_text_144.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 21 KiB

BIN
docs/doxygen/images/overview_highdpi_text_72.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 17 KiB

4
docs/doxygen/mainpages/cat_classes.h
View File

@@ -126,7 +126,7 @@ Controls that are not static can have wxValidator associated with them.
mode
@li wxNotebook: A notebook class
@li wxOwnerDrawnComboBox: A combobox with owner-drawn list items
@li wxPropertyGrid: A complex control to display hierachical, editable information
@li wxPropertyGrid: A complex control to display hierarchical, editable information
@li wxRadioBox: A group of radio buttons
@li wxRadioButton: A round button to be used with others in a mutually
exclusive way
@@ -667,6 +667,7 @@ Related overview: @ref overview_file
@li wxFile: Low-level file input/output class.
@li wxFFile: Another low-level file input/output class.
@li wxTempFile: Class to safely replace an existing file
@li wxTempFFile: Another class to safely replace an existing file
@li wxTextFile: Class for working with text files as with arrays of lines
@li wxStandardPaths: Paths for standard directories
@li wxPathList: A class to help search multiple paths
@@ -702,6 +703,7 @@ Related overview: @ref overview_stream
@li wxFFileInputStream: Another file input stream class
@li wxFFileOutputStream: Another file output stream class
@li wxTempFileOutputStream: Stream to safely replace an existing file
@li wxTempFFileOutputStream: Another stream to safely replace an existing file
@li wxStringInputStream: String input stream class
@li wxStringOutputStream: String output stream class
@li wxLZMAInputStream: LZMA decompression stream class

69
docs/doxygen/mainpages/const_cpp.h
View File

@@ -39,9 +39,9 @@ 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 <tt>__WINDOWS__</tt> should be used for the platform tests.}
@itemdef{__WXOSX__, OS X GUI using any Apple widget framework (AppKit or UIKit)}
@itemdef{__WXOSX_IPHONE__, OS X iPhone (UIKit)}
@itemdef{__WXOSX_COCOA__, OS X using Cocoa (AppKit)}
@itemdef{__WXOSX_MAC__, OS X (Cocoa)}
@itemdef{__WXOSX_IPHONE__, iPhone (UIKit)}
@itemdef{__WXOSX_COCOA__, macOS using Cocoa (AppKit)}
@itemdef{__WXOSX_MAC__, macOS (Cocoa)}
@itemdef{__WXPM__, OS/2 native Presentation Manager (not used any longer).}
@itemdef{__WXSTUBS__, Stubbed version ('template' wxWin implementation)}
@itemdef{__WXXT__, Xt; mutually exclusive with WX_MOTIF, not implemented in wxWidgets 2.x}
@@ -59,7 +59,7 @@ versions: Cocoa for the desktop and a very early iPhone port. To summarize:
<tt>__WXOSX_MAC__</tt>.
@li If you want to test for wxOSX on the iPhone, use
<tt>__WXOSX_IPHONE__</tt>.
@li If you want to test for any port under OS X, including, for
@li If you want to test for any port under macOS, including, for
example, wxGTK and also wxBase, use <tt>__DARWIN__</tt> (see below).
The convention is to use the <tt>__WX</tt> prefix for these
@@ -120,7 +120,7 @@ compiler used.
@beginDefList
@itemdef{__BORLANDC__, Borland C++. The value of the macro corresponds
to the compiler version: 500 is 5.0.}
to the compiler version: 500 is 5.0 (not used any more).}
@itemdef{__DIGITALMARS__, Digital Mars (not used any more).}
@itemdef{__GNUG__, Gnu C++ on any platform, see also wxCHECK_GCC_VERSION}
@itemdef{__GNUWIN32__, Gnu-Win32 compiler, see also wxCHECK_W32API_VERSION}
@@ -171,6 +171,8 @@ Currently the following symbols exist:
wxBitmapToggleButton class is available in addition to wxToggleButton.}
@itemdef{wxHAS_CONFIG_TEMPLATE_RW, Defined if the currently used compiler
supports template Read() and Write() methods in wxConfig.}
@itemdef{wxHAS_MEMBER_DEFAULT, Defined if the currently used compiler supports
C++11 @c =default.}
@itemdef{wxHAS_LARGE_FILES, Defined if wxFile supports files more than 4GB in
size (notice that you must include @c wx/filefn.h before testing for this
symbol).}
@@ -185,7 +187,11 @@ Currently the following symbols exist:
decide whether some function should be overloaded for both
<code>long</code> and <code>long long</code> types.}
@itemdef{wxHAS_MULTIPLE_FILEDLG_FILTERS, Defined if wxFileDialog supports multiple ('|'-separated) filters.}
@itemdef{wxHAS_NATIVE_ANIMATIONCTRL, Defined if native wxAnimationCtrl class is being used (this symbol only exists in wxWidgets 3.1.4 and later).}
@itemdef{wxHAS_NATIVE_DATAVIEWCTRL, Defined if native wxDataViewCtrl class is being used (this symbol only exists in wxWidgets 3.1.4 and later).}
@itemdef{wxHAS_NATIVE_WINDOW, Defined if wxNativeWindow class is available.}
@itemdef{wxHAS_NOEXCEPT, Defined if the currently used compiler supports C++11 @c noexcept. @c wxNOEXCEPT is defined as this keyword in this case, and as nothing otherwise.}
@itemdef{wxHAS_NULLPTR_T, Defined if the currently used compiler supports C++11 @c nullptr.}
@itemdef{wxHAS_IMAGES_IN_RESOURCES, Defined if <a href="http://en.wikipedia.org/wiki/Resource_(Windows)">
Windows resource files</a> or OS/2 resource files are available on the current platform.}
@itemdef{wxHAS_POWER_EVENTS, Defined if wxPowerEvent are ever generated on the current platform.}
@@ -208,16 +214,47 @@ Currently the following symbols exist:
@section page_cppconst_msvc_setup_h Library Selection for MSVC
@section page_cppconst_msvc_setup_h MSVC-specific Symbols
Microsoft Visual C++ users may use the special @c wx/setup.h file for this
compiler in @c 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:
configurations.
By default, the pragmas used in this file to actually link with wxWidgets
libraries suppose that the libraries are located in @c vc_lib or @c vc_dll
directory which is used by default. However when using multiple MSVC versions,
or when using the @ref plat_msw_binaries "official binaries", the libraries are
in a directory containing the compiler version number, e.g. @c vc140_dll. To
make linking work in this case, you must predefine @c wxMSVC_VERSION as @c
vc140 <em>before</em> include @c wx/setup.h file, i.e. typically in the MSVS
project options. Alternatively, you can predefine @c 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 @c 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 @c CFG
variable has been set to specify a different output path for that particular
configuration of build then the @c wxCFG preprocessor symbol should be set in
the project that uses wxWidgets to the same value as the @c CFG variable in
order for the correct @c wx/setup.h file to automatically be included for that
configuration.
@subsection page_cppconst_msvc_setup_h_no_libs 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 @c 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
@@ -238,13 +275,6 @@ with the corresponding library. The following symbols are honoured:
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 @c wxUSE_GUI as 0).
If the makefiles have been used to build the libraries from source and the @c CFG
variable has been set to specify a different output path for that particular
configuration of build then the @c wxCFG preprocessor symbol should be set in
the project that uses wxWidgets to the same value as the @c CFG variable in
order for the correct @c wx/setup.h file to automatically be included for that
configuration.
@section page_cppconst_compatibility Compatibility Macros
@@ -345,6 +375,11 @@ more details.
set to 1 for compatibility reasons as @c -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.}
@itemdef{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 <tt>const char*</tt> in wxString class.
Support for this option appeared in wxWidgets 3.1.4.}
@itemdef{WXMAKINGDLL_XXX,
used internally and defined when building the
library @c XXX as a DLL; when a monolithic wxWidgets build is used only a

2
docs/doxygen/mainpages/const_stdevtid.h
View File

@@ -29,7 +29,7 @@ identifiers are all in the range between @c wxID_LOWEST and
@c wxID_HIGHEST and, accordingly, the user code should avoid defining its
own constants in this range (e.g. by using wxNewId()).
Refer to @ref page_stockitems "the list of stock items" for the subset of standard IDs
Refer to @ref page_stockitems "the list of stock items" for the subset of standard IDs
which are stock IDs as well.
*/

19
docs/doxygen/mainpages/const_wxusedef.h
View File

@@ -35,11 +35,11 @@ library:
@itemdef{wxUSE_STD_IOSTREAM, Standard C++ classes are used instead of or in
addition to wx stream classes.}
@itemdef{wxUSE_UNICODE, Compiled with Unicode support (default in wxWidgets
3.0, non-Unicode build will be deprecated in the future).}
3.0, non-Unicode build is deprecated and will be removed in the future).}
@itemdef{wxUSE_UNICODE_WCHAR, wxString uses wchar_t buffer for internal storage
(default under MSW).}
@itemdef{wxUSE_UNICODE_UTF8, wxString uses UTF-8 for internal storage (default
under Unix and Mac systems).}
(default).}
@itemdef{wxUSE_UNICODE_UTF8, wxString uses UTF-8 for internal storage (mostly
useful for wxGTK where UTF-8 is used by the underlying toolkit).}
@itemdef{wxUSE_UTF8_LOCALE_ONLY, Library supports running only under UTF-8 (and
C) locale. This eliminates the code necessary for conversions from the
other locales and reduces the library size; useful for embedded systems.}
@@ -146,7 +146,6 @@ library:
@itemdef{wxUSE_IMAGE, Use wxImage and related classes.}
@itemdef{wxUSE_IMAGLIST, Use wxImageList class.}
@itemdef{wxUSE_INTL, Use wxLocale and related classes.}
@itemdef{wxUSE_IOSTREAMH, Use header "iostream.h" instead of "iostream".}
@itemdef{wxUSE_IPC, Use interprocess communication classes.}
@itemdef{wxUSE_IPV6, Use experimental wxIPV6address and related classes.}
@itemdef{wxUSE_JOYSTICK, Use wxJoystick class.}
@@ -170,12 +169,14 @@ library:
@itemdef{wxUSE_MDI_ARCHITECTURE, Use MDI-based document-view classes.}
@itemdef{wxUSE_MEDIACTRL, Use wxMediaCtrl.}
@itemdef{wxUSE_MEMORY_TRACING, Use wxWidgets memory leak detection, not recommended if using another memory debugging tool.}
@itemdef{wxUSE_MENUS, Use wxMenu and related classes.}
@itemdef{wxUSE_MENUS, Use wxMenu and wxMenuItem.}
@itemdef{wxUSE_MENUBAR, Use wxMenubar.}
@itemdef{wxUSE_METAFILE, Use wxMetaFile and related classes.}
@itemdef{wxUSE_MIMETYPE, Use wxFileType class.}
@itemdef{wxUSE_MINIFRAME, Use wxMiniFrame class.}
@itemdef{wxUSE_MOUSEWHEEL, Support mouse wheel events.}
@itemdef{wxUSE_MSGDLG, Use wxMessageDialog class and wxMessageBox function.}
@itemdef{wxUSE_NATIVE_DATAVIEWCTRL, Use native wxDataViewCtrl class (this option is new since wxWidgets 3.1.4).}
@itemdef{wxUSE_NATIVE_STATUSBAR, Use native wxStatusBar class.}
@itemdef{wxUSE_NOTEBOOK, Use wxNotebook and related classes.}
@itemdef{wxUSE_NUMBERDLG, Use wxNumberEntryDialog class.}
@@ -319,12 +320,13 @@ library:
@itemdef{wxUSE_ACCESSIBILITY, Enable accessibility support}
@itemdef{wxUSE_ACTIVEX, Use wxActiveXContainer and related classes.}
@itemdef{wxUSE_COMBOCTRL_POPUP_ANIMATION, See wx/msw/combo.h file.}
@itemdef{wxUSE_COMCTL32_SAFELY, See src/msw/treectrl.cpp file.}
@itemdef{wxUSE_COMMON_DIALOGS, Enable use of windows common dialogs from header commdlg.h; example PRINTDLG.}
@itemdef{wxUSE_CRASHREPORT, Use wxCrashReport class.}
@itemdef{wxUSE_DATEPICKCTRL_GENERIC, Use generic wxDatePickerCtrl implementation in addition to the native one.}
@itemdef{wxUSE_DC_CACHEING, cache temporary wxDC objects.}
@itemdef{wxUSE_DDE_FOR_IPC, See wx/ipc.h file.}
@itemdef{wxUSE_DPI_AWARE_MANIFEST, Set the DPI awareness of the application
(0=none, 1=system, 2=per-monitor. Used by CMake and when wxUSE_RC_MANIFEST is enabled.}
@itemdef{wxUSE_ENH_METAFILE, Use wxEnhMetaFile.}
@itemdef{wxUSE_HOTKEY, Use wxWindow::RegisterHotKey() and wxWindow::UnregisterHotKey}
@itemdef{wxUSE_INKEDIT, Use InkEdit library. Related to Tablet PCs.}
@@ -349,6 +351,9 @@ compilers. See also wxUSE_NO_MANIFEST.}
@itemdef{wxUSE_WIN_METAFILES_ALWAYS, Use wxMetaFile even when wxUSE_ENH_METAFILE=1.}
@itemdef{wxUSE_WINRT, Enable WinRT support.}
@itemdef{wxUSE_WXDIB, Use wxDIB class.}
@itemdef{wxUSE_WINSOCK2, Include @c <winsock2.h> instead of @c <winsock.h>.
Turned on automatically if wxUSE_IPV6 is on (this option is new since
wxWidgets 3.1.3).}
@endDefList

4
docs/doxygen/mainpages/copyright.h
View File

@@ -11,7 +11,7 @@
@section section_copyright wxWidgets Copyrights and Licenses
Copyright (c) 1992-2018 Julian Smart, Vadim Zeitlin, Stefan Csomor, Robert
Copyright (c) 1992-2020 Julian Smart, Vadim Zeitlin, Stefan Csomor, Robert
Roebling, and other members of the wxWidgets team, please see the
acknowledgements section below.
@@ -103,7 +103,7 @@ without express or implied warranty.
@verbinclude "lgpl.txt"
@page page_copyright_xserver The Open Group and DEC License
@verbinclude "xserver.txt"
*/

21
docs/doxygen/mainpages/devtips.h
View File

@@ -28,10 +28,6 @@ following section before any other includes:
// For compilers that support precompilation, includes "wx.h".
#include <wx/wxprec.h>
#ifdef __BORLANDC__
# pragma hdrstop
#endif
#ifndef WX_PRECOMP
// Include your minimal set of headers here, or wx.h
# include <wx/wx.h>
@@ -44,8 +40,8 @@ The file @c "wx/wxprec.h" includes @c "wx/wx.h". Although this incantation may
seem quirky, it is in fact the end result of a lot of experimentation, and
several Windows compilers to use precompilation which is largely automatic for
compilers with necessary support. Currently it is used for Visual C++
(including embedded Visual C++), Borland C++ and newer versions of GCC. Some
compilers might need extra work from the application developer to set the build
(including embedded Visual C++) and newer versions of GCC. Some compilers
might need extra work from the application developer to set the build
environment up as necessary for the support.
@@ -110,11 +106,10 @@ and this must not be changed.
On Microsoft Windows, wxWidgets has a different set of makefiles for each
compiler, because each compiler's @c 'make' tool is slightly different. Popular
Windows compilers that we cater for, and the corresponding makefile extensions,
include: Microsoft Visual C++ (.vc), Borland C++ (.bcc) and MinGW/Cygwin
(.gcc). Makefiles are provided for the wxWidgets library itself, samples,
demos, and utilities.
include: Microsoft Visual C++ (.vc) and MinGW/Cygwin (.gcc). Makefiles are
provided for the wxWidgets library itself, samples, demos, and utilities.
On Linux and OS X, you use the @c 'configure' command to generate the
On Linux and macOS, you use the @c 'configure' command to generate the
necessary makefiles. You should also use this method when building with
MinGW/Cygwin on Windows.
@@ -127,7 +122,7 @@ On Windows using a compiler other than MinGW/Cygwin, you would build the
wxWidgets library from the @c "build/msw" directory which contains the relevant
makefiles.
On Windows using MinGW/Cygwin, and on Unix and OS X, you invoke
On Windows using MinGW/Cygwin, and on Unix and macOS, you invoke
'configure' (found in the top-level of the wxWidgets source hierarchy), from
within a suitable empty directory for containing makefiles, object files and
libraries.
@@ -136,7 +131,7 @@ For details on using makefiles, configure, and project files, please see
@c "docs/xxx/install.txt" in your distribution, where @c "xxx" is the platform
of interest, such as @c msw, @c gtk, @c x11, @c mac.
All wxWidgets makefiles are generated using Bakefile <http://www.bakefile.org/>.
All wxWidgets makefiles are generated using Bakefile <https://www.bakefile.org/>.
wxWidgets also provides (in the @c "build/bakefiles/wxpresets" folder) the
wxWidgets bakefile presets. These files allow you to create bakefiles for your
own wxWidgets-based applications very easily.
@@ -259,7 +254,7 @@ its own run-time type information system, implemented using macros.
@subsection page_multiplatform_cpp_precompiledheaders Precompiled Headers
Some compilers, such as Borland C++ and Microsoft C++, support precompiled
Some compilers, such as Microsoft C++, support precompiled
headers. This can save a great deal of compiling time. The recommended approach
is to precompile @c "wx.h", using this precompiled header for compiling both
wxWidgets itself and any wxWidgets applications. For Windows compilers, two

24
docs/doxygen/mainpages/introduction.h
View File

@@ -41,8 +41,9 @@ Compared to the other similar libraries, wxWidgets is:
3. Open source and free for use in both open source and commercial projects.
wxWidgets provides a simple, easy to learn, yet very rich API. It is also
mature and stable, and the applications written using wxWidgets 2.0
wxWidgets provides a simple, easy to learn, yet very rich API, while also
proposing a simple way to define application UI in the external XML files.
It is also mature and stable, and the applications written using wxWidgets 2.0
pre-releases almost 20 years ago can still be built today with wxWidgets 3
almost unchanged. wxWidgets has a large, active and friendly community of
people, including both the users and developers of the library. It is also
@@ -59,7 +60,7 @@ paragraphs, but here are some of the benefits:
@li Extensive documentation (almost 200,000 lines of it).
@li Straightforward API.
@li Simple but powerful layout system.
@li Run-time loadable or compile-time embeddable resources.
@li Run-time loadable or compile-time embeddable resources for UI definition.
@li Flexible event system.
@li All the usual and quite a few of more rare GUI controls.
@li And also all the standard dialogs.
@@ -79,7 +80,7 @@ wxWidgets first-tier "ports", ie implementations of wxWidgets API, are:
@li wxMSW: This is the native port for Microsoft Windows systems (from Windows
XP up to Windows 10), either 32 or 64 bits. The primarily supported compilers
are Microsoft Visual C++ (versions 2003 up to 2017 are supported, at least 2005
are Microsoft Visual C++ (versions 2003 up to 2019 are supported, at least 2005
is recommended) and GNU g++ (either from the traditional MinGW, TDM-GCC or
MinGW-w64 distributions).
@@ -90,12 +91,12 @@ NetBSD, Solaris, AIX, ...) and require GTK+ 2.6 or later or GTK+ 3.x. The
primary supported compiler is GNU g++.
@li wxOSX/Cocoa: This is the native port for Apple computers. wxOSX/Cocoa
supports 32 or 64 bit Intel Macs running OS X 10.7 or later. The port can be
supports 32 or 64 bit Intel Macs running macOS 10.10 or later. The port can be
built either with g++ or clang.
Other platforms (e.g. iOS - with a minimum requirement of iOS 9), compilers (Borland C++
under Windows, Sun CC, HP-UX aCC, IBM xlC or SGI mipsPro under Unix) and ports (
wxQT, wxGTK1, wxX11, wxDFB...) are also supported but to a lesser extent.
Other platforms (e.g. iOS - with a minimum requirement of iOS 13), compilers
(Sun CC, HP-UX aCC, IBM xlC or SGI mipsPro under Unix) and ports (wxQT, wxGTK1,
wxX11, wxDFB...) are also supported but to a lesser extent.
Please see the @subpage page_port "platform details page" for more information.
There are no CPU speed requirements but the faster (and more) CPU(s) you have,
@@ -110,13 +111,12 @@ configurations but at least 1GB and possibly more is required.
@section page_introduction_where Where to get wxWidgets and support for it
The download links can be found at https://www.wxwidgets.org. The primary
download location is https://github.com/wxWidgets/wxWidgets/releases/latest.
The download links can be found at https://www.wxwidgets.org/downloads/.
Additionally, the latest version can always be retrieved from our version
control system using Git (https://github.com/wxWidgets/wxWidgets).
wxWidgets documentation that you are reading is also available online at
https://docs.wxwidgets.org/trunk/ and please also visit our wiki at
The latest version of wxWidgets documentation that you are reading is available
online at https://docs.wxwidgets.org/trunk/ and please also see
https://wiki.wxwidgets.org/ for user-contributed contents.
And if you have any questions, you can join wxWidgets community using

2
docs/doxygen/mainpages/manual.h
View File

@@ -14,7 +14,7 @@
@author Julian Smart, Vadim Zeitlin, Robin Dunn, Stefan Csomor,
Bryan Petty, Francesco Montorsi, Robert Roebling et al
@date December 10, 2018
@date July 22, 2020
Welcome to wxWidgets, a stable and powerful open source framework for
developing native cross-platform GUI applications in C++!

104
docs/doxygen/mainpages/platdetails.h
View File

@@ -23,45 +23,36 @@ platforms and ports.
@section page_port_wxgtk wxGTK
wxGTK is a port of wxWidgets using the GTK+ library. It makes use of GTK+'s
wxGTK is a port of wxWidgets using the GTK library. It makes use of GTK's
native widgets wherever possible and uses wxWidgets' generic controls when
needed. GTK+ itself has been ported to a number of systems, but so far only the
original X11 version is supported. Support for other GTK+ backends is planned,
such as the new DirectFB backend.
needed.
All work is being done on GTK+ version 2.0 and above. Support for GTK+ 1.2 will
be deprecated in a later release.
You will need GTK 2.6 or higher which is available from:
You will need GTK+ 2.6 or higher which is available from:
https://www.gtk.org
http://www.gtk.org
The newer version of GTK+ you use, the more native widgets and features will be
The newer version of GTK you use, the more native widgets and features will be
utilized. We have gone to great lengths to allow compiling wxWidgets
applications with the latest version of GTK+, with the resulting binary working
on systems even with a much earlier version of GTK+. You will have to ensure
applications with the latest version of GTK, with the resulting binary working
on systems even with a much earlier version of GTK. You will have to ensure
that the application is launched with lazy symbol binding for that.
In order to configure wxWidgets to compile wxGTK you will need use the
In order to configure wxWidgets to compile wxGTK you will need to use the
@c \--with-gtk argument to the @c configure script. This is the default for many
systems.
GTK+ 1.2 can still be used, albeit discouraged. For that you can pass
@c \--with-gtk=1 to the @c configure script.
Support for GTK+ 3 is available starting with wxWidgets 2.9.4, use @c configure
option @c \--with-gtk=3 to enable it.
GTK 3 is the default starting with wxWidgets 3.1.4.
Use @c configure option @c \--with-gtk=2 to use GTK 2.
@subpage plat_gtk_install "Build and Install Instructions"
@subpage plat_gtk_overview "wxWidgets on the GNOME Desktop"
@section page_port_wxosx wxOSX/Cocoa
wxOSX/Cocoa is the port of wxWidgets for the OS X platform. It requires
OS X 10.7 or later and fully supports 64 bit builds.
wxOSX/Cocoa is the port of wxWidgets for the macOS platform. It requires
a minimum SDK 10.11, Xcode 7.2.1 or greater (runs under 10.10.5 and higher),
and fully supports amd64 as well ARM builds and deploying under 10.10.
@subpage plat_osx_install "Build and Install Instructions"
@@ -82,16 +73,12 @@ In order to configure wxWidgets to compile wxX11 you will need to type:
@subpage plat_x11_install "Build Instructions"
There is also a page on the use of wxWidgets for embedded
applications on the wxWidgets web site.
@section page_port_wxmotif wxMotif
wxMotif is a port of wxWidgets for X11 systems using Motif libraries. Motif
libraries provide a clean and fast user interface at the expense of the beauty
and candy of newer interfaces like GTK.
wxMotif is a port of wxWidgets for X11 systems using Motif libraries.
It is no longer actively maintained and by now rather obsolete.
@subpage plat_motif_install "Build Instructions"
@@ -102,9 +89,9 @@ and candy of newer interfaces like GTK.
wxMSW is a port of wxWidgets for the Windows platforms (Windows XP and later
are supported). wxMSW provides native look and feel for each Windows version.
This port can be compiled with several compilers including Microsoft Studio
VC++ 2003 or later, Borland 5.5, MinGW32, Cygwin as well as cross-compilation
with a Linux-hosted MinGW32 tool chain.
This port can be compiled with several compilers including Microsoft
VC++ 2003 or later, MinGW, Cygwin as well as cross-compilation with a
Linux-hosted MinGW tool chain.
@subpage plat_msw_install "Build and Install Instructions"
@@ -127,45 +114,6 @@ avoid this, ensure that the icon which is meant to be used as the main
application icon has a name preceding "wxICON" in alphabetical order.
@subsection page_port_wxmsw_themedborders Themed Borders
Starting with wxWidgets 2.8.5, you can specify the @c wxBORDER_THEME style to
have wxWidgets use a themed border. Using the default XP theme, this is a thin
1-pixel blue border, with an extra 1-pixel border in the window client
background colour (usually white) to separate the client area's scrollbars from
the border.
If you don't specify a border style for a wxTextCtrl in rich edit mode,
wxWidgets now gives the control themed borders automatically, where previously
they would take the sunken border style. Other native controls such
as wxTextCtrl in non-rich edit mode, and wxComboBox already paint themed
borders where appropriate. To use themed borders on other windows, such as
wxPanel, pass the @c wxBORDER_THEME style, or (apart from wxPanel) pass no
border style.
In general, specifying @c wxBORDER_THEME will cause a border of some kind to be
used, chosen by the platform and control class. To leave the border decision
entirely to wxWidgets, pass @c wxBORDER_DEFAULT. This is not to be confused
with specifying @c wxBORDER_NONE, which says that there should definitely be
@e no border.
@subsubsection page_port_wxmsw_themedborders_details Internal Border Implementation
The way that wxMSW decides whether to apply a themed border is as follows. The
theming code calls wxWindow::GetBorder() to obtain a border. If no border style
has been passed to the window constructor, GetBorder() calls GetDefaultBorder()
for this window. If wxBORDER_THEME was passed to the window constructor,
GetBorder() calls GetDefaultBorderForControl().
The implementation of wxWindow::GetDefaultBorder() on wxMSW calls
wxWindow::CanApplyThemeBorder() which is a virtual function that tells
wxWidgets whether a control can have a theme applied explicitly (some native
controls already paint a theme in which case we should not apply it ourselves).
Note that wxPanel is an exception to this rule because in many cases we wish to
create a window with no border (for example, notebook pages). So wxPanel
overrides GetDefaultBorder() in order to call the generic
wxWindowBase::GetDefaultBorder(), returning wxBORDER_NONE.
@section page_port_wxQt wxQt
wxQt is a port of wxWidgets using Qt libraries. It requires Qt 5 or later.
@@ -189,13 +137,13 @@ used by wxWidgets to e.g. use toolkit-specific features.
In such case (or when you want to e.g. write a port-specific patch) it can be
necessary to use the underlying toolkit API directly:
- wxMSW port uses win32 API: see MSDN docs at http://msdn2.microsoft.com/en-us/library/ms649779.aspx
- wxGTK port uses GTK+ and other lower-level libraries; see
- GTK+ docs at http://library.gnome.org/devel/gtk/unstable/
- GDK docs at http://library.gnome.org/devel/gdk/unstable/
- GLib docs at http://library.gnome.org/devel/glib/unstable/
- GObject docs at http://library.gnome.org/devel/gobject/unstable/
- Pango docs at http://library.gnome.org/devel/pango/unstable/
- wxOSX port uses the Cocoa API: see Cocoa docs at http://developer.apple.com/cocoa
- wxMSW port uses Win32 API: see MSDN docs at https://docs.microsoft.com/en-us/windows/win32/controls/window-controls
- wxGTK port uses GTK and other lower-level libraries; see
- GTK docs at https://developer.gnome.org/gtk/
- GDK docs at https://library.gnome.org/devel/gdk/
- GLib docs at https://library.gnome.org/devel/glib/
- GObject docs at https://library.gnome.org/devel/gobject/
- Pango docs at https://library.gnome.org/devel/pango/
- wxOSX port uses the Cocoa API: see Cocoa docs at https://developer.apple.com/cocoa
*/

21
docs/doxygen/mainpages/samples.h
View File

@@ -307,23 +307,6 @@ wxProcess::Exists().
@sampledir{exec}
@section page_samples_flash Flash Sample
The flash sample demonstrates embedding of Adobe Flash into a wxWidgets
program. Currently it only works under Windows as it uses the Flash ActiveX
control to achieve this but we hope to be able to extend it to also work under
other platforms in the future. The sample also currently requires Microsoft
Visual C++ compiler as it uses COM support extensions specific to this
compiler.
The sample comes with 2 Flash files (SWF), showing a simple Flash animation
which can be controlled using the "Play", "Stop" and "Back"/"Forward" buttons
in the sample as well as a Flash form which shows how Flash and wxWidgets
program can exchange data: calling "GetText" function without arguments returns
the text of the text control defined inside Flash and calling "SetText" with an
argument sets the control contents to the given string. Finally clicking on the
button generates an event which is caught by the C++ program.
@section page_samples_font Font Sample
The font sample demonstrates wxFont,
@@ -669,7 +652,7 @@ first argument of @c save, @c load or @c delete, followed by the "service" and
"user" arguments as used by wxSecretStore methods. After storing some password,
you can check that it can be retrieved later and also that it can be seen in
the OS-provided password manager (e.g. credential manager under MSW or keychain
utility under OS X).
utility under macOS).
@sampledir{secretstore}
@@ -914,7 +897,7 @@ control.
The wxWebView sample demonstarates the various capabilities of the wxWebView
control. It is set up as a simple single window web browser, but with support
for many of the more complex wxWebView features, including browsing through
for many of the more complex wxWebView features, including browsing through
archives.
@sampledir{webview}

1
docs/doxygen/mainpages/topics.h
View File

@@ -99,5 +99,6 @@ topics related to building applications with wxWidgets.
@li @subpage overview_windowdeletion
@li @subpage overview_envvars
@li @subpage overview_customwidgets
@li @subpage overview_high_dpi
*/

5
docs/doxygen/mainpages/translations.h
View File

@@ -466,11 +466,6 @@ Here are the steps you should follow:
-# Send the finished translation to <a href="mailto:vadim@wxwidgets.org">Vadim Zeitlin</a>
and it will be added to the next wxWidgets release or snapshot.
In addition, please consider subscribing to the very low volume
<a href="https://www.wxwidgets.org/support/mailing-lists/">
wxWidgets translators mailing list</a> on which the news especially important
for the translators are announced.
Thank you in advance for your help!
*/

2
docs/doxygen/mainpages/utilities.h
View File

@@ -13,7 +13,7 @@
In addition to the wxWidgets libraries (see @ref page_libs), some utilities
are available to the users in the @c utils hierarchy (even if some of them are
explicitly conceived for wxWidgets maintainance and will probably be of
explicitly conceived for wxWidgets maintenance and will probably be of
little use to others).
Please note that these utilities only represent the utilities developed and

2
docs/doxygen/overviews/backwardcompatibility.h
View File

@@ -108,7 +108,7 @@ compatible but can also be binary compatible.
Binary compatibility makes it possible to get the maximum benefit from using
shared libraries, also known as dynamic link libraries (DLLs) on Windows or
dynamic shared libraries on OS X.
dynamic shared libraries on macOS.
For example, suppose several applications are installed on a system requiring
wxWidgets 2.6.0, 2.6.1 and 2.6.2. Since 2.6.2 is backward compatible with the

2
docs/doxygen/overviews/bitmap.h
View File

@@ -82,7 +82,7 @@ XPM nor BMP formats are appropriate as they don't have support for alpha and
another format, typically PNG, should be used. wxWidgets provides a similar
helper for PNG bitmaps called wxBITMAP_PNG() that can be used to either load
PNG files embedded in resources (meaning either Windows resource section of the
executable file or OS X "Resource" subdirectory of the application bundle) or
executable file or macOS "Resource" subdirectory of the application bundle) or
arrays containing PNG data included into the program code itself.
@see @ref group_class_gdi

12
docs/doxygen/overviews/bookctrl.h
View File

@@ -41,12 +41,12 @@ The mapping consists of:
@beginTable
@row2col{ ::wxBookCtrl, wxChoicebook or wxNotebook }
@row2col{ @c wxEVT_COMMAND_BOOKCTRL_PAGE_CHANGED,
@c wxEVT_COMMAND_CHOICEBOOK_PAGE_CHANGED or
@c wxEVT_COMMAND_NOTEBOOK_PAGE_CHANGED }
@row2col{ @c wxEVT_COMMAND_BOOKCTRL_PAGE_CHANGING,
@c wxEVT_COMMAND_CHOICEBOOK_PAGE_CHANGING or
@c wxEVT_COMMAND_NOTEBOOK_PAGE_CHANGING }
@row2col{ @c wxEVT_BOOKCTRL_PAGE_CHANGED,
@c wxEVT_CHOICEBOOK_PAGE_CHANGED or
@c wxEVT_NOTEBOOK_PAGE_CHANGED }
@row2col{ @c wxEVT_BOOKCTRL_PAGE_CHANGING,
@c wxEVT_CHOICEBOOK_PAGE_CHANGING or
@c wxEVT_NOTEBOOK_PAGE_CHANGING }
@row2col{ @c EVT_BOOKCTRL_PAGE_CHANGED(id\, fn),
@c EVT_CHOICEBOOK_PAGE_CHANGED(id, fn) or
@c EVT_NOTEBOOK_PAGE_CHANGED(id, fn) }

10
docs/doxygen/overviews/cmake.md
View File

@@ -5,7 +5,7 @@ CMake Overview {#overview_cmake}
CMake allows building wxWidgets on various platforms with your preferred build
system.
Most linux distributions contain CMake as a package on Windows and OS X you can
Most linux distributions contain CMake as a package on Windows and macOS you can
download an installer at the [CMake Page](https://cmake.org).
Using the CMake GUI {#cmake_gui}
@@ -26,11 +26,11 @@ Using the CMake Command Line {#cmake_cli}
2. Change into the created folder
3. Run `cmake -G "Unix Makefiles" path_to_wxWidgets_root`
4. After that you can run `cmake --build .` to start the build process or
directly use your choosen build system.
directly use your chosen build system.
Run `cmake --help` to see a list of available generators on your platform.
These can than be specified using the -G command line option. On Windows it
is recommended to use Visual Studio and on OS X Xcode is recommended.
is recommended to use Visual Studio and on macOS Xcode is recommended.
Various build options can be specified using -D see
[available options](#cmake_options).
@@ -64,7 +64,7 @@ or specified via the -D command line option when running the cmake command.
Option Name | Type | Default | Description
------------------------- | ----- | ------- | ----------------------------
wxBUILD_SHARED | BOOL | ON | Build shared libraries
wxBUILD_SHARED | BOOL | ON | Build shared or static libraries
wxBUILD_TESTS | STRING | OFF | CONSOLE_ONLY, ALL or OFF
wxBUILD_SAMPLES | STRING | OFF | SOME, ALL or OFF
wxBUILD_DEMOS | BOOL | OFF | Build demo applications
@@ -122,5 +122,5 @@ Your *CMakeLists.txt* would look like this:
...
add_subdirectory(libs/wxWidgets)
add_executable(myapp myapp.cpp)
target_link_libraries(myapp net core base)
target_link_libraries(myapp wx::net wx::core wx::base)
~~~

2
docs/doxygen/overviews/customwidgets.h
View File

@@ -12,7 +12,7 @@
@tableofcontents
Typically combining the existing @ref group_class_ctrl controls in wxDialogs
and wxFrames is sufficient to fullfill any GUI design. Using the wxWidgets
and wxFrames is sufficient to fulfill any GUI design. Using the wxWidgets
standard controls makes your GUI looks native on all ports and is obviously
easier and faster.

2
docs/doxygen/overviews/datetime.h
View File

@@ -106,7 +106,7 @@ just @c wxDateTime::Now() + wxDateSpan::Month()).
@section overview_datetime_arithmetics Date Arithmetics
@section overview_datetime_arithmetics Date Arithmetic
Many different operations may be performed with the dates, however not all of
them make sense. For example, multiplying a date by a number is an invalid

2
docs/doxygen/overviews/debugging.h
View File

@@ -21,7 +21,7 @@ debugging. Both assertions and debug logging are also used by wxWidgets itself
so you may encounter them even if you don't use either of these features
yourself.
@see wxLog, @ref group_funcmacro_log, @ref group_funcmacro_debug
@see wxLog, @ref group_funcmacro_log, @ref group_funcmacro_debug

2
docs/doxygen/overviews/docview.h
View File

@@ -86,7 +86,7 @@ use Wx ':docview'; # import constants (optional)
@endcode
@endWxPerlOnly
@see @ref group_class_docview,
@see @ref group_class_docview,

114
docs/doxygen/overviews/eventhandling.h
View File

@@ -98,10 +98,11 @@ First define one or more <em>event handlers</em>. They
are just simple methods of the class that take as a parameter a
reference to an object of a wxEvent-derived class and have no return value (any
return information is passed via the argument, which is why it is non-const).
You also need to insert a macro
You also need to insert a line with the macro indicating that the class uses an
event table, like this:
@code
wxDECLARE_EVENT_TABLE()
wxDECLARE_EVENT_TABLE();
@endcode
somewhere in the class declaration. It doesn't matter where it appears but
@@ -132,7 +133,7 @@ private:
// obligation to do that; this one is an event handler too:
void DoTest(wxCommandEvent& event);
wxDECLARE_EVENT_TABLE()
wxDECLARE_EVENT_TABLE();
};
@endcode
@@ -224,7 +225,7 @@ global scope as with the event tables), call its Bind<>() method like this:
@code
MyFrame::MyFrame(...)
{
Bind(wxEVT_COMMAND_MENU_SELECTED, &MyFrame::OnExit, this, wxID_EXIT);
Bind(wxEVT_MENU, &MyFrame::OnExit, this, wxID_EXIT);
}
@endcode
@@ -323,7 +324,7 @@ MyFrameHandler myFrameHandler;
MyFrame::MyFrame()
{
Bind( wxEVT_COMMAND_MENU_SELECTED, &MyFrameHandler::OnFrameExit,
Bind( wxEVT_MENU, &MyFrameHandler::OnFrameExit,
&myFrameHandler, wxID_EXIT );
}
@endcode
@@ -345,7 +346,7 @@ void HandleExit( wxCommandEvent & )
MyFrame::MyFrame()
{
Bind( wxEVT_COMMAND_MENU_SELECTED, &HandleExit, wxID_EXIT );
Bind( wxEVT_MENU, &HandleExit, wxID_EXIT );
}
@endcode
@@ -366,7 +367,7 @@ MyFunctor myFunctor;
MyFrame::MyFrame()
{
Bind( wxEVT_COMMAND_MENU_SELECTED, myFunctor, wxID_EXIT );
Bind( wxEVT_MENU, myFunctor, wxID_EXIT );
}
@endcode
@@ -376,7 +377,7 @@ separate functor class:
@code
MyFrame::MyFrame()
{
Bind(wxEVT_COMMAND_MENU_SELECTED,
Bind(wxEVT_MENU,
[](wxCommandEvent&) {
// Do something useful
},
@@ -406,7 +407,7 @@ MyFrame::MyFrame()
{
function< void ( wxCommandEvent & ) > exitHandler( bind( &MyHandler::OnExit, &myHandler, _1 ));
Bind( wxEVT_COMMAND_MENU_SELECTED, exitHandler, wxID_EXIT );
Bind( wxEVT_MENU, exitHandler, wxID_EXIT );
}
@endcode
@@ -427,7 +428,7 @@ MyFrame::MyFrame()
function< void ( wxCommandEvent & ) > exitHandler(
bind( &MyHandler::OnExit, &myHandler, EXIT_FAILURE, _1, "Bye" ));
Bind( wxEVT_COMMAND_MENU_SELECTED, exitHandler, wxID_EXIT );
Bind( wxEVT_MENU, exitHandler, wxID_EXIT );
}
@endcode
@@ -614,7 +615,7 @@ custom event types.
Finally, you will need to generate and post your custom events.
Generation is as simple as instancing your custom event class and initializing
its internal fields.
For posting events to a certain event handler there are two possibilities:
For posting events to a certain event handler there are two possibilities:
using wxEvtHandler::AddPendingEvent or using wxEvtHandler::QueueEvent.
Basically you will need to use the latter when doing inter-thread communication;
when you use only the main thread you can also safely use the former.
@@ -675,13 +676,15 @@ void MyWindow::SendEvent()
Under certain circumstances, you must define your own event class e.g., for
sending more complex data from one place to another. Apart from defining your
event class, you also need to define your own event table macro if you want to
use event tables for handling events of this type.
event class, you also need to define your own event table macro if you still
need to use event tables (now considered legacy) for handling events of this type.
See ChessBoardEvent in the event sample for a full working implementation
of a new wxEvent-derived class.
Here is an example:
Here is a simple example:
@code
// define a new event class
// create a new event class derived from wxEvent
class MyPlotEvent: public wxEvent
{
public:
@@ -701,40 +704,51 @@ private:
const wxPoint m_pos;
};
// we define a single MY_PLOT_CLICKED event type associated with the class
// above but typically you are going to have more than one event type, e.g. you
// could also have MY_PLOT_ZOOMED or MY_PLOT_PANNED &c -- in which case you
// would just add more similar lines here
wxDEFINE_EVENT(MY_PLOT_CLICKED, MyPlotEvent);
// We use a single myEVT_PLOT_CLICKED event type associated with the class
// above but often you are going to have more than one event type, e.g. you
// could also have myEVT_PLOT_ZOOMED or myEVT_PLOT_PANNED etc. -- in which case
// you would just add more similar lines here.
//
// Note that this macro, as all declarations, should be in the header, and
// there should be a matching definition macro in some source file (see
// wxDEFINE_EVENT below).
wxDECLARE_EVENT(myEVT_PLOT_CLICKED, MyPlotEvent);
// if you want to support old compilers you need to use some ugly macros:
// --- Skip this part if you're only going to use Bind() (as recommended) ---
// The following typedef and macro are needed only when the new event class
// still needs to be used with the legacy approach to handling events - event
// table macros or Connect() - to cast the type of a function handling it to
// the type expected by the legacy event handling machinery.
typedef void (wxEvtHandler::*MyPlotEventFunction)(MyPlotEvent&);
#define MyPlotEventHandler(func) wxEVENT_HANDLER_CAST(MyPlotEventFunction, func)
// if your code is only built using reasonably modern compilers, you could just
// do this instead:
#define MyPlotEventHandler(func) (&func)
// If the new event is to be used with event tables, a macro for creating
// event table entries for the new event type must be defined.
#define EVT_PLOT_CLICKED(id, func) \
wx__DECLARE_EVT1(myEVT_PLOT_CLICKED, id, MyPlotEventHandler(func))
// finally define a macro for creating the event table entries for the new
// event type
//
// remember that you don't need this at all if you only use Bind<>() and that
// you can replace MyPlotEventHandler(func) with just &func unless you use a
// really old compiler
#define MY_EVT_PLOT_CLICK(id, func) \
wx__DECLARE_EVT1(MY_PLOT_CLICKED, id, MyPlotEventHandler(func))
// --- End of the part which is only relevant when using event tables ---
// example of code handling the event (you will use one of these methods, not
// both, of course):
// Up until now, we only had declarations that would typically appear in a
// header file. Starting from now we have the definitions, which must occur
// only once in the program and so need to be in a source file.
// This defines the event type declared above. If you use multiple event types,
// you need to do it for each of them.
wxDEFINE_EVENT(myEVT_PLOT_CLICKED, MyPlotEvent);
// example of code handling the event (you will use one of these methods,
// not both, of course):
wxBEGIN_EVENT_TABLE(MyFrame, wxFrame)
EVT_PLOT(ID_MY_WINDOW, MyFrame::OnPlot)
EVT_PLOT_CLICKED(ID_MY_WINDOW, MyFrame::OnPlot)
wxEND_EVENT_TABLE()
MyFrame::MyFrame()
{
Bind(MY_PLOT_CLICKED, &MyFrame::OnPlot, this, ID_MY_WINDOW);
Bind(myEVT_PLOT_CLICKED, &MyFrame::OnPlot, this, ID_MY_WINDOW);
}
void MyFrame::OnPlot(MyPlotEvent& event)
@@ -746,7 +760,7 @@ void MyFrame::OnPlot(MyPlotEvent& event)
// example of code generating the event:
void MyWindow::SendEvent()
{
MyPlotEvent event(MY_PLOT_CLICKED, GetId(), wxPoint(...));
MyPlotEvent event(myEVT_PLOT_CLICKED, GetId(), wxPoint(...));
event.SetEventObject(this);
ProcessWindowEvent(event);
}
@@ -864,6 +878,32 @@ If you use wxNewId() consistently in your application, you can be sure that
your identifiers don't conflict accidentally.
@subsection overview_events_with_mouse_capture Event Handlers and Mouse Capture
Some events are generated in response to a user action performed using the
mouse and, often, the mouse will be captured (see wxWindow::CaptureMouse()) by
the window generating the event in this case. This happens when the user is
dragging the mouse, i.e. for all events involving resizing something (e.g. @c
EVT_SPLITTER_SASH_POS_CHANGING), but also, perhaps less obviously, when
selecting items (e.g. @c EVT_LIST_ITEM_SELECTED).
When the mouse is captured, the control sending events will continue receiving
all mouse events, meaning that the event handler can't do anything relying on
getting them in any other window. Most notably, simply showing a modal dialog
won't work as expected, as the dialog won't receive any mouse input and appear
unresponsive to the user.
The best solution is to avoid showing modal dialogs from such event handlers
entirely, as it can be jarring for the user to be interrupted in their workflow
by a dialog suddenly popping up. However if it's really indispensable to show a
dialog, you need to forcefully break the existing mouse capture by capturing
(and then releasing, because you don't really need the capture) it yourself:
@code
dialog.CaptureMouse();
dialog.ReleaseMouse();
@endcode
@subsection overview_events_custom_generic Generic Event Table Macros
@beginTable

2
docs/doxygen/overviews/grid.h
View File

@@ -84,6 +84,7 @@ Here is a list of classes related to wxGrid:
number.
@li wxGridCellBoolRenderer: Renderer showing the cell as checked or unchecked
box.
@li wxGridCellDateRenderer: Renderer showing the cell as date.
@li wxGridCellEditor: Base class for objects used to edit the cell value.
@li wxGridCellStringEditor: Editor for cells containing text strings.
@li wxGridCellNumberEditor: Editor for cells containing integer numbers.
@@ -91,6 +92,7 @@ Here is a list of classes related to wxGrid:
@li wxGridCellBoolEditor: Editor for boolean-valued cells.
@li wxGridCellChoiceEditor: Editor allowing to choose one of the predefined
strings (and possibly enter new one).
@li wxGridCellDateEditor: Editor for cells containing dates without time component.
@li wxGridEvent: The event sent by most of wxGrid actions.
@li wxGridSizeEvent: The special event sent when a grid column or row is
resized.

4
docs/doxygen/overviews/helloworld.h
View File

@@ -15,6 +15,10 @@ This page shows a very simple wxWidgets program that can be used as a skeleton
for your own code. While it does nothing very useful, it introduces a couple of
important concepts and explains how to write a working wxWidgets application.
Note that this simple example creates the UI entirely from C++ code which is
fine for a simple example, but more realistic examples will typically define
their UI at least partially in @ref overview_xrc "XRC resource files".
First, you have to include wxWidgets' header files, of course. This can be done
on a file by file basis (such as @c wx/window.h) or using one global include
(@c wx/wx.h) which includes most of the commonly needed headers (although not

149
docs/doxygen/overviews/high_dpi.md Normal file
View File

@@ -0,0 +1,149 @@
High DPI Support in wxWidgets {#overview_high_dpi}
=============================
[TOC]
Introduction
============
Many modern displays have way more pixels on the same surface than used to be
the norm, resulting in much higher values of DPI (dots, i.e. pixels, per inch)
than the traditionally used values. This allows to render texts, or geometric
shapes in general much more smoothly.
As an illustration here are two scaled up views of the same text in 11 pt
Helvetica using up the same space on screen. First on an original Mac display
at 72 dpi, then on a High DPI Display, called "Retina" by Apple with twice as
many pixels in both dimensions (144 dpi), thus 4 times the number of pixels on
the same surface. Using these the contours are much more detailed.
![11 pt Helvetica at 72 DPI](overview_highdpi_text_72.png)
![11 pt Helvetica at 144 DPI](overview_highdpi_text_144.png)
To the user the DPI is typically expressed using a scaling factor, by which the
baseline DPI value is multiplied. For example, MSW systems may use 125% or 150%
scaling, meaning that they use DPI of 120 or 144 respectively, as baseline DPI
value is 96. Similarly, Linux systems may use "2x" scaling, resulting in DPI
value of 192. Macs are slightly different, as even they also may use "2x"
scaling, as in the example above, the effective DPI corresponding to it is 144,
as the baseline value on this platform is 72.
The Problem with High DPI Displays
----------------------------------
If high DPI displays were treated in the same way as normal ones, existing
applications would look tiny of them. For example, a square window 500 pixels
in size would take half of a standard 1920×1080 ("Full HD") display vertically,
but only a quarter on a 3840×2160 ("4K UHD") display. To prevent this from
happening, most platforms automatically scale the windows by the scaling
factor, defined above, when displaying them on high DPI displays. In this
example, scaling factor is 2 and so the actual size of the window on screen
would become 1000 when automatic scaling is in effect.
Automatic scaling is convenient, but doesn't really allow the application to
use the extra pixels available on the display. Visually, this means that the
scaled application appears blurry, in contrast to sharper applications using
the full display resolution, so a better solution for interpreting pixel values
on high DPI displays is needed: one which allows to scale some pixel values
(e.g. the total window size), but not some other ones (e.g. those used for
drawing, which should remain unscaled to use the full available resolution).
Pixel Values in wxWidgets
=========================
Logical and Device-Independent Pixels
-------------------------------------
Some systems like eg Apple's OSes automatically scale all the coordinates by
the DPI scaling factor, however not all systems supported by wxWidgets do it --
notably, MSW does not. This means that **logical pixels**, in which all
coordinates and sizes are expressed in wxWidgets API, do _not_ have the same
meaning on all platforms when using high DPI displays. So while on macOS you
can always pass in a size of (500,500) to create the window from the previous
paragraph, whatever the resolution of the display is, you would have to
increase this to (1000,1000) on MSW when working on a 200% display. To hide
this difference from the application, wxWidgets provides **device-independent
pixels**, abbreviated as "DIP", that are always of the same size on all
displays and all platforms.
Thus, the first thing do when preparing your application for high DPI support
is to stop using raw pixel values. Actually, using any pixel values is not
recommended and replacing them with the values based on the text metrics, i.e.
obtained using wxWindow::GetTextExtent(), or expressing them in dialog units
(see wxWindow::ConvertDialogToPixels()) is preferable. However the simplest
change is to just replace the pixel values with the values in DIP: for this,
just use wxWindow::FromDIP() to convert from one to the other.
For example, if you have the existing code:
```cpp
myFrame->SetClientSize(wxSize(400, 300));
```
you can just replace it with
```cpp
myFrame->SetClientSize(myFrame->FromDIP(wxSize(400, 300)));
```
Physical Pixels
---------------
In addition to (logical) pixels and DIPs discussed above, you may also need to
work in physical pixel coordinates, corresponding to the actual display pixels.
Physical pixels are never scaled, on any platform, and must be used when
drawing graphics elements to ensure that the best possible resolution is used.
For example, all operations on wxGLCanvas use physical pixels.
To convert between logical and physical pixels, you can use
wxWindow::GetContentScaleFactor(): this is a value greater than or equal to 1,
so a value in logical pixels needs to be multiplied by it in order to obtain
the value in physical pixels.
For example, in a wxGLCanvas created with the size of 100 (logical) pixels, the
rightmost physical pixel coordinate will be `100*GetContentScaleFactor()`.
High-Resolution Images and Artwork
==================================
In order to benefit from the increased detail on High DPI devices you might want
to provide the images or artwork your application uses in higher resolutions as
well. Note that it is not recommended to just provide a high-resolution version
and let the system scale that down on 1x displays. Apart from performance
consideration also the quality might suffer, contours become more blurry.
You can use vector based graphics like SVG or you can add the same image at different
sizes / resolutions.
[comment]: # (TODO: API and Use Cases)
Platform-Specific Build Issues
==============================
Generally speaking, all systems handle applications not specifically marked as
being "DPI-aware" by emulating low-resolution display for them and scaling them
up, resulting in blurry graphics and fonts, but globally preserving the
application appearance. For the best results, the application needs to be
explicitly marked as DPI-aware in a platform-dependent way.
MSW
---
The behaviour of the application when running on a high-DPI display depends on
the values in its [manifest][1]. If your application include `wx/msw/wx.rc`
from its resource file, you need to predefine `wxUSE_DPI_AWARE_MANIFEST` to
opt-in into [high DPI support][2]: define it as `1` for minimal DPI awareness and
`2` for full, per-monitor DPI awareness supported by Windows 10 version 1703 or
later.
[1]: https://docs.microsoft.com/en-us/windows/win32/sbscs/application-manifests
[2]: https://docs.microsoft.com/en-us/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows
macOS
-----
DPI-aware applications must set their `NSPrincipalClass` to `wxNSApplication`
(or at least `NSApplication`) in their `Info.plist` file. Also see Apple [high
resolution guidelines][2] for more information.
[2]: https://developer.apple.com/library/archive/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html

2
docs/doxygen/overviews/html.h
View File

@@ -13,7 +13,7 @@
The wxHTML library provides classes for parsing and displaying HTML.
It is not intended to be a high-end HTML browser. If you are looking for
something like that try <http://www.mozilla.org/>.
something like that use wxWebView.
wxHTML can be used as a generic rich text viewer - for example to display
a nice About Box (like those of GNOME apps) or to display the result of

11
docs/doxygen/overviews/internationalization.h
View File

@@ -59,6 +59,11 @@ Translating your application involves several steps:
given language: see wxLocale.
@note Under macOS you also need to list all the supported languages under
@c CFBundleLocalizations key in your application @c Info.plist file
in order to allow the application to support the corresponding locale.
@section overview_i18n_mofiles Installing translation catalogs
The .mo files with compiled catalogs must be included with the application.
@@ -75,12 +80,12 @@ locations when possible.
Depending on the platform, the default location differs. On Windows, it is
alongside the executable. On Unix, translations are expected to be in
"$prefix/share/locale". On OS X, application bundle's @em Resources subdirectory
"$prefix/share/locale". On macOS, application bundle's @em Resources subdirectory
is used.
In all cases, translations are searched for in subdirectories named using the
languages codes from ISO 639. The .mo file(s) should be located either directly
in that directory or in LC_MESSAGES subdirectory. On OS X, ".lproj" extension
in that directory or in LC_MESSAGES subdirectory. On macOS, ".lproj" extension
is used for the per-languages Resources subdirectories.
Here's how an app would typically install the files on Unix:
@@ -89,7 +94,7 @@ Here's how an app would typically install the files on Unix:
/usr/share/locale/de/LC_MESSAGES/myapp.mo
/usr/share/locale/fr/LC_MESSAGES/myapp.mo
@endcode
And on OS X:
And on macOS:
@code
MyApp.app/Contents/MacOS/MyApp
MyApp.app/Contents/Resources/de.lproj/myapp.mo

12
docs/doxygen/overviews/log.h
View File

@@ -19,9 +19,9 @@ as well as several standard implementations of it and a family of functions to
use with them.
First of all, no knowledge of wxLog classes is needed to use them. For this,
you should only know about @ref group_funcmacro_log "wxLogXXX() functions".
All of them have the same syntax as @e printf() or @e vprintf() , i.e. they
take the format string as the first argument and respectively a variable number
you should only know about @ref group_funcmacro_log "wxLogXXX() functions".
All of them have the same syntax as @e printf() or @e vprintf() , i.e. they
take the format string as the first argument and respectively a variable number
of arguments or a variable argument list pointer. Here are all of them:
@li wxLogFatalError() which is like wxLogError(), but also terminates the program
@@ -161,8 +161,8 @@ works.
wxWidgets has the notion of a <em>log target</em>: it is just a class deriving
from wxLog. As such, it implements the virtual functions of the base class
which are called when a message is logged. Only one log target is @e active at
any moment, this is the one used by @ref group_funcmacro_log "wxLogXXX() functions".
The normal usage of a log object (i.e. object of a class derived from wxLog) is
any moment, this is the one used by @ref group_funcmacro_log "wxLogXXX() functions".
The normal usage of a log object (i.e. object of a class derived from wxLog) is
to install it as the active target with a call to @e SetActiveTarget() and it
will be used automatically by all subsequent calls to
@ref group_funcmacro_log "wxLogXXX() functions".
@@ -263,7 +263,7 @@ GUI is (already/still) available when your log target as used as wxWidgets
automatically switches to using wxLogStderr if it isn't.
There are several methods which may be overridden in the derived class to
customize log messages handling: wxLog::DoLogRecord(), wxLog::DoLogTextAtLevel()
customize log messages handling: wxLog::DoLogRecord(), wxLog::DoLogTextAtLevel()
and wxLog::DoLogText().
The last method is the simplest one: you should override it if you simply

2
docs/doxygen/overviews/printing.h
View File

@@ -84,7 +84,7 @@ The scaling of the drawn image typically differs from the screen to the preview
and printed images. This class provides a set of routines named
FitThisSizeToXXX(), MapScreenSizeToXXX(), and GetLogicalXXXRect, which can be
used to set the user scale and origin of the wxPrintout's DC so that your class
can easily map your image to the printout withough getting into the details of
can easily map your image to the printout without getting into the details of
screen and printer PPI and scaling. See the printing sample for examples of how
these routines are used.

11
docs/doxygen/overviews/propgrid.h
View File

@@ -733,10 +733,10 @@ accomplish the task:
@code
// Have property editor focus on Enter
propgrid->AddActionTrigger( wxPG_ACTION_EDIT, WXK_RETURN );
// Have Enter work as action trigger even when editor is focused
propgrid->DedicateKey( WXK_RETURN );
// Let Enter also navigate to the next property
propgrid->AddActionTrigger( wxPG_ACTION_NEXT_PROPERTY, WXK_RETURN );
@@ -807,10 +807,9 @@ See wxPGMultiButton class reference.
@subsection propgrid_customeventhandling Handling Events Passed from Properties
<b>wxEVT_COMMAND_BUTTON_CLICKED </b>(corresponds to event table macro EVT_BUTTON):
Occurs when editor button click is not handled by the property itself
(as is the case, for example, if you set property's editor to TextCtrlAndButton
from the original TextCtrl).
@c wxEVT_BUTTON: Occurs when editor button click is not handled by the property
itself (as is the case, for example, if you set property's editor
to TextCtrlAndButton from the original TextCtrl).
@subsection propgrid_attributes Property Attributes

6
docs/doxygen/overviews/richtextctrl.h
View File

@@ -42,7 +42,7 @@ list styles with a renumber option.
There are a few disadvantages to using wxRichTextCtrl. It is not native, so
does not behave exactly as a native wxTextCtrl, although common editing
conventions are followed. Users may miss the built-in spelling correction on
OS X, or any special character input that may be provided by the native
macOS, or any special character input that may be provided by the native
control. It would also be a poor choice if intended users rely on screen
readers that would be not work well with non-native text input implementation.
You might mitigate this by providing the choice between wxTextCtrl and
@@ -415,7 +415,7 @@ set the focus back to the top-level object.
An event will be sent to the control when the focus changes.
When the user clicks on the control, wxRichTextCtrl determines which container
to set as the current object focus by calling the found container's overrided
to set as the current object focus by calling the found container's overridden
wxRichTextObject::AcceptsFocus function. For example, although a table is a
container, it must not itself be the object focus because there is no text
editing at the table level. Instead, a cell within the table must accept the
@@ -495,7 +495,7 @@ tables, text boxes, and floating images, in addition to a simplified-HTML mode f
There are also things that could be done to take advantage of the underlying
text capabilities of the platform; higher-level text formatting APIs are
available on some platforms, such as OS X, and some of translation from
available on some platforms, such as macOS, and some of translation from
high level to low level wxDC API is unnecessary. However this would require
additions to the wxWidgets API.

51
docs/doxygen/overviews/roughguide.h
View File

@@ -11,28 +11,40 @@
@tableofcontents
To set a wxWidgets application going, you will need to derive a wxApp class and
override wxApp::OnInit.
@section overview_roughguide_structure Application Structure
An application must have a top-level wxFrame or wxDialog window. Each frame may
contain one or more instances of classes such as wxPanel, wxSplitterWindow or
other windows and controls.
To set a wxWidgets application going, you will need to derive a wxApp class and
override wxApp::OnInit() in which you will typically create your application
main top-level window.
This window can be a wxFrame or a wxDialog and may contain one or more
instances of classes such as wxPanel, wxSplitterWindow or other windows and
controls. These windows can be created from C++ code or loaded from resource
definitions in @ref overview_xrc "XRC format".
A frame can have a wxMenuBar, a wxToolBar, a wxStatusBar, and a wxIcon for when
the frame is iconized.
A wxPanel is used to place controls (classes derived from wxControl) which are
used for user interaction. Examples of controls are wxButton, wxCheckBox,
wxChoice, wxListBox, wxRadioBox, and wxSlider.
wxChoice, wxListBox, wxRadioBox, and wxSlider. Such controls need to be
positioned correctly -- and also repositioned when the top-level window is
resized by the user -- and to do this you use wxSizer-derived classes, such as
wxBoxSizer and wxFlexGridSizer, to layout everything correctly.
Instances of wxDialog can also be used for controls and they have the advantage
of not requiring a separate frame.
of not requiring a separate panel inside them.
Instead of creating a dialog box and populating it with items, it is possible
to choose one of the convenient common dialog classes, such as wxMessageDialog
and wxFileDialog.
You never draw directly onto a window - you use a <em>device context</em> (DC).
@section overview_roughguide_draw Drawing on the Screen
You never draw directly onto a window -- you use either one of the older
<em>device context</em> (DC) classes or the newer <em>graphics context</em>
(GC) one, that support features such as alpha transparency or anti-aliasing.
wxDC is the base for wxClientDC, wxPaintDC, wxMemoryDC, wxPostScriptDC,
wxMemoryDC, wxMetafileDC and wxPrinterDC. If your drawing functions have wxDC
as a parameter, you can pass any of these DCs to the function, and thus use the
@@ -40,20 +52,19 @@ same code to draw to several different devices. You can draw using the member
functions of wxDC, such as wxDC::DrawLine and wxDC::DrawText. Control colour on
a window (wxColour) with brushes (wxBrush) and pens (wxPen).
To intercept events, you add a wxDECLARE_EVENT_TABLE macro to the window class
declaration, and put a wxBEGIN_EVENT_TABLE ... wxEND_EVENT_TABLE block in the
implementation file. Between these macros, you add event macros which map the
event (such as a mouse click) to a member function. These might override
predefined event handlers such as for wxKeyEvent and wxMouseEvent.
With wxGraphicsContext, you create it using one of the methods of
wxGraphicsRenderer and then construct your drawing from wxGraphicsPath objects,
finally using wxGraphicsContext::StrokePath() or wxGraphicsContext::FillPath().
Most modern applications will have an on-line, hypertext help system; for this,
you need wxHelp and the wxHelpController class to control wxHelp.
GUI applications aren't all graphical wizardry. List and hash table needs are
catered for by wxList and wxHashMap. You will undoubtedly need some
platform-independent @ref group_funcmacro_file, and you may find it handy to
maintain and search a list of paths using wxPathList. There's many
@ref group_funcmacro_misc of operating system methods and other functions.
@section overview_roughguide_events Event Handling
GUI programs spend most of their time waiting for the user-initiated events --
and then processing them. To do it, you use wxEvtHandler::Bind() to specify the
handler for an event of the given time. Event handlers receive the object
describing the event, such as wxKeyEvent or wxMouseEvent, and perform whichever
action corresponds to it. See @ref overview_events "events handling" overview
for much more information about this subject.
@see @ref group_class

20
docs/doxygen/overviews/sizer.h
View File

@@ -15,7 +15,7 @@ Sizers, as represented by the wxSizer class and its descendants in the
wxWidgets class hierarchy, have become the method of choice to define the
layout of controls in dialogs in wxWidgets because of their ability to create
visually appealing dialogs independent of the platform, taking into account
the differences in size and style of the individual controls.
the differences in size and style of the individual controls.
The next section describes and shows what can be done with sizers. The
following sections briefly describe how to program with individual sizer
@@ -211,7 +211,7 @@ window will preserve it is original size, @c wxGROW flag (same as @c wxEXPAND) f
the window to grow with the sizer, and @c wxSHAPED flag tells the window to change
it is size proportionally, preserving original aspect ratio. When @c wxGROW flag
is not used, the item can be aligned within available space. @c wxALIGN_LEFT,
@c wxALIGN_TOP, @c wxALIGN_RIGHT, @c wxALIGN_BOTTOM, @c wxALIGN_CENTER_HORIZONTAL
@c wxALIGN_TOP, @c wxALIGN_RIGHT, @c wxALIGN_BOTTOM, @c wxALIGN_CENTER_HORIZONTAL
and @c wxALIGN_CENTER_VERTICAL do what they say. @c wxALIGN_CENTRE (same as
@c wxALIGN_CENTER) is defined as (<tt>wxALIGN_CENTER_HORIZONTAL | wxALIGN_CENTER_VERTICAL</tt>).
Default alignment is <tt>wxALIGN_LEFT | wxALIGN_TOP</tt>.
@@ -267,7 +267,7 @@ MyDialog::MyDialog(wxFrame *parent, wxWindowID id, const wxString &title )
}
@endcode
Note that the recommended way of specifying flags to wxSizer is via wxSizerFlags.
Note that the recommended way of specifying flags to wxSizer is via wxSizerFlags.
This class greatly eases the burden of passing flags to a wxSizer.
Here's how you'd do the previous example with wxSizerFlags:
@@ -313,18 +313,18 @@ MyDialog::MyDialog(wxFrame *parent, wxWindowID id, const wxString &title )
@section overview_sizer_types Other Types of Sizers
wxStdDialogButtonSizer is a sizer that creates button layouts in dialogs
which conform to the standard button spacing and ordering defined by
wxStdDialogButtonSizer is a sizer that creates button layouts in dialogs
which conform to the standard button spacing and ordering defined by
the platform or toolkit's user interface guidelines (if such things exist).
As a convenience, wxDialog::CreateButtonSizer() can be used to create this sizer.
wxWrapSizer is a sizer that lays out its items in a single line, like a box
sizer -- as long as there is space available in that direction. Once all available
space in the primary direction has been used, a new line is added and items
are added there.
wxWrapSizer is a sizer that lays out its items in a single line, like a box
sizer -- as long as there is space available in that direction. Once all available
space in the primary direction has been used, a new line is added and items
are added there.
wxGridBagSizer is a rather special kind of sizer which, unlike the other
classes, allows to directly put the elements at the given position in the
sizer.
sizer.
*/

32
docs/doxygen/overviews/string.h
View File

@@ -135,7 +135,7 @@ to buffer overflows. At last, C++ has a standard string class (@c std::string).
why the need for wxString? There are several advantages:
@li <b>Efficiency:</b> Since wxWidgets 3.0 wxString uses @c std::string (in UTF8
mode under Linux, Unix and OS X) or @c std::wstring (in UTF16 mode under Windows)
mode under Linux, Unix and macOS) or @c std::wstring (in UTF16 mode under Windows)
internally by default to store its contents. wxString will therefore inherit the
performance characteristics from @c std::string.
@li <b>Compatibility:</b> This class tries to combine almost full compatibility
@@ -236,12 +236,40 @@ arguments should take <tt>const wxString&</tt> (this makes assignment to the
strings inside the function faster) and all functions returning strings
should return wxString - this makes it safe to return local variables.
Finally note that wxString uses the current locale encoding to convert any C string
Note that wxString uses by default the current locale encoding to convert any C string
literal to Unicode. The same is done for converting to and from @c std::string
and for the return value of c_str().
For this conversion, the @a wxConvLibc class instance is used.
See wxCSConv and wxMBConv.
It is also possible to disable any automatic conversions from C
strings to Unicode. This can be useful when the @a wxConvLibc encoding
is not appropriate for the current software and platform. The macro @c
wxNO_IMPLICIT_WXSTRING_ENCODING disables all implicit conversions, and
forces the code to explicitly indicate the encoding of all C strings.
Finally note that encodings, either implicitly or explicitly selected,
may not be able to represent all the string's characters. The result
in this case is undefined: the string may be empty, or the
unrepresentable characters may be missing or wrong.
@code
wxString s;
// s = "world"; does not compile with wxNO_IMPLICIT_WXSTRING_ENCODING
s = wxString::FromAscii("world"); // Always compiles
s = wxASCII_STR("world"); // shorthand for the above
s = wxString::FromUTF8("world"); // Always compiles
s = wxString("world", wxConvLibc); // Always compiles, explicit encoding
s = wxASCII_STR("Grüße"); // Always compiles but encoding fails
const char *c;
// c = s.c_str(); does not compile with wxNO_IMPLICIT_WXSTRING_ENCODING
// c = s.mb_str(); does not compile with wxNO_IMPLICIT_WXSTRING_ENCODING
c = s.ToAscii(); // Always compiles, encoding may fail
c = s.ToUTF8(); // Always compiles, encoding never fails
c = s.utf8_str(); // Alias for the above
c = s.mb_str(wxConvLibc); // Always compiles, explicit encoding
@endcode
@subsection overview_string_iterating Iterating wxString Characters

2
docs/doxygen/overviews/unicode.h
View File

@@ -182,7 +182,7 @@ aware of the potential problems covered by the following section.
wxWidgets uses the system @c wchar_t in wxString implementation by default
under all systems. Thus, under Microsoft Windows, UCS-2 (simplified version of
UTF-16 without support for surrogate characters) is used as @c wchar_t is 2
bytes on this platform. Under Unix systems, including OS X, UCS-4 (also
bytes on this platform. Under Unix systems, including macOS, UCS-4 (also
known as UTF-32) is used by default, however it is also possible to build
wxWidgets to use UTF-8 internally by passing @c \--enable-utf8 option to
configure.

5
docs/doxygen/overviews/windowsizing.h
View File

@@ -116,4 +116,9 @@ some simple explanations of things.
the constraints algorithm is run. The @c Layout() method is what is called by
the default @c EVT_SIZE handler for container windows.
@li wxTopLevelWindow::Layout(): this overridden version does the same thing as
the base wxWindow::Layout() except, for convenience, it will also resize
the only child of the top-level window to cover its entire client area if
there is no sizer associated with the window. Note that this only happens
if there is exactly one child.
*/

4
docs/doxygen/overviews/xrc.h
View File

@@ -196,10 +196,10 @@ void MyClass::ShowDialog()
if (!wxXmlResource::Get()->LoadDialog(&dlg, NULL, "SimpleDialog"))
return;
XRCCTRL(dlg, "text", wxTextCtrl)->Bind(wxEVT_COMMAND_TEXT_UPDATED,
XRCCTRL(dlg, "text", wxTextCtrl)->Bind(wxEVT_TEXT,
wxTextEventHandler(MyClass::OnTextEntered), this, XRCID("text"));
XRCCTRL(dlg, "clickme_btn", wxButton)->Bind(wxEVT_COMMAND_BUTTON_CLICKED,
XRCCTRL(dlg, "clickme_btn", wxButton)->Bind(wxEVT_BUTTON,
wxCommandEventHandler(MyClass::OnClickme), this, XRCID("clickme_btn"));
dlg.ShowModal();

96
docs/doxygen/overviews/xrc_format.h
View File

@@ -115,7 +115,7 @@ These come in two varieties:
("\<label\>Cancel\</label\>"), but they may use nested subelements too (e.g.
@ref overview_xrcformat_type_font "font property"). A property can only be
listed once in an object's definition.
-# Child objects. Window childs, sizers, sizer items or notebook pages
-# Child objects. Window children, sizers, sizer items or notebook pages
are all examples of child objects. They are represented using nested
@c \<object\> elements and are can be repeated more than once. The specifics
of which object classes are allowed as children are class-specific and
@@ -352,6 +352,9 @@ wxFileSystem URL) of the bitmap to use. For example:
The value is interpreted as path relative to the location of XRC file where the
reference occurs.
Bitmap file paths can include environment variables that are expanded if
wxXRC_USE_ENVVARS was passed to the wxXmlResource constructor.
Alternatively, it is possible to specify the bitmap using wxArtProvider IDs.
In this case, the property element has no textual value (filename) and instead
has the @c stock_id XML attribute that contains stock art ID as accepted by
@@ -389,6 +392,16 @@ Examples:
@endcode
@subsection overview_xrcformat_type_showeffect Show Effect
One of the @ref wxShowEffect values.
Example:
@code
<showeffect>wxSHOW_EFFECT_EXPAND</showeffect>
@endcode
@subsection overview_xrcformat_type_font Font
XRC uses similar, but more flexible, abstract description of fonts to that
@@ -756,6 +769,11 @@ Refer to the section @ref xrc_wxtoolbar for more details.
@hdr3col{property, type, description}
@row3col{default, @ref overview_xrcformat_type_bool,
Should this button be the default button in dialog (default: 0)?}
@row3col{close, @ref overview_xrcformat_type_bool,
If set, this is a special "Close" button using system-defined appearance,
see wxBitmapButton::NewCloseButton(). If this property is set, @c bitmap
and @c style are ignored and shouldn't be used. Available since wxWidgets
3.1.5.}
@row3col{bitmap, @ref overview_xrcformat_type_bitmap,
Bitmap to show on the button (default: none).}
@row3col{selected, @ref overview_xrcformat_type_bitmap,
@@ -944,6 +962,9 @@ The wxCommandLinkButton contains a main title-like @c label and an optional
concatenated into a single string using a new line character between them
(notice that the @c note part can have more new lines in it).
Since wxWidgets 3.1.5 it also supports @c default and @c bitmap properties,
just as @ref xrc_wxbutton wxButton.
@beginTable
@hdr3col{property, type, description}
@row3col{label, @ref overview_xrcformat_type_text,
@@ -951,6 +972,10 @@ concatenated into a single string using a new line character between them
will be made when the button is pressed (default: empty). }
@row3col{note, @ref overview_xrcformat_type_text,
Second line of text describing the action performed when the button is pressed (default: none). }
@row3col{bitmap, @ref overview_xrcformat_type_bitmap,
Bitmap to display in the button (optional).}
@row3col{default, @ref overview_xrcformat_type_bool,
Should this button be the default button in dialog (default: 0)?}
@endTable
@@ -1021,6 +1046,25 @@ Example:
@endTable
@subsubsection xrc_wxdataviewctrl wxDataViewCtrl
No additional properties.
@subsubsection xrc_wxdataviewlistctrl wxDataViewListCtrl
No additional properties.
@subsubsection xrc_wxdataviewtreectrl wxDataViewTreeCtrl
@beginTable
@hdr3col{property, type, description}
@row3col{imagelist, @ref overview_xrcformat_type_imagelist,
Image list to use for the images (default: none).}
@endTable
@subsubsection xrc_wxdatepickerctrl wxDatePickerCtrl
No additional properties.
@@ -1153,6 +1197,14 @@ objects. If sizer child is used, it sets
Ignored, preserved only for compatibility.}
@endTable
@subsubsection xrc_wxgenericanimationctrl wxGenericAnimationCtrl
This handler is identical to the one for @ref xrc_wxanimationctrl
"wxAnimationCtrl", please see it for more information. The only difference is
that, for the platforms with a native wxAnimationCtrl implementation, using
this handler creates a generic control rather than a native one.
@subsubsection xrc_wxgenericdirctrl wxGenericDirCtrl
@beginTable
@@ -1199,6 +1251,40 @@ page.
@endTable
@subsubsection xrc_wxinfobar wxInfoBar
@beginTable
@hdr3col{property, type, description}
@row3col{showeffect, @ref overview_xrcformat_type_showeffect,
The effect to use when showing the bar (optional).}
@row3col{hideeffect, @ref overview_xrcformat_type_showeffect,
The effect to use when hiding the bar (optional).}
@row3col{effectduration, integer,
The duration of the animation used when showing or hiding the bar
(optional).}
@row3col{button, object,
Add a button to be shown in the info bar (see wxInfoBar::AddButton);
this property is of class "button" has name (can be one of standard
button ID) and has optional label property. If no buttons are added
to the info bar, the default "Close" button will be shown.}
@endTable
Example:
@code
<object class="wxInfoBar">
<effectduration>1000</effectduration>
<showeffect>wxSHOW_EFFECT_EXPAND</showeffect>
<hideeffect>wxSHOW_EFFECT_SLIDE_TO_RIGHT</hideeffect>
<object class="button" name="wxID_UNDO"/>
<object class="button" name="wxID_REDO">
<label>Redo Custom Label</label>
</object>
</object>
@endcode
@since 3.1.3
@subsubsection xrc_wxlistbox wxListBox
@beginTable
@@ -1745,7 +1831,7 @@ objects have the following properties:
@endTable
A wxRibbonPage may have children of any type derived from wxRibbonControl.
Most commontly, wxRibbonPanel is used. As a special case, the @c panel
Most commonly, wxRibbonPanel is used. As a special case, the @c panel
pseudo-class may be used instead of @c wxRibbonPanel when used as wxRibbonPage
children.
@@ -2589,15 +2675,15 @@ should be processed on. It is filtered out and ignored on any other platforms.
Possible elemental values are:
@beginDefList
@itemdef{ @c win, Windows }
@itemdef{ @c mac, OS X (or Mac Classic in wxWidgets version supporting it) }
@itemdef{ @c unix, Any Unix platform @em except OS X }
@itemdef{ @c mac, macOS (or Mac Classic in wxWidgets version supporting it) }
@itemdef{ @c unix, Any Unix platform @em except macOS }
@endDefList
Examples:
@code
<label platform="win">Windows</label>
<label platform="unix">Unix</label>
<label platform="mac">OS X</label>
<label platform="mac">macOS</label>
<help platform="mac|unix">Not a Windows machine</help>
@endcode

52
docs/doxygen/regen.sh
View File

@@ -6,7 +6,7 @@
# readable.
#
# Usage:
# ./regen.sh [html|chm|xml|latex|all]
# ./regen.sh [html|chm|xml|latex|docset|all]
#
# Pass "x" to regen only the X output format and "all" to regen them all.
# If no arguments are passed, HTML is regenerated (just like passing "html").
@@ -17,6 +17,8 @@
me=$(basename $0)
path=${0%%/$me} # path from which the script has been launched
cd "$path"
SCRIPTS_DIR="$(pwd)/scripts"
if [[ -z "$WXWIDGETS" ]]; then
# Notice the use of -P to ensure we get the canonical path even if there
# are symlinks in the current path. This is important because Doxygen
@@ -80,6 +82,7 @@ case "$1" in
docset)
export GENERATE_DOCSET="YES"
export GENERATE_HTML="YES"
export GENERATE_TAGFILE="$path/out/wxWidgets.tag"
;;
latex)
export GENERATE_LATEX="YES"
@@ -166,7 +169,11 @@ if [[ "$1" = "docset" ]]; then
ATOMDIR="https://docs.wxwidgets.org/docsets"
XAR="$BASENAME.xar"
XARDIR="https://docs.wxwidgets.org/docsets"
XCODE_INSTALL=`xcode-select -print-path`
# See if xcode is installed
if [ -x "$(command -v xcode-select)" ]; then
XCODE_INSTALL=`xcode-select -print-path`
fi
cd out/html
DESTINATIONDIR=`pwd`/../docset
@@ -177,19 +184,38 @@ if [[ "$1" = "docset" ]]; then
make DOCSET_NAME=$DESTINATIONDIR/$DOCSETNAME
defaults write $DESTINATIONDIR/$DOCSETNAME/Contents/Info CFBundleVersion 1.3
defaults write $DESTINATIONDIR/$DOCSETNAME/Contents/Info CFBundleShortVersionString 1.3
defaults write $DESTINATIONDIR/$DOCSETNAME/Contents/Info CFBundleName "wxWidgets 3.1"
defaults write $DESTINATIONDIR/$DOCSETNAME/Contents/Info DocSetFeedURL $ATOMDIR/$ATOM
defaults write $DESTINATIONDIR/$DOCSETNAME/Contents/Info DocSetFallbackURL https://docs.wxwidgets.org
defaults write $DESTINATIONDIR/$DOCSETNAME/Contents/Info DocSetDescription "API reference and conceptual documentation for wxWidgets 3.0"
defaults write $DESTINATIONDIR/$DOCSETNAME/Contents/Info NSHumanReadableCopyright "Copyright 1992-2018 wxWidgets team, Portions 1996 Artificial Intelligence Applications Institute"
defaults write $DESTINATIONDIR/$DOCSETNAME/Contents/Info isJavaScriptEnabled true
defaults write $DESTINATIONDIR/$DOCSETNAME/Contents/Info dashIndexFilePath index.html
defaults write $DESTINATIONDIR/$DOCSETNAME/Contents/Info DocSetPlatformFamily wx
# Choose which plist modification utility to use
if [ -x "$(command -v defaults)" ]; then
PLIST_WRITE_CMD="defaults write"
else
PLIST_WRITE_CMD="python $SCRIPTS_DIR/write_info_tag.py"
fi
$XCODE_INSTALL/usr/bin/docsetutil package -atom $DESTINATIONDIR/$ATOM -download-url $XARDIR/$XAR -output $DESTINATIONDIR/$XAR $DESTINATIONDIR/$DOCSETNAME
# Modify the Info.plist file
$PLIST_WRITE_CMD $DESTINATIONDIR/$DOCSETNAME/Contents/Info CFBundleVersion 1.3
$PLIST_WRITE_CMD $DESTINATIONDIR/$DOCSETNAME/Contents/Info CFBundleShortVersionString 1.3
$PLIST_WRITE_CMD $DESTINATIONDIR/$DOCSETNAME/Contents/Info CFBundleName "wxWidgets 3.1"
$PLIST_WRITE_CMD $DESTINATIONDIR/$DOCSETNAME/Contents/Info DocSetFeedURL $ATOMDIR/$ATOM
$PLIST_WRITE_CMD $DESTINATIONDIR/$DOCSETNAME/Contents/Info DocSetFallbackURL https://docs.wxwidgets.org
$PLIST_WRITE_CMD $DESTINATIONDIR/$DOCSETNAME/Contents/Info DocSetDescription "API reference and conceptual documentation for wxWidgets 3.0"
$PLIST_WRITE_CMD $DESTINATIONDIR/$DOCSETNAME/Contents/Info NSHumanReadableCopyright "Copyright 1992-2020 wxWidgets team, Portions 1996 Artificial Intelligence Applications Institute"
$PLIST_WRITE_CMD $DESTINATIONDIR/$DOCSETNAME/Contents/Info isJavaScriptEnabled true
$PLIST_WRITE_CMD $DESTINATIONDIR/$DOCSETNAME/Contents/Info dashIndexFilePath index.html
$PLIST_WRITE_CMD $DESTINATIONDIR/$DOCSETNAME/Contents/Info DocSetPlatformFamily wx
echo "Creating docset database"
if ! [ -z "$XCODE_INSTALL" ]; then
# Use xcode to create the docset if it is installed
$XCODE_INSTALL/usr/bin/docsetutil package -atom $DESTINATIONDIR/$ATOM -download-url $XARDIR/$XAR -output $DESTINATIONDIR/$XAR $DESTINATIONDIR/$DOCSETNAME
else
# Use doxytag2zealdb to create the database
# This requires the python package doxytag2zealdb installed
python -m doxytag2zealdb --tag $DESTINATIONDIR/../wxWidgets.tag --db $DESTINATIONDIR/$DOCSETNAME/Contents/Resources/docSet.dsidx --include-parent-scopes --include-function-signatures
fi
# Copy the icon
cp $SCRIPTS_DIR/../../../art/wxwin16x16.png $DESTINATIONDIR/$DOCSETNAME/icon.png
cp $SCRIPTS_DIR/../../../art/wxwin32x32.png $DESTINATIONDIR/$DOCSETNAME/icon@2x.png
cd ../..
fi

12
docs/doxygen/scripts/c_tools.py
View File

@@ -16,14 +16,14 @@ class CBuilder:
output_dir = os.path.abspath(os.path.join(self.output_dir, "c"))
if not os.path.exists(output_dir):
os.makedirs(output_dir)
for aclass in self.doxyparser.classes:
# This bit doesn't work, because the aclass.name is not the same as
# those listed in common
if aclass.name in excluded_classes:
#print "Skipping %s" % aclass.name
continue
self.make_c_header(output_dir, aclass)
@@ -46,7 +46,7 @@ class CBuilder:
def make_c_methods(self, aclass):
retval = ""
wxc_classname = 'wxC' + aclass.name[2:].capitalize()
for amethod in aclass.constructors:
@@ -59,13 +59,13 @@ class CBuilder:
if amethod.name.startswith('m_'):
# for some reason, public members are listed as methods
continue
args = '(' + wxc_classname + '* obj'
if amethod.argsstring.find('()') != -1:
args += ')'
else:
else:
args += ', ' + amethod.argsstring[1:].strip()
retval += """
// %s
%s %s%s;\n

4
docs/doxygen/scripts/common.py
View File

@@ -15,7 +15,7 @@ excluded_classes = [
"wxArchiveIterator",
"wxArchiveNotifier",
"wxArchiveOutputStream",
"wxArray< T >",
"wxArray< T >",
"wxArrayString",
"wxAutomationObject",
"wxBufferedInputStream",
@@ -160,5 +160,5 @@ def make_enums(aclass):
retval += ", "
retval += "\n"
retval += "};\n\n"
return retval

56
docs/doxygen/scripts/doxymlparser.py
View File

@@ -38,23 +38,23 @@ class ClassDefinition:
self.includes = []
self.bases = []
self.enums = {}
def __str__(self):
str_repr = """
Class: %s
Bases: %s
Includes: %s
Brief Description:
Brief Description:
%s
Detailed Description:
%s
""" % (self.name, string.join(self.bases, ", "), self.includes, self.brief_description, self.detailed_description)
str_repr += "Methods:\n"
for method in self.methods:
str_repr += str(method)
return str_repr
class MethodDefinition:
@@ -66,20 +66,20 @@ class MethodDefinition:
self.params = []
self.brief_description = ""
self.detailed_description = ""
def __str__(self):
str_repr = """
Method: %s
Return Type: %s
Params: %r
Prototype: %s
Brief Description:
Brief Description:
%s
Detailed Description:
%s
""" % (self.name, self.return_type, self.params, self.definition + self.argsstring, self.brief_description, self.detailed_description)
return str_repr
return str_repr
def getTextValue(node, recursive=False):
text = ""
@@ -89,7 +89,7 @@ def getTextValue(node, recursive=False):
if child.nodeType == child.TEXT_NODE:
# Add a space to ensure we have a space between qualifiers and parameter names
text += child.nodeValue.strip() + " "
return text.strip()
def doxyMLToText(node):
@@ -104,7 +104,7 @@ class DoxyMLParser:
for aclass in self.classes:
if aclass.name == name:
return aclass
return None
def get_enums_and_functions(self, filename, aclass):
@@ -119,17 +119,17 @@ class DoxyMLParser:
def is_derived_from_base(self, aclass, abase):
base = get_first_value(aclass.bases)
while base and base != "":
if base == abase:
return True
parentclass = self.find_class(base)
if parentclass:
base = get_first_value(parentclass.bases)
else:
base = None
return False
def parse(self, filename):
@@ -138,7 +138,7 @@ class DoxyMLParser:
new_class = self.parse_class(node)
self.classes.append(new_class)
self.get_enums_and_functions(filename, new_class)
def parse_class(self, class_node):
new_class = ClassDefinition()
new_class.name = getTextValue(class_node.getElementsByTagName("compoundname")[0])
@@ -156,21 +156,21 @@ class DoxyMLParser:
self.parse_methods(new_class, class_node)
return new_class
def parse_enum(self, new_class, enum, root):
enum_name = ""
enum_values = []
for node in enum.childNodes:
if node.nodeName == "name":
enum_name = getTextValue(node)
elif node.nodeName == "enumvalue":
enum_values.append(getTextValue(node.getElementsByTagName("name")[0]))
new_class.enums[enum_name] = enum_values
def parse_methods(self, new_class, root):
for method in root.getElementsByTagName("memberdef"):
for method in root.getElementsByTagName("memberdef"):
new_method = MethodDefinition()
for node in method.childNodes:
if node.nodeName == "name":
@@ -187,10 +187,10 @@ class DoxyMLParser:
if child.nodeType == child.ELEMENT_NODE:
param[child.nodeName] = getTextValue(child)
new_method.params.append(param)
if self.verbose:
print "Adding %s" % (new_method.name + new_method.argsstring)
if new_method.name == new_class.name:
new_class.constructors.append(new_method)
elif new_method.name == "~" + new_class.name:
@@ -199,30 +199,30 @@ class DoxyMLParser:
new_class.methods.append(new_method)
if __name__ == "__main__":
option_dict = {
option_dict = {
"report" : (False, "Print out the classes and methods found by this script."),
"verbose" : (False, "Provide status updates and other information."),
}
parser = optparse.OptionParser(usage="usage: %prog [options] <doxyml files to parse>\n" + __description__, version="%prog 1.0")
for opt in option_dict:
default = option_dict[opt][0]
action = "store"
if type(default) == types.BooleanType:
action = "store_true"
parser.add_option("--" + opt, default=default, action=action, dest=opt, help=option_dict[opt][1])
options, arguments = parser.parse_args()
if len(arguments) < 1:
parser.print_usage()
sys.exit(1)
doxyparse = DoxyMLParser(verbose = options.verbose)
for arg in arguments:
doxyparse.parse(arg)
doxyparse.parse(arg)
if options.report:
for aclass in doxyparse.classes:

20
docs/doxygen/scripts/make_bindings.py
View File

@@ -12,42 +12,42 @@ import swig_tools
from common import *
if __name__ == "__main__":
option_dict = {
option_dict = {
"output_dir" : ("output", "Directory to output bindings to"),
"sip" : (True, "Produce SIP bindings"),
"swig" : (True, "Produce SWIG bindings."),
"c" : (True, "Produce C wrappers."),
}
parser = optparse.OptionParser(usage="usage: %prog <doxyml files to parse>\n" , version="%prog 1.0")
for opt in option_dict:
default = option_dict[opt][0]
action = "store"
if type(default) == types.BooleanType:
action = "store_true"
parser.add_option("--" + opt, default=default, action=action, dest=opt, help=option_dict[opt][1])
options, arguments = parser.parse_args()
if len(arguments) < 1:
parser.print_usage()
sys.exit(1)
doxyparse = doxymlparser.DoxyMLParser()
for arg in arguments:
doxyparse.parse(arg)
if options.sip:
builder = sip_tools.SIPBuilder(doxyparse, options.output_dir)
builder.make_bindings()
if options.swig:
builder = swig_tools.SWIGBuilder(doxyparse, options.output_dir)
builder.make_bindings()
if options.c:
builder = c_tools.CBuilder(doxyparse, options.output_dir)
builder.make_bindings()

22
docs/doxygen/scripts/sip_tools.py
View File

@@ -11,12 +11,12 @@ class SIPBuilder:
output_dir = os.path.abspath(os.path.join(self.output_dir, "sip"))
if not os.path.exists(output_dir):
os.makedirs(output_dir)
for aclass in self.doxyparser.classes:
if aclass.name in excluded_classes:
print "Skipping %s" % aclass.name
continue
header_name = aclass.name[2:].lower()
filename = os.path.join(output_dir, "_" + header_name + ".sip")
enums_text = make_enums(aclass)
@@ -24,7 +24,7 @@ class SIPBuilder:
base_class = get_first_value(aclass.bases)
if base_class != "":
base_class = ": %s" % base_class
text = """
%s
class %s %s
@@ -45,12 +45,12 @@ public:
def make_sip_methods(self, aclass):
retval = ""
for amethod in aclass.constructors + aclass.methods:
transfer = ""
# FIXME: we need to come up with a way of filtering the methods out by various criteria
# including parameters and method name, and how to deal with overloads
# including parameters and method name, and how to deal with overloads
if aclass.name in ignored_methods:
should_ignore = False
for method in ignored_methods[aclass.name]:
@@ -66,19 +66,19 @@ public:
print "param type = %s, amethod.param type = %s" % (params[i], amethod.params[i]["type"])
should_ignore = False
break
if should_ignore:
continue
# We need to let SIP know when wx is responsible for deleting the object.
# We do this if the class is derived from wxWindow, since wxTLW manages child windows
# and wxApp deletes all wxTLWs on shutdown
if amethod in aclass.constructors and self.doxyparser.is_derived_from_base(aclass, "wxWindow"):
transfer = "/Transfer/"
if amethod.name.startswith("operator"):
continue
retval += " %s %s%s%s;\n\n" % (amethod.return_type.replace("virtual ", ""), amethod.name, amethod.argsstring, transfer)
return retval

18
docs/doxygen/scripts/swig_tools.py
View File

@@ -11,13 +11,13 @@ class SWIGBuilder:
output_dir = os.path.abspath(os.path.join(self.output_dir, "swig"))
if not os.path.exists(output_dir):
os.makedirs(output_dir)
for aclass in self.doxyparser.classes:
header_name = aclass.name[2:].lower()
if aclass.name in excluded_classes:
#print "Skipping %s" % aclass.name
continue
filename = os.path.join(output_dir, "_" + header_name + ".i")
enums_text = make_enums(aclass)
method_text = self.make_swig_methods(aclass)
@@ -37,25 +37,25 @@ public:
afile.write(text)
afile.close()
def make_swig_methods(self, aclass):
retval = ""
retval += """
%%pythonAppend %s "self._setOORInfo(self)"
%%pythonAppend %s() ""
%%typemap(out) %s*; // turn off this typemap
""" % (aclass.name, aclass.name, aclass.name)
for amethod in aclass.constructors:
retval += " %s%s;\n\n" % (amethod.name, amethod.argsstring)
retval += """
// Turn it back on again
%%typemap(out) %s* { $result = wxPyMake_wxObject($1, $owner); }
%%typemap(out) %s* { $result = wxPyMake_wxObject($1, $owner); }
""" % aclass.name
for amethod in aclass.methods:
retval += " %s %s%s;\n\n" % (amethod.return_type, amethod.name, amethod.argsstring)
return retval

41
docs/doxygen/scripts/write_info_tag.py Executable file
View File

@@ -0,0 +1,41 @@
#
# write_info_tag.py
# Write a key/value pair to an Info.plist file created by Doxygen
# while generating docsets.
#
# Author: Ian McInerney (https://github.com/imciner2)
import sys
import plistlib
# The first argument is the plist filename without the extension
fname = sys.argv[1] + ".plist"
# The second argument is the key to replace
key = sys.argv[2]
# The third argument is the value of the key
val = sys.argv[3]
# Handle boolean values
if val.lower() == "true":
val = True
elif val.lower() == "false":
val = False
if sys.version_info >= (3, 4, 0):
# Use the new API if python 3.4 is used
with open( fname, 'rb' ) as plist_file:
pl = plistlib.load( plist_file )
pl[key] = val
with open( fname, 'wb' ) as plist_file:
pl = plistlib.dump( pl, plist_file )
else:
# Use the old API otherwise (supports python 2.7 as well)
pl = plistlib.readPlist( fname )
pl[key] = val
plistlib.writePlist( pl, fname )