=============
NB: this file applies to wxBase library only. If you are using a GUI version
- of wxWindows, please refer to the documentation in the appropriate
+ of wxWidgets, please refer to the documentation in the appropriate
subdirectory (msw, gtk, motif &c).
0. Introduction
---------------
- wxBase is the library providing most of the non-GUI classes of the wxWindows
+ wxBase is the library providing most of the non-GUI classes of the wxWidgets
cross-platform C++ framework. wxBase has some generic classes such as yet
another C++ string class, typesafe dynamic arrays, hashes and lists and, more
excitingly, wxDateTime -- a very flexible and powerful class for manipulating
3. Installing under Unix/BeOS
-----------------------------
-NB: If you're building wxBase from the wxWindows distribution and not from a
+NB: If you're building wxBase from the wxWidgets distribution and not from a
separate wxBase one you will need to add "--disable-gui" to configure
arguments below!
The recommended way to build wxBase is:
- % cd ..../wxWindows
+ % cd ..../wxWidgets
% mkdir base-release # or any other directory of your liking
% cd base-release
% ../configure
wxBase classes. It doesn't do anything useful per itself but you may want to
look at its code to see examples of usage of the class you are interested in.
- There is no separate documentation for wxBase, please refer to wxWindows
+ There is no separate documentation for wxBase, please refer to wxWidgets
documentation instead.
- Support for wxBase is available from the same places as for wxWindows itself,
+ Support for wxBase is available from the same places as for wxWidgets itself,
namely:
* Usenet newsgroup comp.soft-sys.wxwindows
* Mailing lists: see http://lists.wxwindows.org/ for more information
-* WWW page: http://www.wxwindows.org/
+* WWW page: http://www.wxwidgets.org/
Hope you will find wxBase useful!
----------------------------
-wxWindows 2.5/2.6 Change Log
+wxWidgets 2.5/2.6 Change Log
----------------------------
INCOMPATIBLE CHANGES SINCE 2.4.x
DEPRECATED METHODS SINCE 2.4.x
==============================
-Deprecated methods may still be used but will disappear in future wxWindows
+Deprecated methods may still be used but will disappear in future wxWidgets
versions, please update your code to not use them.
- wxDocManager::GetNoHistoryFiles() renamed to GetHistoryFilesCount()
- wxTheFontMapper: use wxFontMapper::Get() instead
- wxStringHashTable: use wxHashMap instead
- wxHashTableLong: use wxHashMap instead
-- wxArrayString::GetStringArray: use wxCArrayString or alternative wxWindows
+- wxArrayString::GetStringArray: use wxCArrayString or alternative wxWidgets
methods taking wxArrayString
- wxArrayString::Remove(index, count): use RemoveAt instead
- wxTreeItemId conversion to long is deprecated and shouldn't be used
wxMSW:
-- wxWindows now builds under Win64
+- wxWidgets now builds under Win64
- fixed DDE memory leaks
- fixed wxTE_*WRAP styles handling
- wxTextCtrl::GetValue() works with text in non default encoding
All:
- It is now possible to build several smaller libraries instead of single
- huge wxWindows library; wxBase is now dependency of GUI ports rather then
+ huge wxWidgets library; wxBase is now dependency of GUI ports rather then
separately compiled library
- added wxDateSpan::operator==() and !=() (Lukasz Michalski)
- added wxFileName::GetForbiddenChars() (Dimitri Schoolwerth)
- improved border handling under Windows XP
- partial fix for wxNotebook pages looking bad under XP: wxUSE_UXTHEME
enables XP theme engine code, and wxUSE_UXTHEME_AUTO tells
- wxWindows to use the theme tab colour for control backgrounds.
+ wxWidgets to use the theme tab colour for control backgrounds.
- disable wxNB_RIGHT, wxNB_LEFT, wxNB_BOTTOM notebook styles under Windows XP
- fixed release mode build with VC 7.x (Martin Ecker)
- added support for wxALWAYS_SHOW_SB style
2.6 release.
NB: if you want to build your program with different major versions
- of wxWindows you will probably find the wxCHECK_VERSION() macro
+ of wxWidgets you will probably find the wxCHECK_VERSION() macro
(see the documentation) useful.
Unix (Base/GUI):
-- wxWindows may be built using BSD and Solaris (and possibly other) make
+- wxWidgets may be built using BSD and Solaris (and possibly other) make
programs and not only GNU make
- wxTCP-based IPC classes now support communicating over Unix domain sockets
-- wxWindows may be built as a dynamic shared library under Darwin / Mac OS X
+- wxWidgets may be built as a dynamic shared library under Darwin / Mac OS X
lazy linking issues have been solved by linking a single module (.o) into
the shared library (two step link using distrib/mac/shared-ld-sh)
- fixed thread priority setting under Linux
- implemented radio menu items and radio toolbar buttons
- added possibility to show text in the toolbar buttons
- added wxArtProvider class that can be used to customize the look of standard
- wxWindows dialogs
+ wxWidgets dialogs
- significantly improved native font support
- wxImage::ComputeHistogram() now uses wxImageHistogram instead of type-unsafe
wxHashTable
- fixed multiple bugs in wxExecute() with IO redirection
- refresh the buttons properly when the window is resized (Hans Van Leemputten)
- huge (40*) speed up in wxMask::Create()
-- changing wxWindows styles also changes the underlying Windows window style
+- changing wxWidgets styles also changes the underlying Windows window style
- wxTreeCtrl supports wxTR_HIDE_ROOT style (George Policello)
- fixed flicker in wxTreeCtrl::SetItemXXX()
- fixed redraw problems in dynamically resized wxStaticText
-- improvements to wxWindows applications behaviour when the system colours
+- improvements to wxWidgets applications behaviour when the system colours
are changed
- choose implicit parent for the dialog boxes better
- fixed wxProgressDialog for ranges > 65535
- Fixed wxFrame::SetClientSize() with toolbar bug
- Added mousewheel processing
- Added wxSystemSettings::Get/SetOption so we can configure
- wxWindows at run time; used this to implement no-maskblt option
+ wxWidgets at run time; used this to implement no-maskblt option
in wxDC
- Fixed bug when using MDIS_ALLCHILDSTYLES style: so now MDI
child frame styles are honoured
fixed handling of relative and absolute font sizes in <font size>
-NOTE: for changes after wxWindows 2.1.0 b4, please see the CVS
+NOTE: for changes after wxWidgets 2.1.0 b4, please see the CVS
change log.
2.1.0, b4, May 9th 1999
- Makefiles for more compilers and samples; Cygwin makefiles
rationalised.
-- Added VC++ project file for compiling wxWindows as DLL.
+- Added VC++ project file for compiling wxWidgets as DLL.
wxMotif:
- Added wxJoystick class and event handling, and simple demo.
- Added simple wxWave class. Needs Stop() function.
- Added wxModule (module.h/module.cpp) to allow definition
- of modules to be initialized and cleaned up on wxWindows
+ of modules to be initialized and cleaned up on wxWidgets
startup/exit.
- Start of Mingw32 compatibility (see minimal and dialogs samples
makefile.m95 files, and install.txt).
- Added wxTaskBarIcon (taskbar.cpp/h, plus samples/taskbar)
to allow maintenance of an icon in the Windows 95 taskbar
tray area.
-- Got MFC sample working (MFC and wxWindows in the same
+- Got MFC sample working (MFC and wxWidgets in the same
application), partly by tweaking ntwxwin.mak settings.
- Got DLL compilation working again (VC++).
- Changed wxProp/Dialog Editor filenames.
For the time being, the standard configure/make method works. You will
want to build static because there are a number of unimplemented functions
-that a shared library will need (becuase of wxWindows code internally using
+that a shared library will need (becuase of wxWidgets code internally using
them) but that a static library will not (because most of the samples
don't need it).
On my system I have the following:
Checked out CVS source is in:
-/Users/dfe/devel/wxHEADcommit/wxWindows
+/Users/dfe/devel/wxHEADcommit/wxWidgets
Debug build directory is:
/Users/dfe/devel/wxHEADcommit/BUILD_COCOAd
From the debug build directory:
-$ ../wxWindows/configure --with-cocoa --enable-debug --disable-shared
+$ ../wxWidgets/configure --with-cocoa --enable-debug --disable-shared
$ make
$ cd samples/minimal
$ make
wxCocoa is still very much a work in progress. At this point quite a bit
of functionality is working, but quite a bit is left to do. wxCocoa is not
-yet suitable for a direct port of most wxWindows applications. Fortunately,
+yet suitable for a direct port of most wxWidgets applications. Fortunately,
wxMac is available for those looking to move to Mac today.
If you're still reading then I assume you're interested in helping with
-*** wxWindows 2.3.3 ***
+*** wxWidgets 2.3.3 ***
Look at the General changes file for more encompassing on
the changes that have taken place in 2.3.3. This file has
Reworked wxConfig class interface.
Reworked wxDynamicLibary class for loading classes (particularly
-wxWindows classes) from dynamic libraries.
+wxWidgets classes) from dynamic libraries.
Removed wxObjectStream class.
Further improvements to wxFileName class.
-*** wxWindows 2.3.2 ***
+*** wxWidgets 2.3.2 ***
Addition of wxFileName class to handler DOS, Unix, Mac and VMS filenames
and paths in a platform independent way.
Addition of a wxPopupWindow class to imitate temporary windows such
as those used combo boxes or in tool tips.
-Addition of wxToggleButton which was missing in wxWindows 2.2.
+Addition of wxToggleButton which was missing in wxWidgets 2.2.
Support for virtual lists in wxListCtrl.
Improved wxSizer-based layout system for better support for dynamic
layout.
-*** wxWindows 2.3.0 ***
+*** wxWidgets 2.3.0 ***
scaling for map modes other than wxMM_TEXT works correctly (Derry Bryson)
-*** wxWindows 2.2.6 ***
+*** wxWidgets 2.2.6 ***
wxGauge now supports wxGA_VERTICAL (Shane Forsythe)
-*** 29th January 2001: wxWindows 2.2.5 released ***
+*** 29th January 2001: wxWidgets 2.2.5 released ***
Synchronized with wxMSW 2.2.5, include macros
for upwards 2.4.0 compatibility.
Fixed compilation with --enable-no_rtti/no_exceptions
with older egcs.
-*** 15th January 2001: wxWindows 2.2.4 released ***
+*** 15th January 2001: wxWidgets 2.2.4 released ***
Corrected wxYield() to handle recursive calls
more gracefully (and with a warning in debug mode).
Synchronized release with wxMSW again.
-*** 3rd November: wxWindows 2.2.3 released ***
+*** 3rd November: wxWidgets 2.2.3 released ***
Fixed bugs in HTTP code.
Linux and FreeBSD default to using GS fonts (and not
Adobe fonts).
-*** 20th September: wxWindows 2.2.2 released ***
+*** 20th September: wxWidgets 2.2.2 released ***
Fixed wxSizer bug that made items with option
flags greater than 1 report a wrong size.
Other minor fixes.
-*** 20th August 2000: wxWindows 2.2.1 released ***
+*** 20th August 2000: wxWidgets 2.2.1 released ***
Minor build fixes.
Minor wxCommandLineParser changes.
-*** 10th July 2000: wxWindows 2.2.0 released ***
+*** 10th July 2000: wxWidgets 2.2.0 released ***
Added code for writing BMP images.
Bug-fixes.
-*** 4th June 2000: wxWindows pre-2.2 release ***
+*** 4th June 2000: wxWidgets pre-2.2 release ***
Complete freeze now. Only vital bug-fixes allowed.
MANY bugfixes.
-*** 22th March 2000: wxWindows 2.1.15 released ***
+*** 22th March 2000: wxWidgets 2.1.15 released ***
Build fix. RPMs no longer require GTK's include files.
An extra library for the OpenGl class now gets built
-*** 19th March 2000: wxWindows 2.1.14 released ***
+*** 19th March 2000: wxWidgets 2.1.14 released ***
An extra library for the OpenGl class now gets built
and installed. There is also an extra RPM for this
The L-GPL iODBC library must now be enables explicitly so as
to not mislead people into reading the license wrong.
-*** 24th January '2000: wxWindows 2.1.13 released ***
+*** 24th January '2000: wxWidgets 2.1.13 released ***
Corrections to TAB handling in notebooks.
Build-fixes for various platforms and compilers.
-*** 6th January '2000: wxWindows 2.1.12 released ***
+*** 6th January '2000: wxWidgets 2.1.12 released ***
Who has a BigEndian computer (e.g. Sparc or PowerPC) that runs a 15
and/or 16 bit colour mode? I need this for testing purposes, i.e. this
Began work on a new dialog and resource editor (wxDesigner).
-*** 7st November '99: wxWindows 2.1.11 released ***
+*** 7st November '99: wxWidgets 2.1.11 released ***
There is still an unresolved problem with bitmap to image
conversion on big-endian architectures (such as Solaris),
Enlightenment has struck the majority of the developers and
they have chosen to use the Linux kernel numbering scheme
-for wxWindows from now on. This means that the next stable
-release will be called wxWindows 2.2.X, development snapshots
+for wxWidgets from now on. This means that the next stable
+release will be called wxWidgets 2.2.X, development snapshots
will be called 2.1.X.
A lot of discussion has been wasted on how to maintain a
once released stable version. It was almost universally
agreed that only a commercial entity will have the motivation
-($$$) to do that - so far there is no wxWindows Inc.
+($$$) to do that - so far there is no wxWidgets Inc.
Support for GTK 1.0 has been dropped. This version has
been tested with GTK 1.2.3 and GTK 1.2.6 - it might
with immediate success. Actually, when using GNU compilers,
your chances are quite good.
-My rewrite of the wxWindows underlying GTK widget
+My rewrite of the wxWidgets underlying GTK widget
has turned scrolling including subwindows from barely
functional to pretty and fast. I also added scrolling
of foreign windows to wxScrolledWindow.
Several printing things fixed. More work needs to be done
here..
-HTML widget and the wxWindows' help system based upon
+HTML widget and the wxWidgets' help system based upon
it have been reorganized and improved for easier use
from Python and C++. Also HTML printing has been added.
Michael is writing a complete rewrite of the antiquated
wxGrid. This is still work-in-progress and might not make
-it into wxWindows 2.2, we'll see. Help would be welcome
+it into wxWidgets 2.2, we'll see. Help would be welcome
to make that happen.
Made wxMenu code lose less memory, also added wxMenu::Delete().
Added code to send wxActivateEvent to MDI windows.
-Vadim added configure things to compile wxWindows without any
+Vadim added configure things to compile wxWidgets without any
GUI library. This is probably work in progress. He'll also add
a wxFontEnumerator class and has enhanced wxFont to make use
of char-encodings.
another cursor misbehaviour.
Updated many parts of the documentation to reflect changes
-in wxWindows 2.1, wxPython and more exact description of
+in wxWidgets 2.1, wxPython and more exact description of
cross-platform issues as well as platform differences.
Many other fixes, mainly by others...
handling and scroll event intercepting from wxScrolledWindow.
By and large much of the code has stabilized and won't be much
-*** different in the final wxWindows 2.1 release. Please test as ***
+*** different in the final wxWidgets 2.1 release. Please test as ***
much as you can.
The next release will have a new build system.
to call usleep()) in idle time - giving more CPU slices to
the application if desired.
-wxGLCanvas (the OpenGl for wxWindows) now accepts keyboard input.
+wxGLCanvas (the OpenGl for wxWidgets) now accepts keyboard input.
The usual number of compile and bug fixes from all involved.
12th April '99: First wxGTK 2.1 snapshot released
-This is the first developers' version of wxWindows 2.1 for GTK. It's main
+This is the first developers' version of wxWidgets 2.1 for GTK. It's main
new feature is that it supports GTK 1.2 (as opposed to GTK 1.0) which
will make development within the GNOME environment a lot easier.
-*** 5th March '99: wxWindows 2.0 released ***
+*** 5th March '99: wxWidgets 2.0 released ***
-This is the final version of wxWindows 2.0 for GTK. The versions for
+This is the final version of wxWidgets 2.0 for GTK. The versions for
Windows and Motif (and also this version) are available form Julian Smart's
site. The Mac version is still under development.
-*** 19th February '99: wxWindows 2.0 beta 5 ***
+*** 19th February '99: wxWidgets 2.0 beta 5 ***
This is the fifth beta release and it contains mostly bug fixes and
-*** 12th February '99: wxWindows 2.0 beta 4 ***
+*** 12th February '99: wxWidgets 2.0 beta 4 ***
This is the fourth beta release and it contains mostly bug fixes and
-*** 29th January '99: wxWindows 2.0 beta 3 ***
+*** 29th January '99: wxWidgets 2.0 beta 3 ***
This is the third beta release and it contains mostly bug fixes.
it Drag'n'Drop. This is mostly due to the fact that DnD in
GTK 1.0 is hardly usable and much different from GTK 1.2 which means that
we have to design a common API for Windows, GTK 1.0 and GTK 1.2. Although
-we are trying to prevent that, it is possible that wxWindows 2.0 (being
+we are trying to prevent that, it is possible that wxWidgets 2.0 (being
based on GTK 1.0) will not have proper DnD support.
The major changes are that tool tips have been added, threads have been completely
-*** 6th January '99: wxWindows 2.0 beta 2 ***
+*** 6th January '99: wxWidgets 2.0 beta 2 ***
This is the second beta release and contains it mostly build and
-*** 20th December '98: wxWindows 2.0 beta 1 ***
+*** 20th December '98: wxWidgets 2.0 beta 1 ***
This is the first beta release and we have used the time before
We changed the name of the shared library to include the version of
the GTK used so that no conflicts emerge with simultaneous
-versions of wxWindows for GTK 1.0 and for GTK 1.2 and so on.
+versions of wxWidgets for GTK 1.0 and for GTK 1.2 and so on.
As you can see, we have not moved to GTK 1.1.X as the different
development versions are too different and buggy to be useful. We'll
Linux-x86 and egcs 1.1 on Linux-Alpha and egcs 1.0 on Sparc. This isn't
as easy as it sounds...
-Available form this site are the Python bindings of wxWindows.
+Available form this site are the Python bindings of wxWidgets.
Thanks to Robin Dunn for this tremendous contribution.
Tkinter is dead, Java is dead, wxPython rules! That's all there is to say.
constructors.
As the number of users and the number of test programs and samples
-is steadily rising the core classes of wxWindows for MSW and GTK 1.0
+is steadily rising the core classes of wxWidgets for MSW and GTK 1.0
can be considered to be very stable if not outright bug-free. I haven't
-seen a crash for weeks now and wxWindows' internal debug features also
+seen a crash for weeks now and wxWidgets' internal debug features also
have improved every week, making stepping-through with a debugger almost
completely unnecessary as the library reports possible errors itself
(when in debug mode).
-wxWindows 2.5 for GTK installation
+wxWidgets 2.5 for GTK installation
----------------------------------
IMPORTANT NOTE:
mailing wxwin-users or the author. Preferably, try to fix the
problem first and then send a patch to the author.
- When sending bug reports tell us what version of wxWindows you are
+ When sending bug reports tell us what version of wxWidgets you are
using (including the beta) and what compiler on what system. One
example: wxGTK 2.4.0, gcc 2.95.4, Redhat 6.2
* The simplest case
-------------------
-If you compile wxWindows on Linux for the first time and don't like to read
+If you compile wxWidgets on Linux for the first time and don't like to read
install instructions just do (in the base dir):
> ./configure --with-gtk
> ldconfig
> exit
-If you want to remove wxWindows on Unix you can do this:
+If you want to remove wxWidgets on Unix you can do this:
> su <type root password>
> make uninstall
* The expert case
-----------------
-If you want to do some more serious cross-platform programming with wxWindows,
+If you want to do some more serious cross-platform programming with wxWidgets,
such as for GTK and Motif, you can now build two complete libraries and use
them concurrently. For this end, you have to create a directory for each build
-of wxWindows - you may also want to create different versions of wxWindows
+of wxWidgets - you may also want to create different versions of wxWidgets
and test them concurrently. Most typically, this would be a version configured
with --enable-debug and one without. Note, that only one build can
currently be installed, so you'd have to use local version of the library for
they were installed in a non default location.
You get errors from make: please use GNU make instead of the native make
-program. Currently wxWindows can be built only with GNU make, BSD make and
+program. Currently wxWidgets can be built only with GNU make, BSD make and
Solaris make. Other versions might work or not (any which don't have VPATH
support definitely won't).
* General
---------
-The Unix variants of wxWindows use GNU configure. If you have problems with
+The Unix variants of wxWidgets use GNU configure. If you have problems with
your make use GNU make instead.
If you have general problems with installation, read my homepage at
* GUI libraries
---------------
-wxWindows/GTK requires the GTK+ library to be installed on your system. It has
+wxWidgets/GTK requires the GTK+ library to be installed on your system. It has
to be a stable version, preferably version 1.2.10 (at least 1.2.3 is required,
1.2.7 is strongly recommended).
* Additional libraries
----------------------
-wxWindows/Gtk requires a thread library and X libraries known to work with
+wxWidgets/Gtk requires a thread library and X libraries known to work with
threads. This is the case on all commercial Unix-Variants and all
Linux-Versions that are based on glibc 2 except RedHat 5.0 which is broken in
many aspects. As of writing this, virtually all Linux distributions have
Please send comments and question about the OS/2 installation
to Stefan Neis <Stefan.Neis@t-online.de> and patches to
-the wxWindows mailing list.
+the wxWidgets mailing list.
In the following list, the version numbers indicate the configuration that
was actually used by myself, newer version should cause no problems and
./configure --help
-It is recommended to build wxWindows in another directory (maybe a
-subdirectory of your wxWindows installation) as this allows you to
+It is recommended to build wxWidgets in another directory (maybe a
+subdirectory of your wxWidgets installation) as this allows you to
have multiple configurations (for example, debug and release or GTK
and Motif) simultaneously.
--disable-shared Do not create shared libraries, but
build static libraries instead.
- --enable-monolithic Build wxWindows as single library instead
+ --enable-monolithic Build wxWidgets as single library instead
of as several smaller libraries (which is
- the default since wxWindows 2.5.0).
+ the default since wxWidgets 2.5.0).
--disable-optimise Do not optimise the code. Can
sometimes be useful for debugging
such as gdb (or its many frontends).
--enable-debug_flag Define __DEBUG__ and __WXDEBUG__ when
- compiling. This enable wxWindows' very
+ compiling. This enable wxWidgets' very
useful internal debugging tricks (such
as automatically reporting illegal calls)
to work. Note that program and library
When producing an executable that is linked statically with wxGTK
you'll be surprised at its immense size. This can sometimes be
-drastically reduced by removing features from wxWindows that
+drastically reduced by removing features from wxWidgets that
are not used in your program. The most relevant such features
are
--with-odbc Enables ODBC code. This is disabled
by default because iODBC is under the
L-GPL license which is less liberal than
- wxWindows license.
+ wxWidgets license.
--without-libpng Disables PNG image format code.
make install
-You can remove any traces of wxWindows by typing
+You can remove any traces of wxWidgets by typing
make uninstall
This is certain to become the standard way unless we decide
to stick to tmake.
-If your application uses only some of wxWindows libraries, you can
+If your application uses only some of wxWidgets libraries, you can
specify required libraries when running wx-config. For example,
`wx-config --libs=html,core` will only output link command to link
with libraries required by core GUI classes and wxHTML classes. See
the manual for more information on the libraries.
2) The other way creates a project within the source code
-directories of wxWindows. For this endeavour, you'll need
+directories of wxWidgets. For this endeavour, you'll need
GNU autoconf version 2.14 and add an entry to your Makefile.in
to the bottom of the configure.in script and run autoconf
and configure before you can type make.
-wxWindows Library License, Version 3
+wxWidgets Library License, Version 3
====================================
Copyright (C) 1998 Julian Smart, Robert Roebling et al.
1. As a special exception, the copyright holders of this library give
permission for additional uses of the text contained in this release of
- the library as licensed under the wxWindows Library License, applying
+ the library as licensed under the wxWidgets Library License, applying
either version 3 of the License, or (at your option) any later version of
the License as published by the copyright holders of version 3 of the
License document.
- Welcome to wxWindows/Gtk 2.5
+ Welcome to wxWidgets/Gtk 2.5
You have downloaded version 2.5 of the GTK port of the
-wxWindows GUI library.
+wxWidgets GUI library.
-wxWindows no longer supports GTK 1.0 (as did some early
+wxWidgets no longer supports GTK 1.0 (as did some early
snapshots) so that you will need GTK 1.2 when using it.
GTK 1.2.6 or above is recommended although some programs
will work with GTK 1.2.3 onwards. There is now support
for GTK 2.0.
-More info about the wxWindows project (including the
+More info about the wxWidgets project (including the
Windows, X11/Motif and other ports) can be found at the main
-wxWindows homepage at:
+wxWidgets homepage at:
- http://www.wxwindows.org
+ http://www.wxwidgets.org
Information on how to install can be found in the file
INSTALL.txt, but if you cannot wait, this should work on
switch was used or if shared libraries are not supported at all
on your platform which is quite unlikely) and
libwx_gtk-2.2.so.0.0.0 (shared) so that once a binary
-incompatible version of wxWindows/Gtk comes out we'll augment
+incompatible version of wxWidgets/Gtk comes out we'll augment
the library version number to avoid linking problems.
Please send problems concerning installation, feature requests,
-bug reports or comments to the wxWindows users list. Information
+bug reports or comments to the wxWidgets users list. Information
on how to subscribe is available from my homepage.
Do NOT send any comments directly to me.
-wxWindows/Gtk doesn't come with any guarantee whatsoever. It
+wxWidgets/Gtk doesn't come with any guarantee whatsoever. It
might crash your harddisk or destroy your monitor. It doesn't
claim to be suitable for any special or general purpose.
<HTML>
<HEAD>
-<TITLE>wxWindows Documentation</TITLE>
+<TITLE>wxWidgets Documentation</TITLE>
</HEAD>
<IMG src="logo.gif" align=right hspace=10 vspace=0>
-<b>Welcome to wxWindows 2, the première cross-platform GUI C++ framework.</b><P>
+<b>Welcome to wxWidgets 2, the première cross-platform GUI C++ framework.</b><P>
This is an index of
the plain text, HTML, Windows Help and Acrobat documentation: availability depends on what you've
-downloaded from the <a href="http://www.wxwindows.org">wxWindows Web site</a>.<br clear=all><P>
+downloaded from the <a href="http://www.wxwindows.org">wxWidgets Web site</a>.<br clear=all><P>
<CENTER>
<FONT size=-1>
<P>
-Unless you installed a binary version of wxWindows using RPMs,
-you will probably have to compile the wxWindows library first.
+Unless you installed a binary version of wxWidgets using RPMs,
+you will probably have to compile the wxWidgets library first.
Please read the platform-specific readme.txt and install.txt
for how to do this.
<li><a href="faq.htm"><B>FAQ</B></a>:
<ul>
<li><a href="faqgen.htm">General questions</a>
- <li><a href="faqgtk.htm">wxWindows 2 for GTK+</a>
- <li><a href="faqmsw.htm">wxWindows 2 for Windows</a>
- <li><a href="faqmot.htm">wxWindows 2 for Motif</a>
- <li><a href="faqx11.htm">wxWindows 2 for X11</a>
- <li><a href="faqmac.htm">wxWindows 2 for Mac</a>
+ <li><a href="faqgtk.htm">wxWidgets 2 for GTK+</a>
+ <li><a href="faqmsw.htm">wxWidgets 2 for Windows</a>
+ <li><a href="faqmot.htm">wxWidgets 2 for Motif</a>
+ <li><a href="faqx11.htm">wxWidgets 2 for X11</a>
+ <li><a href="faqmac.htm">wxWidgets 2 for Mac</a>
</ul>
<li>ToDo: <a href="../todo.txt"><b>General ToDo</b></a>,
<a href="../gtk/todo.txt">wxGTK</a>,
<a href="../motif/todo.txt">wxMotif</a>,
<a href="../msw/todo.txt">wxMSW</a>,
<a href="../mac/todo.txt">wxMac</a>
-<li>List of <a href="../symbols.txt">preprocessor symbols</a> used in wxWindows
+<li>List of <a href="../symbols.txt">preprocessor symbols</a> used in wxWidgets
</ul>
Further platform-specific notes:
<tr>
<td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif">
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
-<b><a name="manuals">wxWindows manuals</a></b>
+<b><a name="manuals">wxWidgets manuals</a></b>
</font>
</td>
</tr>
application, either compiling it from utils/helpview in the distribution,
or downloading a binary, for example from <a href="http://www.storylinescentral.com/helpview.htm">here</a>.<P>
-See also the <a href="../pdf/wxTutorial.pdf">wxWindows Tutorial</a>
+See also the <a href="../pdf/wxTutorial.pdf">wxWidgets Tutorial</a>
by Franky Braem, in PDF format.<P>
<P>
<tr>
<td align=center>
-<a href="wx/wx.htm">wxWindows Reference</a>
+<a href="wx/wx.htm">wxWidgets Reference</a>
</td>
<td align=center>
-<a href="../winhelp/wx.hlp">wxWindows Reference</a>
+<a href="../winhelp/wx.hlp">wxWidgets Reference</a>
</td>
<td align=center>
-<a href="../htmlhelp/wx.chm">wxWindows Reference</a>
+<a href="../htmlhelp/wx.chm">wxWidgets Reference</a>
</td>
<td align=center>
-<a href="../htb/wx.htb">wxWindows Reference</a>
+<a href="../htb/wx.htb">wxWidgets Reference</a>
</td>
<td align=center>
-<a href="../pdf/wx.pdf">wxWindows Reference</a>
+<a href="../pdf/wx.pdf">wxWidgets Reference</a>
</td>
</tr>
<li><a href="../tech/index.txt">Index of technical notes</a>
<li><a href="../tech/">Technical notes</a>
<li><a href="platform.htm">Platforms supported</a>
-<li><a href="i18n.htm">Languages supported by wxWindows</a>
+<li><a href="i18n.htm">Languages supported by wxWidgets</a>
</ul>
<P>
<P>
-Each of the following samples demonstrates one or more aspect of wxWindows.<P>
+Each of the following samples demonstrates one or more aspect of wxWidgets.<P>
<ul>
<li><a href="../../samples/calendar">artprov</a>: shows how you can customize the look of standard
-wxWindows dialogs by replacing default bitmaps/icons with your own versions.
+wxWidgets dialogs by replacing default bitmaps/icons with your own versions.
<li><a href="../../samples/calendar">calendar</a>: a sample to test the wxCalendarCtrl class.
<li><a href="../../samples/caret">caret</a>: a sample to test the wxCaret class.
<li><a href="../../samples/checklst">checklst</a>: demonstrates wxCheckListBox on
<li><a href="../../samples/config">config</a>: demonstrates use of wxConfig, which
defaults to wxRegConfig on WIN32 (optionally wxIniConfig), and wxFileConfig on other platforms.
<li><a href="../../samples/console">console</a>: demonstrates a console application using
-console-mode (no-GUI) compilation of wxWindows.
+console-mode (no-GUI) compilation of wxWidgets.
<li><a href="../../samples/controls">controls</a>: sample showing a variety of controls, including
wxNotebook.
<li><a href="../../samples/db">db</a>: wxDB ODBC sample.
<li><a href="../../samples/html/zip">zip</a>: shows how help files can be packaged in zip archives.
</ul>
<li><a href="../../samples/image">image</a>: shows off the cross-platform wxImage class.
-<li><a href="../../samples/internat">internat</a>: use of wxWindows' internationalization support.
+<li><a href="../../samples/internat">internat</a>: use of wxWidgets' internationalization support.
<li><a href="../../samples/joytest">joytest</a>: tests the wxJoystick class (currently Windows and GTK only).
<li><a href="../../samples/keyboard">keyboard</a>: tests keyboard support.
<li><a href="../../samples/layout">layout</a>: shows the constraint layout system in action.
scheme is used whereby child windows have full sizing and moving rights within the main
window. On other platforms, tabbed windows are used, where the children are always maximized.
<li><a href="../../samples/memcheck">memcheck</a>: demonstrates the memory checking/debugging facilities.
-<li><a href="../../samples/mfc">mfc</a>: shows how to use MFC and wxWindows code in the same application (Windows only).
-To compile this, you must edit include/wx/wxprec.h, comment out the windows.h inclusion, and recompile wxWindows.
+<li><a href="../../samples/mfc">mfc</a>: shows how to use MFC and wxWidgets code in the same application (Windows only).
+To compile this, you must edit include/wx/wxprec.h, comment out the windows.h inclusion, and recompile wxWidgets.
<li><a href="../../samples/minifram">minifram</a>: demonstrates a frame with a small title bar. On
platforms that don't support it, a normal-sized title bar is displayed.
<li><a href="../../samples/minimal">minimal</a>: just shows a frame, a menubar, and a statusbar. About as
-small a wxWindows application as you can get.
+small a wxWidgets application as you can get.
<li><a href="../../samples/mobile">mobile</a>: mini applications for embedded platforms.
-<li><a href="../../samples/nativdlg">nativdlg</a>: shows how wxWindows can load a standard Windows
-dialog resource, translating the controls into wxWindows controls (Windows only).
+<li><a href="../../samples/nativdlg">nativdlg</a>: shows how wxWidgets can load a standard Windows
+dialog resource, translating the controls into wxWidgets controls (Windows only).
<li><a href="../../samples/notebook">notebook</a>: shows the wxNotebook (tabbed window) control.
<li><a href="../../samples/oleauto">oleauto</a>: a little OLE automation controller (Windows only; requires
Excel to be present).
The following are deprecated samples.
<ul>
-<li><a href="../../contrib/deprecated/samples/resource">resource</a>: shows how to use old-style wxWindows resources (.wxr files).
+<li><a href="../../contrib/deprecated/samples/resource">resource</a>: shows how to use old-style wxWidgets resources (.wxr files).
<li><a href="../../contrib/deprecated/samples/proplist">proplist</a>: demonstrates the property list classes (a VB-style property editor).
<li><a href="../../contrib/deprecated/samples/treelay">treelay</a>: an algorithm for displaying tree hierarchies.
</ul>
<li><a href="../../demos/dbbrowse">dbbrowse</a>: ODBC database browser application.
<li><a href="../../demos/forty">forty</a>: a great little card game by Chris Breeze.
<li><a href="../../demos/fractal">fractal</a>: fractal mountains by Andrew Davison.
-<li><a href="../../demos/life">life</a>: the game of Life by J. H. Conway, implemented in wxWindows by Guillermo Rodriguez Garcia.
+<li><a href="../../demos/life">life</a>: the game of Life by J. H. Conway, implemented in wxWidgets by Guillermo Rodriguez Garcia.
<li><a href="../../demos/poem">poem</a>: a little poetry display program.
</ul>
<HTML>
<HEAD>
-<TITLE>Welcome to wxWindows 2</TITLE>
+<TITLE>Welcome to wxWidgets</TITLE>
</HEAD>
<tr>
<td bgcolor="#660000">
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
-Welcome to wxWindows 2
+Welcome to wxWidgets
</font>
</td>
</tr>
<P>
-Welcome to wxWindows 2, the premiere cross-platform GUI C++ framework.<P>
+Welcome to wxWidgets, the premiere cross-platform GUI C++ framework.<P>
Please click on <a href="html/index.htm">docs/html/index.htm</a> to view the main document index.<P>
\section{\class{wxAccessible}}\label{wxaccessible}
-The wxAccessible class allows wxWindows applications, and
-wxWindows itself, to return extended information about user interface elements
+The wxAccessible class allows wxWidgets applications, and
+wxWidgets itself, to return extended information about user interface elements
to client applications such as screen readers. This is the
-main way in which wxWindows implements accessibility features.
+main way in which wxWidgets implements accessibility features.
At present, only Microsoft Active Accessibility is supported
by this class.
For details on the semantics of functions and types, please refer to the
Microsoft Active Accessibility 1.2 documentation.
-This class is compiled into wxWindows only if the wxUSE\_ACCESSIBILITY setup
+This class is compiled into wxWidgets only if the wxUSE\_ACCESSIBILITY setup
symbol is set to 1.
\wxheading{Derived from}
\end{itemize}
You should use the macro IMPLEMENT\_APP(appClass) in your application implementation
-file to tell wxWindows how to create an instance of your application class.
+file to tell wxWidgets how to create an instance of your application class.
Use DECLARE\_APP(appClass) in a header file if you want the wxGetApp function (which returns
a reference to your application object) to be visible to other files.
\wxheading{Remarks}
-wxWindows sets this to a reasonable default before
+wxWidgets sets this to a reasonable default before
calling \helpref{wxApp::OnInit}{wxapponinit}, but the application can reset it at will.
\func{int}{MainLoop}{\void}
-Called by wxWindows on creation of the application. Override this if you wish
+Called by wxWidgets on creation of the application. Override this if you wish
to provide your own (environment-dependent) main loop.
\wxheading{Return value}
Override this member function for any processing which needs to be
done as the application is about to exit. OnExit is called after
destroying all application windows and controls, but before
-wxWindows cleanup. Note that it is not called at all if
+wxWidgets cleanup. Note that it is not called at all if
\helpref{OnInit}{wxapponinit} failed.
The return value of this function is currently ignored, return the same value
%%since this forwards OnIdle events to windows and also performs garbage collection for
%%windows whose destruction has been delayed.
%%
-%%wxWindows' strategy for OnIdle processing is as follows. After pending user interface events for an
-%%application have all been processed, wxWindows sends an OnIdle event to the application object. wxApp::OnIdle itself
+%%wxWidgets' strategy for OnIdle processing is as follows. After pending user interface events for an
+%%application have all been processed, wxWidgets sends an OnIdle event to the application object. wxApp::OnIdle itself
%%sends an OnIdle event to each application window, allowing windows to do idle processing such as updating
%%their appearance. If either wxApp::OnIdle or a window OnIdle function requested more time, by
-%%calling \helpref{wxIdleEvent::RequestMore}{wxidleeventrequestmore}, wxWindows will send another OnIdle
+%%calling \helpref{wxIdleEvent::RequestMore}{wxidleeventrequestmore}, wxWidgets will send another OnIdle
%%event to the application object. This will occur in a loop until either a user event is found to be
%%pending, or OnIdle requests no more time. Then all pending user events are processed until the system
%%goes idle again, when OnIdle is called, and so on.
that the function returns \true.
Notice that if you want to to use the command line processing provided by
-wxWindows you have to call the base class version in the derived class
+wxWidgets you have to call the base class version in the derived class
OnInit().
Return \true to continue processing, \false to exit the application
\func{virtual int}{OnRun}{\void}
-This virtual function is where the execution of a program written in wxWindows
+This virtual function is where the execution of a program written in wxWidgets
starts. The default implementation just enters the main loop and starts
handling the events until it terminates, either because
\helpref{ExitMainLoop}{wxappexitmainloop} has been explicitly called or because
Windows-only function for processing a message. This function
is called from the main message loop, checking for windows that
may wish to process it. The function returns true if the message
-was processed, false otherwise. If you use wxWindows with another class
+was processed, false otherwise. If you use wxWidgets with another class
library with its own message loop, you should make sure that this
-function is called to allow wxWindows to receive messages. For example,
+function is called to allow wxWidgets to receive messages. For example,
to allow co-existence with the Microsoft Foundation Classes, override
the PreTranslateMessage function:
\begin{verbatim}
-// Provide wxWindows message loop compatibility
+// Provide wxWidgets message loop compatibility
BOOL CTheApp::PreTranslateMessage(MSG *msg)
{
if (wxTheApp && wxTheApp->ProcessMessage((WXMSW *)msg))
Sends idle events to a window and its children.
-Please note that this function is internal to wxWindows and shouldn't be used
+Please note that this function is internal to wxWidgets and shouldn't be used
by user code.
\wxheading{Remarks}
Sets the name of the application. The name may be used in dialogs
(for example by the document/view framework). A default name is set by
-wxWindows.
+wxWidgets.
\wxheading{See also}
\func{void}{SetTopWindow}{\param{wxWindow* }{window}}
Sets the `top' window. You can call this from within \helpref{wxApp::OnInit}{wxapponinit} to
-let wxWindows know which is the main window. You don't have to set the top window;
+let wxWidgets know which is the main window. You don't have to set the top window;
it is only a convenience so that (for example) certain dialogs without parents can use a
specific window as the top window. If no top window is specified by the application,
-wxWindows just uses the first frame or dialog in its top-level window list, when it
+wxWidgets just uses the first frame or dialog in its top-level window list, when it
needs to use the top window.
\wxheading{Parameters}
Sets the name of application's vendor. The name will be used
in registry access. A default name is set by
-wxWindows.
+wxWidgets.
\wxheading{See also}
you may find some useful hints about optimizing wxArray memory usage. As for executable size, all
wxArray functions are inline, so they do not take {\it any space at all}.
-wxWindows has three different kinds of array. All of them derive from
+wxWidgets has three different kinds of array. All of them derive from
wxBaseArray class which works with untyped data and can not be used directly.
The standard macros WX\_DEFINE\_ARRAY(), WX\_DEFINE\_SORTED\_ARRAY() and
WX\_DEFINE\_OBJARRAY() are used to define a new class deriving from it. The
all of wxArray's functions are inline, so it costs strictly nothing to define as
many array types as you want (either in terms of the executable size or the
speed) as long as at least one of them is defined and this is always the case
-because wxArrays are used by wxWindows internally. This class has one serious
+because wxArrays are used by wxWidgets internally. This class has one serious
limitation: it can only be used for storing integral types (bool, char, short,
int, long and their unsigned variants) or pointers (of any kind). An attempt
to use with objects of sizeof() greater than sizeof(long) will provoke a
runtime assertion failure, however declaring a wxArray of floats will not (on
the machines where sizeof(float) <= sizeof(long)), yet it will {\bf not} work,
please use wxObjArray for storing floats and doubles (NB: a more efficient
-wxArrayDouble class is scheduled for the next release of wxWindows).
+wxArrayDouble class is scheduled for the next release of wxWidgets).
wxSortedArray is a wxArray variant which should be used when searching in the
array is a frequently used operation. It requires you to define an additional
\func{}{WX\_DEFINE\_USER\_EXPORTED\_ARRAY}{\param{}{T}, \param{}{name}, \param{}{exportspec}}
This macro defines a new array class named {\it name} and containing the
-elements of type {\it T}. The second form is used when compiling wxWindows as
+elements of type {\it T}. The second form is used when compiling wxWidgets as
a DLL under Windows and array needs to be visible outside the DLL. The third is
needed for exporting an array from a user DLL.
WX_DEFINE_ARRAY(MyClass *, wxArrayOfMyClass);
\end{verbatim}
-Note that wxWindows predefines the following standard array classes: wxArrayInt,
+Note that wxWidgets predefines the following standard array classes: wxArrayInt,
wxArrayLong and wxArrayPtrVoid.
\membersection{WX\_DEFINE\_SORTED\_ARRAY}\label{wxdefinesortedarray}
\func{}{WX\_DEFINE\_SORTED\_USER\_EXPORTED\_ARRAY}{\param{}{T}, \param{}{name}}
This macro defines a new sorted array class named {\it name} and containing
-the elements of type {\it T}. The second form is used when compiling wxWindows as
+the elements of type {\it T}. The second form is used when compiling wxWidgets as
a DLL under Windows and array needs to be visible outside the DLL. The third is
needed for exporting an array from a user DLL.
\func{}{WX\_DECLARE\_USER\_EXPORTED\_OBJARRAY}{\param{}{T}, \param{}{name}}
This macro declares a new object array class named {\it name} and containing
-the elements of type {\it T}. The second form is used when compiling wxWindows as
+the elements of type {\it T}. The second form is used when compiling wxWidgets as
a DLL under Windows and array needs to be visible outside the DLL. The third is
needed for exporting an array from a user DLL.
\section{\class{wxArtProvider}}\label{wxartprovider}
-wxArtProvider class is used to customize the look of wxWindows application.
-When wxWindows need to display an icon or a bitmap (e.g. in the standard file
+wxArtProvider class is used to customize the look of wxWidgets application.
+When wxWidgets need to display an icon or a bitmap (e.g. in the standard file
dialog), it does not use hard-coded resource but asks wxArtProvider for it
instead. This way the users can plug in own wxArtProvider class and easily
replace standard art with his/her own version. It is easy thing to do: all
platform native icons as provided by
\helpref{wxArtProvider::GetBitmap}{wxartprovidergetbitmap} or
\helpref{wxArtProvider::GetIcon}{wxartprovidergeticon} (NB: this is not yet really
-possible as of wxWindows 2.3.3, the set of wxArtProvider bitmaps is too
+possible as of wxWidgets 2.3.3, the set of wxArtProvider bitmaps is too
small).
\membersection{Identifying art resources}
\wxheading{Remarks}
-A bitmap button can be supplied with a single bitmap, and wxWindows will draw
+A bitmap button can be supplied with a single bitmap, and wxWidgets will draw
all button states using this bitmap. If the application needs more control, additional bitmaps for
the selected state, unpressed focused state, and greyed-out state may be supplied.
\wxheading{Remarks}
-The {\it bitmap} parameter is normally the only bitmap you need to provide, and wxWindows will
+The {\it bitmap} parameter is normally the only bitmap you need to provide, and wxWidgets will
draw the button correctly in its different states. If you want more control, call
any of the functions \helpref{wxBitmapButton::SetBitmapSelected}{wxbitmapbuttonsetbitmapselected},\rtfsp
\helpref{wxBitmapButton::SetBitmapFocus}{wxbitmapbuttonsetbitmapfocus},\rtfsp
\twocolitem{\indexit{wxBITMAP\_TYPE\_RESOURCE}}{Load a Windows resource name.}
\end{twocollist}
-The validity of these flags depends on the platform and wxWindows configuration.
-If all possible wxWindows settings are used, the Windows platform supports BMP file, BMP resource,
+The validity of these flags depends on the platform and wxWidgets configuration.
+If all possible wxWidgets settings are used, the Windows platform supports BMP file, BMP resource,
XPM data, and XPM. Under wxGTK, the available formats are BMP file, XPM data, XPM file, and PNG file.
Under wxMotif, the available formats are XBM data, XBM file, XPM data, XPM file.
The sixth form constructs a new bitmap.
-The seventh form constructs a bitmap from pixmap (XPM) data, if wxWindows has been configured
+The seventh form constructs a bitmap from pixmap (XPM) data, if wxWidgets has been configured
to incorporate this feature.
To use this constructor, you must first include an XPM file. For
data be deleted.
If the application omits to delete the bitmap explicitly, the bitmap will be
-destroyed automatically by wxWindows when the application exits.
+destroyed automatically by wxWidgets when the application exits.
Do not delete a bitmap that is selected into a memory device context.
Deletes all bitmap handlers.
-This function is called by wxWindows on exit.
+This function is called by wxWidgets on exit.
\membersection{wxBitmap::ConvertToImage}\label{wxbitmapconverttoimage}
\func{static void}{InitStandardHandlers}{\void}
-Adds the standard bitmap format handlers, which, depending on wxWindows
+Adds the standard bitmap format handlers, which, depending on wxWidgets
configuration, can be handlers for Windows bitmap, Windows bitmap resource, and XPM.
-This function is called by wxWindows on startup.
+This function is called by wxWidgets on startup.
\wxheading{See also}
\twocolitem{{\bf wxBITMAP\_TYPE\_XPM}}{Load an XPM bitmap file.}
\end{twocollist}
-The validity of these flags depends on the platform and wxWindows configuration.
+The validity of these flags depends on the platform and wxWidgets configuration.
In addition, wxBitmap can read all formats that \helpref{wxImage}{wximage} can
(wxBITMAP\_TYPE\_JPEG, wxBITMAP\_TYPE\_PNG, wxBITMAP\_TYPE\_GIF, wxBITMAP\_TYPE\_PCX, wxBITMAP\_TYPE\_PNM).
\twocolitem{{\bf wxBITMAP\_TYPE\_XPM}}{Save an XPM bitmap file.}
\end{twocollist}
-The validity of these flags depends on the platform and wxWindows configuration.
+The validity of these flags depends on the platform and wxWidgets configuration.
In addition, wxBitmap can save all formats that \helpref{wxImage}{wximage} can
(wxBITMAP\_TYPE\_JPEG, wxBITMAP\_TYPE\_PNG).
\wxheading{Remarks}
-Depending on how wxWindows has been configured, not all formats may be available.
+Depending on how wxWidgets has been configured, not all formats may be available.
\wxheading{See also}
Returns the bitmap associated with the data object. You may wish to override
this method when offering data on-demand, but this is not required by
-wxWindows' internals. Use this method to get data in bitmap form from
+wxWidgets' internals. Use this method to get data in bitmap form from
the \helpref{wxClipboard}{wxclipboard}.
\membersection{wxBitmapDataObject::SetBitmap}\label{wxbitmapdataobjectsetbitmap}
\setheader{{\it CHAPTER \thechapter}}{}{}{}{}{{\it CHAPTER \thechapter}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
-\section{What is wxWindows?}
+\section{What is wxWidgets?}
-wxWindows is a C++ framework providing GUI (Graphical User
+wxWidgets is a C++ framework providing GUI (Graphical User
Interface) and other facilities on more than one platform. Version 2 currently
supports all desktop versions of MS Windows, Unix with GTK+, Unix with Motif,
and MacOS. An OS/2 port is in progress.
-wxWindows was originally developed at the Artificial Intelligence
+wxWidgets was originally developed at the Artificial Intelligence
Applications Institute, University of Edinburgh, for internal use,
and was first made publicly available in 1992.
Version 2 is a vastly improved version written and maintained by
Julian Smart, Robert Roebling, Vadim Zeitlin, Vaclav Slavik and many others.
This manual contains a class reference and topic overviews.
-For a selection of wxWindows tutorials, please see the documentation page on the \urlref{wxWindows web site}{http://www.wxwindows.org}.
+For a selection of wxWidgets tutorials, please see the documentation page on the \urlref{wxWidgets web site}{http://www.wxwidgets.org}.
Please note that in the following, ``MS Windows" often refers to all
platforms related to Microsoft Windows, including 16-bit and 32-bit
\section{Why another cross-platform development tool?}
-wxWindows was developed to provide a cheap and flexible way to maximize
+wxWidgets was developed to provide a cheap and flexible way to maximize
investment in GUI application development. While a number of commercial
class libraries already existed for cross-platform development,
none met all of the following criteria:
\item support for a wide range of compilers.
\end{enumerate}
-Since wxWindows was started, several other free or almost-free
+Since wxWidgets was started, several other free or almost-free
GUI frameworks have emerged. However, none has the range of
features, flexibility, documentation and the well-established
-development team that wxWindows has.
+development team that wxWidgets has.
-As open source software, wxWindows has benefited from comments,
+As open source software, wxWidgets has benefited from comments,
ideas, bug fixes, enhancements and the sheer enthusiasm of
-users. This gives wxWindows a certain advantage over its
+users. This gives wxWidgets a certain advantage over its
commercial competitors (and over free libraries without an
independent development team), plus a robustness against the
transience of one individual or company. This openness and
cannot be overstated, since GUI application development is very
time-consuming, and sustained popularity of particular GUIs
cannot be guaranteed. Code can very quickly become obsolete if
-it addresses the wrong platform or audience. wxWindows helps to
+it addresses the wrong platform or audience. wxWidgets helps to
insulate the programmer from these winds of change. Although
-wxWindows may not be suitable for every application (such as an
+wxWidgets may not be suitable for every application (such as an
OLE-intensive program), it provides access to most of the
functionality a GUI program normally requires, plus many extras
such as network programming, PostScript output, and HTML
rendering; and it can of course be extended as needs dictate.
As a bonus, it provides a far cleaner and easier programming
interface than the native APIs. Programmers may find it
-worthwhile to use wxWindows even if they are developing on only
+worthwhile to use wxWidgets even if they are developing on only
one platform.
-It is impossible to sum up the functionality of wxWindows in a few paragraphs, but
+It is impossible to sum up the functionality of wxWidgets in a few paragraphs, but
here are some of the benefits:
\begin{itemize}\itemsep=0pt
\end{itemize}
\end{comment}
-\section{wxWindows requirements}\label{requirements}
+\section{wxWidgets requirements}\label{requirements}
-To make use of wxWindows, you currently need one of the following setups.
+To make use of wxWidgets, you currently need one of the following setups.
(a) MS-Windows:
\item At least 60 MB of disk space.
\end{enumerate}
-\section{Availability and location of wxWindows}
+\section{Availability and location of wxWidgets}
-\winhelponly{wxWindows is available by anonymous FTP and World Wide Web
-from ftp://biolpc22.york.ac.uk/pub and/or http://www.wxwindows.org.}
-\winhelpignore{wxWindows is available by anonymous FTP and World Wide Web
+\winhelponly{wxWidgets is available by anonymous FTP and World Wide Web
+from ftp://biolpc22.york.ac.uk/pub and/or http://www.wxwidgets.org.}
+\winhelpignore{wxWidgets is available by anonymous FTP and World Wide Web
from \urlref{ftp://biolpc22.york.ac.uk/pub}{ftp://biolpc22.york.ac.uk/pub}
-and/or \urlref{http://www.wxwindows.org}{http://www.wxwindows.org}.}
+and/or \urlref{http://www.wxwidgets.org}{http://www.wxwidgets.org}.}
You can also buy a CD-ROM using the form on the Web site.
\section{Acknowledgements}
Thanks are due to AIAI for being willing to release the original version of
-wxWindows into the public domain, and to our patient partners.
+wxWidgets into the public domain, and to our patient partners.
-We would particularly like to thank the following for their contributions to wxWindows, and the many others who have been involved in
+We would particularly like to thank the following for their contributions to wxWidgets, and the many others who have been involved in
the project over the years. Apologies for any unintentional omissions from this list.
Yiorgos Adamopoulos, Jamshid Afshar, Alejandro Aguilar-Sierra, AIAI, Patrick Albert, Karsten Ballueder, Michael Bedward, Kai Bendorf, Yura Bidus, Keith
suitability of this software for any purpose. It is provided ``as is''
without express or implied warranty.}
-\chapter{Multi-platform development with wxWindows}\label{multiplat}
+\chapter{Multi-platform development with wxWidgets}\label{multiplat}
\setheader{{\it CHAPTER \thechapter}}{}{}{}{}{{\it CHAPTER \thechapter}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
-This chapter describes the practical details of using wxWindows. Please
+This chapter describes the practical details of using wxWidgets. Please
see the file install.txt for up-to-date installation instructions, and
changes.txt for differences between versions.
\section{Include files}
The main include file is {\tt "wx/wx.h"}; this includes the most commonly
-used modules of wxWindows.
+used modules of wxWidgets.
To save on compilation time, include only those header files relevant to the
source file. If you are using precompiled headers, you should include
the file to use for precompilation. Watcom C++ is automatic apart from the specification of
the .pch file. Watcom C++ is strange in requiring the precompiled header to be used only for
object files compiled in the same directory as that in which the precompiled header was created.
-Therefore, the wxWindows Watcom C++ makefiles go through hoops deleting and recreating
+Therefore, the wxWidgets Watcom C++ makefiles go through hoops deleting and recreating
a single precompiled header file for each module, thus preventing an accumulation of many
multi-megabyte .pch files.
\section{Libraries}
-Most ports of wxWindows can create either a static library or a shared
-library. wxWindows can also be built in multilib and monolithic variants.
+Most ports of wxWidgets can create either a static library or a shared
+library. wxWidgets can also be built in multilib and monolithic variants.
See the \helpref{libraries list}{librarieslist} for more
information on these.
\section{Configuration}
-When using project files and makefiles directly to build wxWindows,
+When using project files and makefiles directly to build wxWidgets,
options are configurable in the file
\rtfsp{\tt "wx/XXX/setup.h"} where XXX is the required platform (such as msw, motif, gtk, mac). Some
settings are a matter of taste, some help with platform-specific problems, and
others can be set to minimize the size of the library. Please see the setup.h file
and {\tt install.txt} files for details on configuration.
-When using the 'configure' script to configure wxWindows (on Unix and other platforms where
+When using the 'configure' script to configure wxWidgets (on Unix and other platforms where
configure is available), the corresponding setup.h files are generated automatically
along with suitable makefiles. When using the RPM packages
-for installing wxWindows on Linux, a correct setup.h is shipped in the package and
+for installing wxWidgets on Linux, a correct setup.h is shipped in the package and
this must not be changed.
\section{Makefiles}
-On Microsoft Windows, wxWindows has a different set of makefiles for each
+On Microsoft Windows, wxWidgets has a different set of makefiles for each
compiler, because each compiler's '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),
OpenWatcom C++ (.wat) and MinGW/Cygwin (.gcc). Makefiles are provided
-for the wxWindows library itself, samples, demos, and utilities.
+for the wxWidgets library itself, samples, demos, and utilities.
On Linux, Mac and OS/2, you use the 'configure' command to
generate the necessary makefiles. You should also use this method when
We also provide project files for some compilers, such as
Microsoft VC++. However, we recommend using makefiles
-to build the wxWindows library itself, because makefiles
+to build the wxWidgets library itself, because makefiles
can be more powerful and less manual intervention is required.
On Windows using a compiler other than MinGW/Cygwin, you would
-build the wxWindows library from the build/msw directory
+build the wxWidgets library from the build/msw directory
which contains the relevant makefiles.
On Windows using MinGW/Cygwin, and on Unix, MacOS X and OS/2, you invoke
-'configure' (found in the top-level of the wxWindows source hierarchy),
+'configure' (found in the top-level of the wxWidgets source hierarchy),
from within a suitable empty directory for containing makefiles, object files and
libraries.
\section{Windows-specific files}
-wxWindows application compilation under MS Windows requires at least two
+wxWidgets application compilation under MS Windows requires at least two
extra files, resource and module definition files.
\subsection{Resource file}\label{resources}
#include "wx/msw/wx.rc"
\end{verbatim}
-which includes essential internal wxWindows definitions. The resource script
+which includes essential internal wxWidgets definitions. The resource script
may also contain references to icons, cursors, etc., for example:
\begin{verbatim}
so programs that search your executable for icons (such
as the Program Manager) find your application icon first.}
-\section{Allocating and deleting wxWindows objects}
+\section{Allocating and deleting wxWidgets objects}
In general, classes derived from wxWindow must dynamically allocated
with {\it new} and deleted with {\it delete}. If you delete a window,
so you don't need to delete these descendants explicitly.
When deleting a frame or dialog, use {\bf Destroy} rather than {\bf delete} so
-that the wxWindows delayed deletion can take effect. This waits until idle time
+that the wxWidgets delayed deletion can take effect. This waits until idle time
(when all messages have been processed) to actually delete the window, to avoid
problems associated with the GUI sending events to deleted windows.
with delayed deletion.
If you decide to allocate a C++ array of objects (such as wxBitmap) that may
-be cleaned up by wxWindows, make sure you delete the array explicitly
-before wxWindows has a chance to do so on exit, since calling {\it delete} on
+be cleaned up by wxWidgets, make sure you delete the array explicitly
+before wxWidgets has a chance to do so on exit, since calling {\it delete} on
array members will cause memory problems.
wxColour can be created statically: it is not automatically cleaned
the basic C types are not defined the same on all platforms. This holds true
for both the length in bits of the standard types (such as int and long) as
well as their byte order, which might be little endian (typically
-on Intel computers) or big endian (typically on some Unix workstations). wxWindows
+on Intel computers) or big endian (typically on some Unix workstations). wxWidgets
defines types and macros that make it easy to write architecture independent
code. The types are:
\section{Conditional compilation}
-One of the purposes of wxWindows is to reduce the need for conditional
+One of the purposes of wxWidgets is to reduce the need for conditional
compilation in source code, which can be messy and confusing to follow.
However, sometimes it is necessary to incorporate platform-specific
features (such as metafile use under MS Windows). The symbols
\subsection{Templates}
-wxWindows does not use templates (except for some advanced features that
+wxWidgets does not use templates (except for some advanced features that
are switched off by default) since it is a notoriously unportable feature.
\subsection{RTTI}
-wxWindows does not use C++ run-time type information since wxWindows provides
+wxWidgets does not use C++ run-time type information since wxWidgets provides
its own run-time type information system, implemented using macros.
\subsection{Type of NULL}
\end{verbatim}
}%
-It is recommended to adhere to this in all code using wxWindows as
+It is recommended to adhere to this in all code using wxWidgets as
this make the code (a bit) more portable.
\subsection{Precompiled headers}
Some compilers, such as Borland C++ and Microsoft C++, support
precompiled headers. This can save a great deal of compiling time. The
recommended approach is to precompile {\tt "wx.h"}, using this
-precompiled header for compiling both wxWindows itself and any
-wxWindows applications. For Windows compilers, two dummy source files
+precompiled header for compiling both wxWidgets itself and any
+wxWidgets applications. For Windows compilers, two dummy source files
are provided (one for normal applications and one for creating DLLs)
to allow initial creation of the precompiled header.
is that to take advantage of the facility, you often need to include
more header files than would normally be the case. This means that
changing a header file will cause more recompilations (in the case of
-wxWindows, everything needs to be recompiled since everything includes {\tt "wx.h"}!)
+wxWidgets, everything needs to be recompiled since everything includes {\tt "wx.h"}!)
A related problem is that for compilers that don't have precompiled
headers, including a lot of header files slows down compilation
See also the File Functions section of the reference manual for
descriptions of miscellaneous file handling functions.
-\chapter{Utilities and libraries supplied with wxWindows}\label{utilities}
+\chapter{Utilities and libraries supplied with wxWidgets}\label{utilities}
\setheader{{\it CHAPTER \thechapter}}{}{}{}{}{{\it CHAPTER \thechapter}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
-In addition to the core wxWindows library, a number of further
+In addition to the core wxWidgets library, a number of further
libraries and utilities are supplied with each distribution.
Some are under the 'contrib' hierarchy which mirrors the
-structure of the main wxWindows hierarchy. See also the 'utils'
+structure of the main wxWidgets hierarchy. See also the 'utils'
hierarchy. The first place to look for documentation about
-these tools and libraries is under the wxWindows 'docs' hierarchy,
+these tools and libraries is under the wxWidgets 'docs' hierarchy,
for example {\tt docs/htmlhelp/fl.chm}.
For other user-contributed packages, please see the Contributions page
-on the \urlref{wxWindows Web site}{http://www.wxwindows.org}.
+on the \urlref{wxWidgets Web site}{http://www.wxwidgets.org}.
\begin{description}\itemsep=0pt
\item[{\bf Helpview}]
-Helpview is a program for displaying wxWindows HTML
-Help files. In many cases, you may wish to use the wxWindows HTML
+Helpview is a program for displaying wxWidgets HTML
+Help files. In many cases, you may wish to use the wxWidgets HTML
Help classes from within your application, but this provides a
handy stand-alone viewer. See \helpref{wxHTML Notes}{wxhtml} for more details.
You can find it in {\tt samples/html/helpview}.
\item[{\bf Tex2RTF}]
-Supplied with wxWindows is a utility called Tex2RTF for converting\rtfsp
+Supplied with wxWidgets is a utility called Tex2RTF for converting\rtfsp
\LaTeX\ manuals HTML, MS HTML Help, wxHTML Help, RTF, and Windows
-Help RTF formats. Tex2RTF is used for the wxWindows manuals and can be used independently
+Help RTF formats. Tex2RTF is used for the wxWidgets manuals and can be used independently
by authors wishing to create on-line and printed manuals from the same\rtfsp
\LaTeX\ source. Please see the separate documentation for Tex2RTF.
You can find it under {\tt utils/tex2rtf}.
systems, the Xnest window does not synchronise with the
'skin' window. This program can be found in {\tt utils/emulator}.
\item[{\bf Configuration Tool}]
-The wxWindows Configuration Tool is a work in progress
-intended to make it easier to configure wxWindows
+The wxWidgets Configuration Tool is a work in progress
+intended to make it easier to configure wxWidgets
features in detail. It exports setup.h configurations and will
eventually generate makefile config files. Invoking compilers is
also on the cards. Since configurations are
\setfooter{\thepage}{}{}{}{}{\thepage}%
This chapter is intended to list strategies that may be useful when
-writing and debugging wxWindows programs. If you have any good tips,
+writing and debugging wxWidgets programs. If you have any good tips,
please submit them for inclusion here.
\section{Strategies for reducing programming errors}
\subsection{Use ASSERT}
-Although I haven't done this myself within wxWindows, it is good
+Although I haven't done this myself within wxWidgets, it is good
practice to use ASSERT statements liberally, that check for conditions that
should or should not hold, and print out appropriate error messages.
-These can be compiled out of a non-debugging version of wxWindows
+These can be compiled out of a non-debugging version of wxWidgets
and your application. Using ASSERT is an example of `defensive programming':
it can alert you to problems later on.
very differently sized panel items. Consider using the constraint system, although this
can be complex to program.
-Alternatively, you could use alternative .wrc (wxWindows resource files) on different
+Alternatively, you could use alternative .wrc (wxWidgets resource files) on different
platforms, with slightly different dimensions in each. Or space your panel items out
to avoid problems.
-\subsection{Use wxWindows resource files}
+\subsection{Use wxWidgets resource files}
-Use .xrc (wxWindows resource files) where possible, because they can be easily changed
+Use .xrc (wxWidgets resource files) where possible, because they can be easily changed
independently of source code.
\section{Strategies for debugging}\label{debugstrategies}
in some circumstances (such as when your debugger doesn't support a lot
of debugging code, or you wish to print a bunch of variables).
-\subsection{Use the wxWindows debugging facilities}
+\subsection{Use the wxWidgets debugging facilities}
You can use wxDebugContext to check for
-memory leaks and corrupt memory: in fact in debugging mode, wxWindows will
-automatically check for memory leaks at the end of the program if wxWindows is suitably
+memory leaks and corrupt memory: in fact in debugging mode, wxWidgets will
+automatically check for memory leaks at the end of the program if wxWidgets is suitably
configured. Depending on the operating system and compiler, more or less
specific information about the problem will be logged.
\wxheading{Remarks}
-On a monochrome display, wxWindows shows
+On a monochrome display, wxWidgets shows
all brushes as white unless the colour is really black.
Do not initialize objects on the stack before the program commences,
Although all remaining brushes are deleted when the application exits,
the application should try to clean up all brushes itself. This is because
-wxWindows cannot know if a pointer to the brush object is stored in an
+wxWidgets cannot know if a pointer to the brush object is stored in an
application data structure, and there is a risk of double deletion.
\membersection{wxBrush::GetColour}\label{wxbrushgetcolour}
`memory leaks'. However, it is best not to rely on this automatic
cleanup because it can lead to double deletion in some circumstances.
-There are two mechanisms in recent versions of wxWindows which make the
+There are two mechanisms in recent versions of wxWidgets which make the
brush list less useful than it once was. Under Windows, scarce resources
are cleaned up internally if they are not being used. Also, a referencing
counting mechanism applied to all GDI objects means that some sharing
your application is using too many resources, you can resort to using
GDI lists to share objects explicitly.
-The only compelling use for the brush list is for wxWindows to keep
+The only compelling use for the brush list is for wxWidgets to keep
track of brushes in order to clean them up on exit. It is also kept for
-backward compatibility with earlier versions of wxWindows.
+backward compatibility with earlier versions of wxWidgets.
\wxheading{See also}
\func{void}{AddBrush}{\param{wxBrush *}{brush}}
-Used internally by wxWindows to add a brush to the list.
+Used internally by wxWidgets to add a brush to the list.
\membersection{wxBrushList::FindOrCreateBrush}\label{wxbrushlistfindorcreatebrush}
\func{void}{RemoveBrush}{\param{wxBrush *}{brush}}
-Used by wxWindows to remove a brush from the list.
+Used by wxWidgets to remove a brush from the list.
%% Created: 07.02.04
%% RCS-ID: $Id$
%% Copyright: (c) 2004 Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxBufferedDC}}\label{wxbuffereddc}
creation of a button and before the creation of other buttons
will cause misalignment of the row of buttons, since default
buttons are larger. To get around this, call {\it SetDefault}\rtfsp
-after you have created a row of buttons: wxWindows will
+after you have created a row of buttons: wxWidgets will
then set the size of all buttons currently on the panel to
the same size.
%% Created: 03.01.00
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxCalendarCtrl}}\label{wxcalendarctrl}
%% Created: 20.06.00
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxCaret}}\label{wxcaret}
\setheader{{\it CHAPTER \thechapter}}{}{}{}{}{{\it CHAPTER \thechapter}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
-A classification of wxWindows classes by category.
+A classification of wxWidgets classes by category.
{\large {\bf Managed windows}}
{\large {\bf Data structures}}
-These are the data structure classes supported by wxWindows.
+These are the data structure classes supported by wxWidgets.
\twocolwidtha{6cm}
\begin{twocollist}\itemsep=0pt
\twocolitem{\helpref{wxList}{wxlist}}{A simple linked list implementation}
\twocolitem{\helpref{wxLongLong}{wxlonglong}}{A portable 64 bit integer type}
\twocolitem{\helpref{wxNode}{wxnode}}{Represents a node in the wxList implementation}
-\twocolitem{\helpref{wxObject}{wxobject}}{The root class for most wxWindows classes}
+\twocolitem{\helpref{wxObject}{wxobject}}{The root class for most wxWidgets classes}
\twocolitem{\helpref{wxPathList}{wxpathlist}}{A class to help search multiple paths}
\twocolitem{\helpref{wxPoint}{wxpoint}}{Representation of a point}
\twocolitem{\helpref{wxRect}{wxrect}}{A class representing a rectangle}
\overview{Overview}{runtimeclassoverview}
-wxWindows supports run-time manipulation of class information, and dynamic
+wxWidgets supports run-time manipulation of class information, and dynamic
creation of objects given class names.
\twocolwidtha{6cm}
\overview{Overview}{wxlogoverview}
-wxWindows provides several classes and functions for message logging.
+wxWidgets provides several classes and functions for message logging.
Please see the \helpref{wxLog overview}{wxlogoverview} for more details.
\twocolwidtha{6cm}
\overview{Overview}{debuggingoverview}
-wxWindows supports some aspects of debugging an application through
+wxWidgets supports some aspects of debugging an application through
classes, functions and macros.
\twocolwidtha{6cm}
{\large {\bf Networking classes}}
-wxWindows provides its own classes for socket based networking.
+wxWidgets provides its own classes for socket based networking.
\twocolwidtha{6cm}
\begin{twocollist}\itemsep=0pt
\overview{Overview}{ipcoverview}
-wxWindows provides simple interprocess communications facilities
+wxWidgets provides simple interprocess communications facilities
based on Windows DDE, but available on most platforms using TCP.
\twocolwidtha{6cm}
\overview{Overview}{docviewoverview}
-wxWindows supports a document/view framework which provides
+wxWidgets supports a document/view framework which provides
housekeeping for a document-centric application.
\twocolwidtha{6cm}
{\large {\bf File related classes}}
-wxWindows has several small classes to work with disk files, see \helpref{file classes
+wxWidgets has several small classes to work with disk files, see \helpref{file classes
overview}{wxfileoverview} for more details.
\twocolwidtha{6cm}
{\large {\bf Stream classes}}
-wxWindows has its own set of stream classes, as an alternative to often buggy standard stream
+wxWidgets has its own set of stream classes, as an alternative to often buggy standard stream
libraries, and to provide enhanced functionality.
\twocolwidtha{6cm}
\overview{Multithreading overview}{wxthreadoverview}
-wxWindows provides a set of classes to make use of the native thread
+wxWidgets provides a set of classes to make use of the native thread
capabilities of the various platforms.
\twocolwidtha{6cm}
{\large {\bf HTML classes}}
-wxWindows provides a set of classes to display text in HTML format. These
+wxWidgets provides a set of classes to display text in HTML format. These
class include a help system based on the HTML widget.
\twocolwidtha{6cm}
{\large {\bf Virtual file system classes}}
-wxWindows provides a set of classes that implement an extensible virtual file system,
+wxWidgets provides a set of classes that implement an extensible virtual file system,
used internally by the HTML classes.
\twocolwidtha{6cm}
\overview{Database classes overview}{odbcoverview}
-wxWindows provides a set of classes for accessing Microsoft's ODBC (Open Database Connectivity)
+wxWidgets provides a set of classes for accessing Microsoft's ODBC (Open Database Connectivity)
product, donated by Remstar. This is known as wxODBC.
\twocolwidtha{6cm}
A checklistbox is like a listbox, but allows items to be checked or unchecked.
This class is currently implemented under Windows and GTK. When using this
-class under Windows wxWindows must be compiled with USE\_OWNER\_DRAWN set to 1.
+class under Windows wxWidgets must be compiled with USE\_OWNER\_DRAWN set to 1.
Only the new functions for this class are documented; see also \helpref{wxListBox}{wxlistbox}.
\func{static void}{InitializeClasses}{\void}
Initializes pointers in the wxClassInfo objects for fast execution
-of IsKindOf. Called in base wxWindows library initialization.
+of IsKindOf. Called in base wxWidgets library initialization.
\membersection{wxClassInfo::IsKindOf}\label{wxclassinfoiskindof}
(such as all controls and \helpref{wxApp}{wxapp})
can hold arbitrary data which is here referred to as "client data".
This is useful e.g. for scripting languages which need to handle
-shadow objects for most of wxWindows' classes and which store
+shadow objects for most of wxWidgets' classes and which store
a handle to such a shadow class as client data in that class.
This data can either be of type void - in which case the data
{\it container} does not take care of freeing the data again
\section{\class{wxClipboard}}\label{wxclipboard}
A class for manipulating the clipboard. Note that this is not compatible with the
-clipboard class from wxWindows 1.xx, which has the same name but a different implementation.
+clipboard class from wxWidgets 1.xx, which has the same name but a different implementation.
To use the clipboard, you call member functions of the global {\bf wxTheClipboard} object.
%% Created: 27.03.00
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxCmdLineParser}}\label{wxcmdlineparser}
command line parsing.
In the latter case, the appropriate error message and usage information are
-logged by wxCmdLineParser itself using the standard wxWindows logging functions.
+logged by wxCmdLineParser itself using the standard wxWidgets logging functions.
\membersection{Getting results}\label{wxcmdlineparsergettingresults}
\section{\class{wxColourDatabase}}\label{wxcolourdatabase}
-wxWindows maintains a database of standard RGB colours for a predefined
+wxWidgets maintains a database of standard RGB colours for a predefined
set of named colours (such as ``BLACK'', ``LIGHT GREY''). The
application may add to this set if desired by using
\helpref{AddColour}{wxcolourdatabaseaddcolour} and may use it to look up
it is replaced.
Please note that the overload taking a pointer is deprecated and will be
-removed in the next wxWindows version, please don't use it.
+removed in the next wxWidgets version, please don't use it.
\membersection{wxColourDatabase::Find}\label{wxcolourdatabasefind}
must be deleted by the caller otherwise.
Please note that this method is deprecated and will be removed in the next
-wxWindows version, please use \helpref{Find}{wxcolourdatabasefind} instead of
+wxWidgets version, please use \helpref{Find}{wxcolourdatabasefind} instead of
it.
allows you to write the same code regardless of whether you're working with
the registry under Win32 or text-based config files under Unix (or even
Windows 3.1 .INI files if you're really unlucky). To make writing the portable
-code even easier, wxWindows provides a typedef wxConfig
+code even easier, wxWidgets provides a typedef wxConfig
which is mapped onto the native wxConfigBase implementation on the given
platform: i.e. wxRegConfig under Win32 (optionally wxIniConfig) and
wxFileConfig otherwise.
\wxheading{Include files}
-<wx/config.h> (to let wxWindows choose a wxConfig class for your platform)\\
+<wx/config.h> (to let wxWidgets choose a wxConfig class for your platform)\\
<wx/confbase.h> (base config class)\\
<wx/fileconf.h> (wxFileConfig class)\\
<wx/msw/regconf.h> (wxRegConfig class)\\
in the very start of the program and {\it Set()} it as the default. Then, from
anywhere in your program, you may access it using the {\it Get()} function.
Note that you must delete this object (usually in \helpref{wxApp::OnExit}{wxapponexit})
-in order to avoid memory leaks, wxWindows won't do it automatically.
+in order to avoid memory leaks, wxWidgets won't do it automatically.
As it happens, you may even further simplify the procedure described above:
you may forget about calling {\it Set()}. When {\it Get()} is called and there
is no current object, it will create one using {\it Create()} function. To
disable this behaviour {\it DontCreateOnDemand()} is provided.
-{\bf Note:} You should use either {\it Set()} or {\it Get()} because wxWindows
+{\bf Note:} You should use either {\it Set()} or {\it Get()} because wxWidgets
library itself would take advantage of it and could save various information
in it. For example \helpref{wxFontMapper}{wxfontmapper} or Unix version
of \helpref{wxFileDialog}{wxfiledialog} have ability to use wxConfig class.
of the usual storage of {\tt foo=C:$\backslash\backslash$mydir}.
The wxCONFIG\_USE\_NO\_ESCAPE\_CHARACTERS style can be helpful if your config
-file must be read or written to by a non-wxWindows program (which might not
+file must be read or written to by a non-wxWidgets program (which might not
understand the escape characters). Note, however, that if
wxCONFIG\_USE\_NO\_ESCAPE\_CHARACTERS style is used, it is is now
your application's responsibility to ensure that there is no newline or
\setheader{{\it CHAPTER \thechapter}}{}{}{}{}{{\it CHAPTER \thechapter}}%
\setfooter{\thepage}{}{}{}{}{\thepage}
-This chapter describes the constants defined by wxWindows.
+This chapter describes the constants defined by wxWidgets.
\input cppconst.tex
\input stdevtid.tex
-\section{Preprocesser symbols defined by wxWindows}\label{cppconst}
+\section{Preprocesser symbols defined by wxWidgets}\label{cppconst}
-Here is the list of preprocessor symbols used in the wxWindows source grouped
+Here is the list of preprocessor symbols used in the wxWidgets source grouped
by category (and sorted by alphabetical order inside each category).
\subsection{GUI system}
\begin{twocollist}\itemsep=0pt
\twocolitem{\_\_WINDOWS\_\_}{any Windows, yom may also use \_\_WXMSW\_\_}
-\twocolitem{\_\_WIN16\_\_}{Win16 API (not supported since wxWindows 2.6)}
+\twocolitem{\_\_WIN16\_\_}{Win16 API (not supported since wxWidgets 2.6)}
\twocolitem{\_\_WIN32\_\_}{Win32 API}
\twocolitem{\_\_WIN95\_\_}{Windows 95 or NT 4.0 and above system (not NT 3.5x)}
\twocolitem{\_\_WXBASE\_\_}{Only wxBase, no GUI features}
\twocolitem{\_\_WXPM\_\_}{OS/2 native Presentation Manager}
\twocolitem{\_\_WXSTUBS\_\_}{Stubbed version ('template' wxWin implementation)}
\twocolitem{\_\_WXXT\_\_}{Xt; mutually exclusive with WX\_MOTIF, not
-implemented in wxWindows 2.x}
+implemented in wxWidgets 2.x}
\twocolitem{\_\_WXX11\_\_}{wxX11 (\_\_WXUNIVERSAL\_\_ will be also defined)}
\twocolitem{\_\_WXWINE\_\_}{WINE (i.e. WIN32 on Unix)}
\twocolitem{\_\_WXUNIVERSAL\_\_}{wxUniversal port, always defined in addition
\subsection{Miscellaneous}
\begin{twocollist}\itemsep=0pt
-\twocolitem{\_\_WXWINDOWS\_\_}{always defined in wxWindows applications, see
+\twocolitem{\_\_WXWINDOWS\_\_}{always defined in wxWidgets applications, see
also \helpref{wxCHECK\_VERSION}{wxcheckversion}}
\twocolitem{\_\_WXDEBUG\_\_}{defined in debug mode, undefined in release mode}
\twocolitem{wxUSE\_XXX}{if defined as $1$, feature XXX is active
\twocolitem{wxUSE\_GUI}{this particular feature test macro is defined to $1$
when compiling or using the library with the GUI features activated, if it is
defined as $0$, only wxBase is available.}
-\twocolitem{wxUSE\_BASE}{only used by wxWindows internally (defined as $1$ when
+\twocolitem{wxUSE\_BASE}{only used by wxWidgets internally (defined as $1$ when
building wxBase code, either as a standalone library or as part of the
-monolithic wxWindows library, defined as $0$ when building GUI library only)}
+monolithic wxWidgets library, defined as $0$ when building GUI library only)}
\end{twocollist}
%% Created: 01.01.03
%% RCS-ID: $Id$
%% Copyright: (c) 2003 Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxControlWithItems}}\label{wxcontrolwithitems}
-This class is an abstract base class for some wxWindows controls which contain
+This class is an abstract base class for some wxWidgets controls which contain
several items, such as \helpref{wxListBox}{wxlistbox} and
\helpref{wxCheckListBox}{wxchecklistbox} derived from it,
\helpref{wxChoice}{wxchoice} and \helpref{wxComboBox}{wxcombobox}.
{\bf Obsolescence note:} This method is obsolete and was replaced with
\helpref{GetCount}{wxcontrolwithitemsgetcount}, please use the new method in
-the new code. This method is only available if wxWindows was compiled with
+the new code. This method is only available if wxWidgets was compiled with
{\tt WXWIN\_COMPATIBILITY\_2\_2} defined and will disappear completely in
future versions.
an example).
A single cursor object may be used in many windows (any subwindow type).
-The wxWindows convention is to set the cursor for a window, as in X,
+The wxWidgets convention is to set the cursor for a window, as in X,
rather than to set it globally as in MS Windows, although a
global \helpref{::wxSetCursor}{wxsetcursor} is also available for MS Windows use.
Destroys the cursor. A cursor can be reused for more
than one window, and does not get destroyed when the window is
-destroyed. wxWindows destroys all cursors on application exit, although
+destroyed. wxWidgets destroys all cursors on application exit, although
it is best to clean them up explicitly.
\membersection{wxCursor::Ok}\label{wxcursorok}
%% Created: 03.11.99
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxDataFormat}}\label{wxdataformat}
%% Modified by:
%% Created: 18.10.99
%% RCS-ID: $Id$
-%% Copyright: (c) wxWindows team
-%% License: wxWindows license
+%% Copyright: (c) wxWidgets team
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxDataObject}}\label{wxdataobject}
but may be annoying if you only want to do something simple like cut and paste
text.
-To provide a solution for both cases, wxWindows has two predefined classes
+To provide a solution for both cases, wxWidgets has two predefined classes
which derive from wxDataObject: \helpref{wxDataObjectSimple}{wxdataobjectsimple} and
\helpref{wxDataObjectComposite}{wxdataobjectcomposite}.
\helpref{wxDataObjectSimple}{wxdataobjectsimple} is
%% Created: 04.04.00
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxDateSpan}}\label{wxdatespan}
%% Created: 07.03.00
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxDateTime}}\label{wxdatetime}
This function does the same as the standard ANSI C {\tt strftime(3)} function.
Please see its description for the meaning of {\it format} parameter.
-It also accepts a few wxWindows-specific extensions: you can optionally specify
+It also accepts a few wxWidgets-specific extensions: you can optionally specify
the width of the field to follow using {\tt printf(3)}-like syntax and the
format specification {\tt \%l} can be used to get the number of milliseconds.
\func{}{wxDataInputStream}{\param{wxInputStream\&}{ stream}, \param{wxMBConv\&}{ conv = wxMBConvUTF8}}
Constructs a datastream object from an input stream. Only read methods will
-be available. The second form is only available in Unicode build of wxWindows.
+be available. The second form is only available in Unicode build of wxWidgets.
\wxheading{Parameters}
integer specifying the length of the string (without the last null character)
and then reads the string.
-In Unicode build of wxWindows, the fuction first reads multibyte (char*)
+In Unicode build of wxWidgets, the fuction first reads multibyte (char*)
string from the stream and then converts it to Unicode using the {\it conv}
object passed to constructor and returns the result as wxString. You are
responsible for using the same convertor as when writing the stream.
\func{}{wxDataOutputStream}{\param{wxOutputStream\&}{ stream}, \param{wxMBConv\&}{ conv = wxMBConvUTF8}}
Constructs a datastream object from an output stream. Only write methods will
-be available. The second form is only available in Unicode build of wxWindows.
+be available. The second form is only available in Unicode build of wxWidgets.
\wxheading{Parameters}
Writes {\it string} to the stream. Actually, this method writes the size of
the string before writing {\it string} itself.
-In ANSI build of wxWindows, the string is written to the stream in exactly
+In ANSI build of wxWidgets, the string is written to the stream in exactly
same way it is represented in memory. In Unicode build, however, the string
is first converted to multibyte representation with {\it conv} object passed
to stream's constructor (consequently, ANSI application can read data
\wxheading{Remarks}
Default cursor scrolling is defined by wxODBC\_FWD\_ONLY\_CURSORS in setup.h
-when the wxWindows library is built. This behavior can be overridden when
+when the wxWidgets library is built. This behavior can be overridden when
an instance of a wxDb is created (see \helpref{wxDb constructor}{wxdbconstr}).
Default setting of this value true, as not all databases/drivers support
both types of cursors.
\helpref{Enumerated types}{wxdbenumeratedtypes} section of wxDb.
There are known issues with conformance to the ODBC standards with several
-datasources supported by the wxWindows ODBC classes. Please see the overview
+datasources supported by the wxWidgets ODBC classes. Please see the overview
for specific details on which datasource have which issues.
\wxheading{Return value}
\func{bool}{IsFwdOnlyCursors}{\void}
-Older form (pre-2.3/2.4 of wxWindows) of the
+Older form (pre-2.3/2.4 of wxWidgets) of the
\helpref{wxDb::IsFwdOnlyCursors}{wxdbisfwdonlycursors}. This method is
provided for backward compatibility only. The method
\helpref{wxDb::IsFwdOnlyCursors}{wxdbisfwdonlycursors} should be
\wxheading{Remarks}
-Added as of wxWindows v2.4 release, this function is a renamed version of
-wxDb::FwdOnlyCursors() to match the normal wxWindows naming conventions for
+Added as of wxWidgets v2.4 release, this function is a renamed version of
+wxDb::FwdOnlyCursors() to match the normal wxWidgets naming conventions for
class member functions.
This function is not available in versions prior to v2.4. You should
-use \helpref{wxDb::FwdOnlyCursors}{wxdbfwdonlycursors} for wxWindows
+use \helpref{wxDb::FwdOnlyCursors}{wxdbfwdonlycursors} for wxWidgets
versions prior to 2.4.
\wxheading{See also}
information about all tables in the datasource to have all the datasource's
information in one memory structure.
-Primarily, this class is used internally by the wxWindows ODBC classes.
+Primarily, this class is used internally by the wxWidgets ODBC classes.
\begin{verbatim}
wxChar catalog[128+1];
\wxheading{Remarks}
-NULL column support is currently not fully implemented as of wxWindows 2.4.
+NULL column support is currently not fully implemented as of wxWidgets 2.4.
\membersection{wxDbTable::IsCursorClosedOnCommit}\label{wxdbtableiscursorclosedoncommit}
and logical functions are supported.
{\bf Note:} on Windows, blitting with masks can be speeded up considerably by compiling
-wxWindows with the wxUSE\_DC\_CACHE option enabled. You can also influence whether MaskBlt
+wxWidgets with the wxUSE\_DC\_CACHE option enabled. You can also influence whether MaskBlt
or the explicit mask blitting code above is used, by using \helpref{wxSystemOptions}{wxsystemoptions} and
setting the {\bf no-maskblt} option to 1.
for filling the shape. Using a transparent brush suppresses filling.
The programmer is responsible for deleting the list of points.
-Note that wxWindows automatically closes the first and last points.
+Note that wxWidgets automatically closes the first and last points.
\pythonnote{The wxPython version of this method accepts a Python list
of wxPoint objects.}
If {\it optimize} is true (the default), this function sets optimization mode on.
This currently means that under X, the device context will not try to set a pen or brush
property if it is known to be set already. This approach can fall down
-if non-wxWindows code is using the same device context or window, for example
+if non-wxWidgets code is using the same device context or window, for example
when the window is a panel on which the windowing system draws panel items.
-The wxWindows device context 'memory' will now be out of step with reality.
+The wxWidgets device context 'memory' will now be out of step with reality.
Setting optimization off, drawing, then setting it back on again, is a trick
that must occasionally be employed.
A class for performing various debugging and memory tracing
operations. Full functionality (such as printing out objects
-currently allocated) is only present in a debugging build of wxWindows,
+currently allocated) is only present in a debugging build of wxWidgets,
i.e. if the \_\_WXDEBUG\_\_ symbol is defined. wxDebugContext
and related functions and macros can be compiled out by setting
wxUSE\_DEBUG\_CONTEXT to 0 is setup.h
%% Created: 11.08.03
%% RCS-ID: $Id$
%% Copyright: (c) 2003 Vadim Zeitlin <vadim@wxwindows.org>
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxDelegateRendererNative}}\label{wxdelegaterenderernative}
%% Created: 08.04.00
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxDialUpEvent}}\label{wxdialupevent}
\helpref{application's top level window}{wxappgettopwindow} as parent. Use this
style to prevent this from happening and create an orphan dialog. This is not recommended for modal dialogs.}
\twocolitem{\windowstyle{wxDIALOG\_EX\_CONTEXTHELP}}{Under Windows, puts a query button on the
-caption. When pressed, Windows will go into a context-sensitive help mode and wxWindows will send
+caption. When pressed, Windows will go into a context-sensitive help mode and wxWidgets will send
a wxEVT\_HELP event if the user clicked on an application window. {\it Note}\ that this is an extended
style and must be set by calling \helpref{SetExtraStyle}{wxwindowsetextrastyle} before Create is called (two-step construction).}
\end{twocollist}
\docparam{title}{The title of the dialog.}
\docparam{pos}{The dialog position. A value of (-1, -1) indicates a default position, chosen by
-either the windowing system or wxWindows, depending on platform.}
+either the windowing system or wxWidgets, depending on platform.}
\docparam{size}{The dialog size. A value of (-1, -1) indicates a default size, chosen by
-either the windowing system or wxWindows, depending on platform.}
+either the windowing system or wxWidgets, depending on platform.}
\docparam{style}{The window style. See \helpref{wxDialog}{wxdialog}.}
%% Created: 08.04.00
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxDialUpManager}}\label{wxdialupmanager}
when the user hangs up the modem). For this, you need to use one of the event
macros described below.
-This class is different from other wxWindows classes in that there is at most
+This class is different from other wxWidgets classes in that there is at most
one instance of this class in the program accessed via
\helpref{wxDialUpManager::Create()}{wxdialupmanagercreate} and you can't
create the objects of this class directly.
%% Created: 04.04.00
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxDir}}\label{wxdir}
%% Created: 14.01.02 (extracted from dir.tex)
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxDirTraverser}}\label{wxdirtraverser}
%% Created: 02.04.00
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxDllLoader}}\label{wxdllloader}
%% Created: 02.11.99
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxDataObjectComposite}}\label{wxdataobjectcomposite}
%% Created: 02.11.99
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxDataObjectSimple}}\label{wxdataobjectsimple}
The wxDocChildFrame class provides a default frame for displaying documents
on separate windows. This class can only be used for SDI (not MDI) child frames.
-The class is part of the document/view framework supported by wxWindows,
+The class is part of the document/view framework supported by wxWidgets,
and cooperates with the \helpref{wxView}{wxview}, \helpref{wxDocument}{wxdocument},
\rtfsp\helpref{wxDocManager}{wxdocmanager} and \helpref{wxDocTemplate}{wxdoctemplate} classes.
\section{\class{wxDocManager}}\label{wxdocmanager}
-The wxDocManager class is part of the document/view framework supported by wxWindows,
+The wxDocManager class is part of the document/view framework supported by wxWidgets,
and cooperates with the \helpref{wxView}{wxview}, \helpref{wxDocument}{wxdocument}\rtfsp
and \helpref{wxDocTemplate}{wxdoctemplate} classes.
The wxDocMDIChildFrame class provides a default frame for displaying documents
on separate windows. This class can only be used for MDI child frames.
-The class is part of the document/view framework supported by wxWindows,
+The class is part of the document/view framework supported by wxWidgets,
and cooperates with the \helpref{wxView}{wxview}, \helpref{wxDocument}{wxdocument},
\rtfsp\helpref{wxDocManager}{wxdocmanager} and \helpref{wxDocTemplate}{wxdoctemplate} classes.
\section{\class{wxDocument}}\label{wxdocument}
The document class can be used to model an application's file-based
-data. It is part of the document/view framework supported by wxWindows,
+data. It is part of the document/view framework supported by wxWidgets,
and cooperates with the \helpref{wxView}{wxview}, \helpref{wxDocTemplate}{wxdoctemplate}\rtfsp
and \helpref{wxDocManager}{wxdocmanager} classes.
streaming your own data. LoadObject is called by the framework
automatically when the document contents need to be loaded.
-Note that only one of these forms exists, depending on how wxWindows
+Note that only one of these forms exists, depending on how wxWidgets
was configured.
\membersection{wxDocument::Modify}\label{wxdocumentmodify}
streaming your own data. SaveObject is called by the framework
automatically when the document contents need to be saved.
-Note that only one of these forms exists, depending on how wxWindows
+Note that only one of these forms exists, depending on how wxWidgets
was configured.
\membersection{wxDocument::SetCommandProcessor}
%% Created: 14.01.02 (extracted from dllload.tex)
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxDynamicLibrary}}\label{wxdynamiclibrary}
\func{wxString}{CanonicalizePluginName}{\param{const wxString\& }{name}, \param{wxPluginCategory}{ cat = wxDL\_PLUGIN\_GUI}}
This function does the same thing as
-\helpref{CanonicalizeName}{wxdynamiclibrarycanonicalizename} but for wxWindows
+\helpref{CanonicalizeName}{wxdynamiclibrarycanonicalizename} but for wxWidgets
plugins. The only difference is that compiler and version information are added
to the name to ensure that the plugin which is going to be loaded will be
compatible with the main program.
This class is capable of converting strings between two
8-bit encodings/charsets. It can also convert from/to Unicode (but only
-if you compiled wxWindows with wxUSE\_WCHAR\_T set to 1). Only limited subset
+if you compiled wxWidgets with wxUSE\_WCHAR\_T set to 1). Only limited subset
of encodings in supported by wxEncodingConverter:
{\tt wxFONTENCODING\_ISO8859\_1..15}, {\tt wxFONTENCODING\_CP1250..1257} and
{\tt wxFONTENCODING\_KOI8}.
false if given conversion is impossible, true otherwise
(conversion may be impossible either if you try to convert
-to Unicode with non-Unicode build of wxWindows or if input
+to Unicode with non-Unicode build of wxWidgets or if input
or output encoding is not supported.)
You must call \helpref{Init}{wxencodingconverterinit} before using this method!
-{\tt wchar\_t} versions of the method are not available if wxWindows was compiled
+{\tt wchar\_t} versions of the method are not available if wxWidgets was compiled
with {\tt wxUSE\_WCHAR\_T} set to 0.
Returns a copy of the event.
-Any event that is posted to the wxWindows event system for later action (via
+Any event that is posted to the wxWidgets event system for later action (via
\helpref{wxEvtHandler::AddPendingEvent}{wxevthandleraddpendingevent} or
-\helpref{wxPostEvent}{wxpostevent}) must implement this method. All wxWindows
+\helpref{wxPostEvent}{wxpostevent}) must implement this method. All wxWidgets
events fully implement this method, but any derived events implemented by the
user should also implement this method just in case they (or some event
derived from them) are ever posted.
-All wxWindows events implement a copy constructor, so the easiest way of
+All wxWidgets events implement a copy constructor, so the easiest way of
implementing the Clone function is to implement a copy constructor for
a new event (call it MyEvent) and then define the Clone function like this:
\wxheading{Remarks}
-Normally, your application would not call this function: it is called in the wxWindows
+Normally, your application would not call this function: it is called in the wxWidgets
implementation to dispatch incoming user interface events to the framework (and application).
However, you might need to call it if implementing new functionality (such as a new control) where
you define new event types, as opposed to allowing the user to override virtual functions.
An instance where you might actually override the {\bf ProcessEvent} function is where you want
-to direct event processing to event handlers not normally noticed by wxWindows. For example,
+to direct event processing to event handlers not normally noticed by wxWidgets. For example,
in the document/view architecture, documents and views are potential event handlers.
When an event reaches a frame, {\bf ProcessEvent} will need to be called on the associated
document and view in case event handler functions are associated with these objects.
%% Created: 01.08.01
%% RCS-ID: $Id$
%% Copyright: (c) 2001 Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxFindDialogEvent}}\label{wxfinddialogevent}
\func{}{wxFindDialogEvent}{\param{wxEventType }{commandType = wxEVT\_NULL}, \param{int }{id = 0}}
-Constuctor used by wxWindows only.
+Constuctor used by wxWidgets only.
\membersection{wxFindDialogEvent::GetFlags}\label{wxfinddialogeventgetflags}
%% Created: 14.01.02 (extracted from file.tex)
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxFFile}}\label{wxffile}
Writes the contents of the string to the file, returns \true on success.
-The second argument is only meaningful in Unicode build of wxWindows when
+The second argument is only meaningful in Unicode build of wxWidgets when
{\it conv} is used to convert {\it s} to multibyte representation.
{\bf Warning:} Under all non-Windows platforms this class is currently
"input-only", i.e. you can receive the files from another application, but
-copying (or dragging) file(s) from a wxWindows application is not currently
+copying (or dragging) file(s) from a wxWidgets application is not currently
supported.
\wxheading{Virtual functions to override}
%% Created: 14.01.02 (extracted from file.tex)
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxFile}}\label{wxfile}
Writes the contents of the string to the file, returns true on success.
-The second argument is only meaningful in Unicode build of wxWindows when
+The second argument is only meaningful in Unicode build of wxWidgets when
{\it conv} is used to convert {\it s} to multibyte representation.
Note that this method only works with {\tt NUL}-terminated strings, if you want
\docparam{pos}{Dialog position. Not implemented.}
-{\bf NB:} Previous versions of wxWindows used {\tt wxCHANGE\_DIR} by default
+{\bf NB:} Previous versions of wxWidgets used {\tt wxCHANGE\_DIR} by default
under MS Windows which allowed the program to simply remember the last
directory where user selected the files to open/save. This (desired)
functionality must be implemented in the program itself now (manually remember
%% Created: 30.11.01
%% RCS-ID: $Id$
%% Copyright: (c) 2001 Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxFileName}}\label{wxfilename}
wxFileName encapsulates a file name. This class serves two purposes: first, it
provides the functions to split the file names into components and to recombine
these components in the full file name which can then be passed to the OS file
-functions (and \helpref{wxWindows functions}{filefunctions} wrapping them).
+functions (and \helpref{wxWidgets functions}{filefunctions} wrapping them).
Second, it includes the functions for working with the files itself. Note that
to change the file data you should use \helpref{wxFile}{wxfile} class instead.
wxFileName provides functions for working with the file attributes.
rows or all columns are not necessarily the same height or width as in
the \helpref{wxGridSizer}{wxgridsizer}.
-Since wxWindows 2.5.0, wxFlexGridSizer can also size items equally in one
+Since wxWidgets 2.5.0, wxFlexGridSizer can also size items equally in one
direction but unequally ("flexibly") in the other. If the sizer is only
flexible in one direction (this can be changed using
\helpref{SetFlexibleDrection}{wxflexgridsizersetflexibledirection}),
Although all remaining fonts are deleted when the application exits,
the application should try to clean up all fonts itself. This is because
-wxWindows cannot know if a pointer to the font object is stored in an
+wxWidgets cannot know if a pointer to the font object is stored in an
application data structure, and there is a risk of double deletion.
\membersection{wxFont::IsFixedWidth}\label{wxfontisfixedwidth}
To avoid portability problems, don't rely on a specific face, but specify the font family
instead or as well. A suitable font will be found on the end-user's system. If both the
-family and the facename are specified, wxWindows will first search for the specific face,
+family and the facename are specified, wxWidgets will first search for the specific face,
and then for a font belonging to the same family.
\wxheading{See also}
%% Created: 03.11.99
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxFontEnumerator}}\label{wxfontenumerator}
\func{void}{AddFont}{\param{wxFont *}{font}}
-Used by wxWindows to add a font to the list, called in the font constructor.
+Used by wxWidgets to add a font to the list, called in the font constructor.
\membersection{wxFontList::FindOrCreateFont}\label{findorcreatefont}
\func{void}{RemoveFont}{\param{wxFont *}{font}}
-Used by wxWindows to remove a font from the list.
+Used by wxWidgets to remove a font from the list.
structure with the parameters required to create the font, otherwise
return false.
-The first form is for wxWindows' internal use while the second one
+The first form is for wxWidgets' internal use while the second one
is better suitable for general use -- it returns wxFontEncoding which
can consequently be passed to wxFont constructor.
Set the current font mapper object and return previous one (may be NULL).
This method is only useful if you want to plug-in an alternative font mapper
-into wxWindows.
+into wxWidgets.
\wxheading{See also}
on top of its parent (unlike wxSTAY\_ON\_TOP). A frame created with this style
must have a non-NULL parent.}
\twocolitem{\windowstyle{wxFRAME\_EX\_CONTEXTHELP}}{Under Windows, puts a query button on the
-caption. When pressed, Windows will go into a context-sensitive help mode and wxWindows will send
+caption. When pressed, Windows will go into a context-sensitive help mode and wxWidgets will send
a wxEVT\_HELP event if the user clicked on an application window. {\it Note} that this is an extended
style and must be set by calling \helpref{SetExtraStyle}{wxwindowsetextrastyle} before Create is called (two-step construction).
You cannot use this style together with wxMAXIMIZE\_BOX or wxMINIMIZE\_BOX, so
\docparam{title}{The caption to be displayed on the frame's title bar.}
\docparam{pos}{The window position. A value of (-1, -1) indicates a default position, chosen by
-either the windowing system or wxWindows, depending on platform.}
+either the windowing system or wxWidgets, depending on platform.}
\docparam{size}{The window size. A value of (-1, -1) indicates a default size, chosen by
-either the windowing system or wxWindows, depending on platform.}
+either the windowing system or wxWidgets, depending on platform.}
\docparam{style}{The window style. See \helpref{wxFrame}{wxframe}.}
of valid styles.}
\docparam{id}{The status bar window identifier. If -1, an identifier will be chosen by
-wxWindows.}
+wxWidgets.}
\docparam{name}{The status bar window name.}
of valid styles.}
\docparam{id}{The toolbar window identifier. If -1, an identifier will be chosen by
-wxWindows.}
+wxWidgets.}
\docparam{name}{The toolbar window name.}
of valid styles.}
\docparam{id}{The window identifier. If -1, an identifier will be chosen by
-wxWindows.}
+wxWidgets.}
\docparam{name}{The window name.}
of valid styles.}
\docparam{id}{The toolbar window identifier. If -1, an identifier will be chosen by
-wxWindows.}
+wxWidgets.}
\docparam{name}{The toolbar window name.}
%\end{verbatim}
%
%You can replace std.ico, mdi.ico and child.ico with your own defaults
-%for all your wxWindows application. Currently they show the same icon.
+%for all your wxWidgets application. Currently they show the same icon.
\membersection{wxFrame::SetMenuBar}\label{wxframesetmenubar}
\item {\bf protocol} - handler can recognize if it is able to open a
file by checking its protocol. Examples are "http", "file" or "ftp".
\item {\bf right location} - is the name of file within the protocol.
-In "http://www.wxwindows.org/index.html" the right location is "//www.wxwindows.org/index.html".
+In "http://www.wxwidgets.org/index.html" the right location is "//www.wxwidgets.org/index.html".
\item {\bf anchor} - an anchor is optional and is usually not present.
In "index.htm\#chapter2" the anchor is "chapter2".
\item {\bf left location} - this is usually an empty string.
\wxheading{File Systems Included in wxHTML}
-The following virtual file system handlers are part of wxWindows so far:
+The following virtual file system handlers are part of wxWidgets so far:
\begin{twocollist}
\twocolitem{{\bf wxInternetFSHandler}}{A handler for accessing documents
will be copied into private memory stream and available under
name "memory:" + filename.
-Note that when storing image/bitmap, you must use image format that wxWindows
+Note that when storing image/bitmap, you must use image format that wxWidgets
can write (e.g. JPG, PNG, see \helpref{wxImage documentation}{wximage})!
Examples :
\begin{verbatim}
-http://www.wxwindows.org
+http://www.wxwidgets.org
http://www.ms.mff.cuni.cz/~vsla8348/wxhtml/archive.zip#zip:info.txt
file:/home/vasek/index.htm
relative-file.htm
%% Modified by:
%% Created: ~1997
%% RCS-ID: $Id$
-%% Copyright: (c) wxWindows team
-%% License: wxWindows license
+%% Copyright: (c) wxWidgets team
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxFTP}}\label{wxftp}
}
ftp.ChDir("/pub");
- wxInputStream *in = ftp.GetInputStream("wxWindows-4.2.0.tar.gz");
+ wxInputStream *in = ftp.GetInputStream("wxWidgets-4.2.0.tar.gz");
if ( !in )
{
wxLogError("Coudln't get file");
\setheader{{\it CHAPTER \thechapter}}{}{}{}{}{{\it CHAPTER \thechapter}}%
\setfooter{\thepage}{}{}{}{}{\thepage}
-The functions and macros defined in wxWindows are described here: you can
+The functions and macros defined in wxWidgets are described here: you can
either look up a function using the alphabetical listing of them or find it in
the corresponding topic.
\section{Version macros}\label{versionfunctions}
-The following constants are defined in wxWindows:
+The following constants are defined in wxWidgets:
\begin{itemize}\itemsep=0pt
-\item {\tt wxMAJOR\_VERSION} is the major version of wxWindows
-\item {\tt wxMINOR\_VERSION} is the minor version of wxWindows
+\item {\tt wxMAJOR\_VERSION} is the major version of wxWidgets
+\item {\tt wxMINOR\_VERSION} is the minor version of wxWidgets
\item {\tt wxRELEASE\_NUMBER} is the release number
\end{itemize}
-For example, the values or these constants for wxWindows 2.1.15 are 2, 1 and
+For example, the values or these constants for wxWidgets 2.1.15 are 2, 1 and
15.
Additionally, {\tt wxVERSION\_STRING} is a user-readable string containing
-the full wxWindows version and {\tt wxVERSION\_NUMBER} is a combination of the
+the full wxWidgets version and {\tt wxVERSION\_NUMBER} is a combination of the
three version numbers above: for 2.1.15, it is 2115 and it is 2200 for
-wxWindows 2.2.
+wxWidgets 2.2.
\wxheading{Include files}
\func{bool}{wxCHECK\_VERSION}{\param{}{major, minor, release}}
-This is a macro which evaluates to true if the current wxWindows version is at
+This is a macro which evaluates to true if the current wxWidgets version is at
least major.minor.release.
-For example, to test if the program is compiled with wxWindows 2.2 or higher,
+For example, to test if the program is compiled with wxWidgets 2.2 or higher,
the following can be done:
\begin{verbatim}
\membersection{::wxEntry}\label{wxentry}
-This initializes wxWindows in a platform-dependent way. Use this if you
-are not using the default wxWindows entry code (e.g. main or WinMain). For example,
-you can initialize wxWindows from an Microsoft Foundation Classes application using
+This initializes wxWidgets in a platform-dependent way. Use this if you
+are not using the default wxWidgets entry code (e.g. main or WinMain). For example,
+you can initialize wxWidgets from an Microsoft Foundation Classes application using
this function.
\func{void}{wxEntry}{\param{HANDLE}{ hInstance}, \param{HANDLE}{ hPrevInstance},
\param{const wxString\& }{commandLine}, \param{int}{ cmdShow}, \param{bool}{ enterLoop = true}}
-wxWindows initialization under Windows (non-DLL). If {\it enterLoop} is false, the
-function will return immediately after calling wxApp::OnInit. Otherwise, the wxWindows
+wxWidgets initialization under Windows (non-DLL). If {\it enterLoop} is false, the
+function will return immediately after calling wxApp::OnInit. Otherwise, the wxWidgets
message loop will be entered.
\func{void}{wxEntry}{\param{HANDLE}{ hInstance}, \param{HANDLE}{ hPrevInstance},
\param{WORD}{ wDataSegment}, \param{WORD}{ wHeapSize}, \param{const wxString\& }{ commandLine}}
-wxWindows initialization under Windows (for applications constructed as a DLL).
+wxWidgets initialization under Windows (for applications constructed as a DLL).
\func{int}{wxEntry}{\param{int}{ argc}, \param{const wxString\& *}{argv}}
-wxWindows initialization under Unix.
+wxWidgets initialization under Unix.
\wxheading{Remarks}
-To clean up wxWindows, call wxApp::OnExit followed by the static function
-wxApp::CleanUp. For example, if exiting from an MFC application that also uses wxWindows:
+To clean up wxWidgets, call wxApp::OnExit followed by the static function
+wxApp::CleanUp. For example, if exiting from an MFC application that also uses wxWidgets:
\begin{verbatim}
int CTheApp::ExitInstance()
\func{wxAppDerivedClass\&}{wxGetApp}{\void}
-This function doesn't exist in wxWindows but it is created by using
+This function doesn't exist in wxWidgets but it is created by using
the \helpref{IMPLEMENT\_APP}{implementapp} macro. Thus, before using it
anywhere but in the same module where this macro is used, you must make it
available using \helpref{DECLARE\_APP}{declareapp}.
This function is used in wxBase only and only if you don't create
\helpref{wxApp}{wxapp} object at all. In this case you must call it from your
-{\tt main()} function before calling any other wxWindows functions.
+{\tt main()} function before calling any other wxWidgets functions.
If the function returns {\tt false} the initialization could not be performed,
in this case the library cannot be used and
This function is implemented for Win32,
Mac OS and generic Unix provided the system has {\tt statfs()} function.
-This function first appeared in wxWindows 2.3.2.
+This function first appeared in wxWidgets 2.3.2.
\membersection{::wxGetOSDirectory}\label{wxgetosdirectory}
Under Windows or NT, this function first looks in the environment
variable SYSTEM\_NAME; if this is not found, the entry {\bf HostName}\rtfsp
-in the {\bf wxWindows} section of the WIN.INI file is tried.
+in the {\bf wxWidgets} section of the WIN.INI file is tried.
The first variant of this function returns the hostname if successful or an
empty string otherwise. The second (deprecated) function returns true
Under Windows or NT, this function first looks in the environment
variables USER and LOGNAME; if neither of these is found, the entry {\bf UserId}\rtfsp
-in the {\bf wxWindows} section of the WIN.INI file is tried.
+in the {\bf wxWidgets} section of the WIN.INI file is tried.
The first variant of this function returns the login name if successful or an
empty string otherwise. The second (deprecated) function returns true
This function returns the full user name (something like "Mr. John Smith").
Under Windows or NT, this function looks for the entry {\bf UserName}\rtfsp
-in the {\bf wxWindows} section of the WIN.INI file. If PenWindows
+in the {\bf wxWidgets} section of the WIN.INI file. If PenWindows
is running, the entry {\bf Current} in the section {\bf User} of
the PENWIN.INI file is used.
\func{const wxChar *}{\_T}{\param{const wxChar }{ch}}
This macro is exactly the same as \helpref{wxT}{wxt} and is defined in
-wxWindows simply because it may be more intuitive for Windows programmers as
+wxWidgets simply because it may be more intuitive for Windows programmers as
the standard Win32 headers also define it (as well as yet another name for the
same macro which is {\tt \_TEXT()}).
SetWindowExt(dc, maxX - minX, maxY - minY);
\end{verbatim}
-This simulates the wxMM\_TEXT mapping mode, which wxWindows assumes.
+This simulates the wxMM\_TEXT mapping mode, which wxWidgets assumes.
Placeable metafiles may be imported by many Windows applications, and can be
used in RTF (Rich Text Format) files.
\func{void}{wxDDECleanUp}{\void}
-Called when wxWindows exits, to clean up the DDE system. This no longer needs to be
+Called when wxWidgets exits, to clean up the DDE system. This no longer needs to be
called by the application.
See also \helpref{wxDDEInitialize}{wxddeinitialize}.
Initializes the DDE system. May be called multiple times without harm.
This no longer needs to be called by the application: it will be called
-by wxWindows if necessary.
+by wxWidgets if necessary.
See also \helpref{wxDDEServer}{wxddeserver}, \helpref{wxDDEClient}{wxddeclient}, \helpref{wxDDEConnection}{wxddeconnection},\rtfsp
\helpref{wxDDECleanUp}{wxddecleanup}.
\section{RTTI functions}\label{rttimacros}
-wxWindows uses its own RTTI ("run-time type identification") system which
+wxWidgets uses its own RTTI ("run-time type identification") system which
predates the current standard C++ RTTI and so is kept for backwards
compatibility reasons but also because it allows some things which the
standard RTTI doesn't directly support (such as creating a class from its
The standard C++ RTTI can be used in the user code without any problems and in
general you shouldn't need to use the functions and the macros in this section
-unless you are thinking of modifying or adding any wxWindows classes.
+unless you are thinking of modifying or adding any wxWidgets classes.
\wxheading{See also}
\func{}{IMPLEMENT\_APP}{className}
This is used in the application class implementation file to make the application class known to
-wxWindows for dynamic construction. You use this instead of
+wxWidgets for dynamic construction. You use this instead of
Old form:
These functions provide a variety of logging functions: see \helpref{Log classes overview}{wxlogoverview} for
further information. The functions use (implicitly) the currently active log
target, so their descriptions here may not apply if the log target is not the
-standard one (installed by wxWindows in the beginning of the program).
+standard one (installed by wxWidgets in the beginning of the program).
\wxheading{Include files}
\membersection{::wxError}\label{wxerror}
-\func{void}{wxError}{\param{const wxString\& }{msg}, \param{const wxString\& }{title = "wxWindows Internal Error"}}
+\func{void}{wxError}{\param{const wxString\& }{msg}, \param{const wxString\& }{title = "wxWidgets Internal Error"}}
{\bf NB:} This function is now obsolete, please use \helpref{wxLogError}{wxlogerror}
instead.
Displays {\it msg} and continues. This writes to standard error under
Unix, and pops up a message box under Windows. Used for internal
-wxWindows errors. See also \helpref{wxFatalError}{wxfatalerror}.
+wxWidgets errors. See also \helpref{wxFatalError}{wxfatalerror}.
\wxheading{Include files}
\membersection{::wxFatalError}\label{wxfatalerror}
-\func{void}{wxFatalError}{\param{const wxString\& }{msg}, \param{const wxString\& }{title = "wxWindows Fatal Error"}}
+\func{void}{wxFatalError}{\param{const wxString\& }{msg}, \param{const wxString\& }{title = "wxWidgets Fatal Error"}}
{\bf NB:} This function is now obsolete, please use
\helpref{wxLogFatalError}{wxlogfatalerror} instead.
Displays {\it msg} and exits. This writes to standard error under Unix,
and pops up a message box under Windows. Used for fatal internal
-wxWindows errors. See also \helpref{wxError}{wxerror}.
+wxWidgets errors. See also \helpref{wxError}{wxerror}.
\wxheading{Include files}
\func{void}{wxVLogSysError}{\param{const char *}{formatString}, \param{va\_list }{argPtr}}
-Mostly used by wxWindows itself, but might be handy for logging errors after
+Mostly used by wxWidgets itself, but might be handy for logging errors after
system call (API function) failure. It logs the specified message text as well
as the last system error code ({\it errno} or {\it ::GetLastError()} depending
on the platform) and the corresponding error message. The second form
\helpref{AddTraceMask}{wxlogaddtracemask} or by setting
\helpref{{\tt WXTRACE} environment variable}{envvars}.
The predefined string trace masks
-used by wxWindows are:
+used by wxWidgets are:
\begin{itemize}\itemsep=0pt
\item wxTRACE\_MemAlloc: trace memory allocation (new/delete)
\section{Debugging macros and functions}\label{debugmacros}
Useful macros and functions for error checking and defensive programming.
-wxWindows defines three families of the assert-like macros:
+wxWidgets defines three families of the assert-like macros:
the wxASSERT and wxFAIL macros only do anything if \_\_WXDEBUG\_\_ is defined
(in other words, in the debug build) but disappear completely in the release
build. On the other hand, the wxCHECK macros stay event in release builds but a
\docparam{id}{Window identifier. If -1, will automatically create an identifier.}
-\docparam{pos}{Window position. wxDefaultPosition is (-1, -1) which indicates that wxWindows
+\docparam{pos}{Window position. wxDefaultPosition is (-1, -1) which indicates that wxWidgets
should generate a default position for the window.}
-\docparam{size}{Window size. wxDefaultSize is (-1, -1) which indicates that wxWindows should
+\docparam{size}{Window size. wxDefaultSize is (-1, -1) which indicates that wxWidgets should
generate a default size for the window. If no suitable size can be found, the window will be sized to 20x20 pixels so that the window is visible but obviously not correctly sized.}
\docparam{style}{Window style.}
\func{void}{SetColour}{\param{const char*}{ colour}}
-Sets the current colour for this window, using the wxWindows colour database to find a named colour.
+Sets the current colour for this window, using the wxWidgets colour database to find a named colour.
\membersection{wxGLCanvas::SwapBuffers}\label{wxglcanvasswapbuffers}
relationship between the various grid classes and has a summary of the
keyboard shortcuts and mouse functions provided by wxGrid.
-wxGrid has been greatly expanded and redesigned for wxWindows 2.2
+wxGrid has been greatly expanded and redesigned for wxWidgets 2.2
onwards. If you have been using the old wxGrid class you will probably
want to have a look at the \helpref{wxGrid classes overview}{gridoverview} to see
how things have changed. The new grid classes are reasonably backward-compatible
{\bf Please note} that this class is retained for backward compatibility
reasons; you should use \helpref{wxHashMap}{wxhashmap}.
-This class provides hash table functionality for wxWindows, and for an
+This class provides hash table functionality for wxWidgets, and for an
application if it wishes. Data can be hashed on an integer or string
key.
\end{verbatim}
The HASH\_T and KEY\_EQ\_T are the types
-used for the hashing function and key comparison. wxWindows provides
+used for the hashing function and key comparison. wxWidgets provides
three predefined hashing functions: {\tt wxIntegerHash}
for integer types ( {\tt int}, {\tt long}, {\tt short},
and their unsigned counterparts ), {\tt wxStringHash} for strings
window hierarchy until the event is processed or there are no more event handlers.
The application should call wxEvent::GetId to check the identity of the clicked-on window,
and then either show some suitable help or call wxEvent::Skip if the identifier is unrecognised.
-Calling Skip is important because it allows wxWindows to generate further events for ancestors
+Calling Skip is important because it allows wxWidgets to generate further events for ancestors
of the clicked-on window. Otherwise it would be impossible to show help for container windows,
since processing would stop after the first window found.
\begin{itemize}\itemsep=0pt
\item On Windows, wxWinHelpController is used.
\item On all other platforms, wxHtmlHelpController is used if wxHTML is
-compiled into wxWindows; otherwise wxExtHelpController is used (for invoking an external
+compiled into wxWidgets; otherwise wxExtHelpController is used (for invoking an external
browser).
\end{itemize}
\item wxWinHelpController, for controlling Windows Help.
\item wxCHMHelpController, for controlling MS HTML Help. To use this, you need to set wxUSE\_MS\_HTML\_HELP
to 1 in setup.h and have htmlhelp.h header from Microsoft's HTML Help kit (you don't need
-VC++ specific htmlhelp.lib because wxWindows loads necessary DLL at runtime and so it
+VC++ specific htmlhelp.lib because wxWidgets loads necessary DLL at runtime and so it
works with all compilers).
\item wxBestHelpController, for controlling MS HTML Help or, if Microsoft's runtime is
not available, \helpref{wxHtmlHelpController}{wxhtmlhelpcontroller}. You need to provide
\wxheading{Include files}
-<wx/help.h> (wxWindows chooses the appropriate help controller class)\\
+<wx/help.h> (wxWidgets chooses the appropriate help controller class)\\
<wx/helpbase.h> (wxHelpControllerBase class)\\
<wx/helpwin.h> (Windows Help controller)\\
<wx/msw/helpchm.h> (MS HTML Help controller)\\
\section{\class{wxHtmlHelpController}}\label{wxhtmlhelpcontroller}
-{\bf WARNING!} Although this class has an API compatible with other wxWindows
+{\bf WARNING!} Although this class has an API compatible with other wxWidgets
help controllers as documented by \helpref{wxHelpController}{wxhelpcontroller}, it
is recommended that you use the enhanced capabilities of wxHtmlHelpController's API.
application (see {\it test} sample). The help system is based on {\bf books}
(see \helpref{AddBook}{wxhtmlhelpcontrolleraddbook}). A book is a logical
section of documentation (for example "User's Guide" or "Programmer's Guide" or
-"C++ Reference" or "wxWindows Reference"). The help controller can handle as
+"C++ Reference" or "wxWidgets Reference"). The help controller can handle as
many books as you want.
wxHTML uses Microsoft's HTML Help Workshop project files (.hhp, .hhk, .hhc) as its
%% Created: 01.06.03
%% RCS-ID: $Id$
%% Copyright: (c) 2003 Vadim Zeitlin <vadim@wxwindows.org>
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxHtmlListBox}}\label{wxhtmllistbox}
The easiest way to print an HTML document is to use
\helpref{wxHtmlEasyPrinting class}{wxhtmleasyprinting}. It lets you print HTML documents with only one
command and you don't have to worry about deriving from the wxPrintout class at all. It is only a simple wrapper around the
-\helpref{wxHtmlPrintout}{wxhtmlprintout}, normal wxWindows printout class.
+\helpref{wxHtmlPrintout}{wxhtmlprintout}, normal wxWidgets printout class.
And finally there is the low level class \helpref{wxHtmlDCRenderer}{wxhtmldcrenderer} which you can use to
render HTML into a rectangular area on any DC. It supports rendering into multiple rectangles with the same
-\section{wxWindows Hello World sample}\label{helloworld}
+\section{wxWidgets Hello World sample}\label{helloworld}
As many people have requested a mini-sample to be published here
so that some quick judgment concerning syntax
-and basic principles can be made, you can now look at wxWindows'
+and basic principles can be made, you can now look at wxWidgets'
"Hello World":
-You have to include wxWindows' header files, of course. This can
+You have to include wxWidgets' header files, of course. This can
be done on a file by file basis (such as \#include "wx/window.h")
or using one global include (\#include "wx/wx.h"). This is
also useful on platforms which support precompiled headers such
//
// file name: hworld.cpp
//
-// purpose: wxWindows "Hello world"
+// purpose: wxWidgets "Hello world"
//
// For compilers that support precompilation, includes "wx/wx.h".
END_EVENT_TABLE()
\end{verbatim}
-As in all programs there must be a "main" function. Under wxWindows main is implemented
+As in all programs there must be a "main" function. Under wxWidgets main is implemented
using this macro, which creates an application instance and starts the program.
\begin{verbatim}
SetMenuBar( menuBar );
CreateStatusBar();
- SetStatusText( "Welcome to wxWindows!" );
+ SetStatusText( "Welcome to wxWidgets!" );
}
\end{verbatim}
\begin{verbatim}
void MyFrame::OnAbout(wxCommandEvent& WXUNUSED(event))
{
- wxMessageBox( "This is a wxWindows' Hello world sample",
+ wxMessageBox( "This is a wxWidgets' Hello world sample",
"About Hello World", wxOK | wxICON_INFORMATION );
}
\end{verbatim}
%\twocolitem{\indexit{wxBITMAP\_TYPE\_RESOURCE}}{Load a Windows resource name.}
\end{twocollist}
-The validity of these flags depends on the platform and wxWindows configuration.
-If all possible wxWindows settings are used, the Windows platform supports ICO file, ICO resource,
+The validity of these flags depends on the platform and wxWidgets configuration.
+If all possible wxWidgets settings are used, the Windows platform supports ICO file, ICO resource,
XPM data, and XPM file. Under wxGTK, the available formats are BMP file, XPM data, XPM file, and PNG file.
Under wxMotif, the available formats are XBM data, XBM file, XPM data, XPM file.}
The sixth form constructs a new icon.
-The seventh form constructs an icon from pixmap (XPM) data, if wxWindows has been configured
+The seventh form constructs an icon from pixmap (XPM) data, if wxWidgets has been configured
to incorporate this feature.
To use this constructor, you must first include an XPM file. For
data be deleted.
If the application omits to delete the icon explicitly, the icon will be
-destroyed automatically by wxWindows when the application exits.
+destroyed automatically by wxWidgets when the application exits.
Do not delete an icon that is selected into a memory device context.
\twocolitem{{\bf wxBITMAP\_TYPE\_XPM}}{Load an XPM bitmap file.}
\end{twocollist}
-The validity of these flags depends on the platform and wxWindows configuration.}
+The validity of these flags depends on the platform and wxWidgets configuration.}
\wxheading{Return value}
\twocolitem{{\bf wxBITMAP\_TYPE\_XPM}}{Save an XPM bitmap file.}
\end{twocollist}
-The validity of these flags depends on the platform and wxWindows configuration.}
+The validity of these flags depends on the platform and wxWidgets configuration.}
\docparam{palette}{An optional palette used for saving the icon.}
\wxheading{Remarks}
-Depending on how wxWindows has been configured, not all formats may be available.
+Depending on how wxWidgets has been configured, not all formats may be available.
\wxheading{See also}
%% Created:
%% RCS-ID: $Id$
%% Copyright: (c) 2001 Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxIconizeEvent}}\label{wxiconizeevent}
%% Created: 21.06.03
%% RCS-ID: $Id$
%% Copyright: (c) 2003 Vadim Zeitlin <vadim@wxwindows.org>
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxIconLocation}}\label{wxiconlocation}
\func{static wxIdleMode}{GetMode}{\void}
-Static function returning a value specifying how wxWindows
+Static function returning a value specifying how wxWidgets
will send idle events: to all windows, or only to those which specify that they
will process the events.
\func{void}{RequestMore}{\param{bool}{ needMore = true}}
-Tells wxWindows that more processing is required. This function can be called by an OnIdle
+Tells wxWidgets that more processing is required. This function can be called by an OnIdle
handler for a window or window event handler to indicate that wxApp::OnIdle should
forward the OnIdle event once more to the application windows. If no window calls this function
during OnIdle, then the application will remain in a passive event loop (not calling OnIdle) until a
\func{static void}{SetMode}{\param{wxIdleMode }{mode}}
-Static function for specifying how wxWindows will send idle events: to
+Static function for specifying how wxWidgets will send idle events: to
all windows, or only to those which specify that they
will process the events.
\wxheading{Alpha channel support}
-Starting from wxWindows 2.5.0 wxImage supports alpha channel data, that is in
+Starting from wxWidgets 2.5.0 wxImage supports alpha channel data, that is in
addition to a byte for the red, green and blue colour components for each pixel
it also stores a byte representing the pixel opacity. The alpha value of $0$
corresponds to a transparent pixel (null opacity) while the value of $255$
\wxheading{Remarks}
-Depending on how wxWindows has been configured, not all formats may be available.
+Depending on how wxWidgets has been configured, not all formats may be available.
Note: any handler other than BMP must be previously
initialized with \helpref{wxImage::AddHandler}{wximageaddhandler} or
Deletes all image handlers.
-This function is called by wxWindows on exit.
+This function is called by wxWidgets on exit.
\membersection{wxImage::ComputeHistogram}\label{wximagecomputehistogram}
Internal use only. Adds standard image format handlers. It only install BMP
for the time being, which is used by wxBitmap.
-This function is called by wxWindows on startup, and shouldn't be called by
+This function is called by wxWidgets on startup, and shouldn't be called by
the user.
\wxheading{See also}
\wxheading{Remarks}
-Depending on how wxWindows has been configured, not all formats may be available.
+Depending on how wxWidgets has been configured, not all formats may be available.
Note: you can use \helpref{GetOptionInt}{wximagegetoptionint} to get the
hotspot for loaded cursor file:
\wxheading{Remarks}
-Depending on how wxWindows has been configured, not all formats may be available.
+Depending on how wxWidgets has been configured, not all formats may be available.
Note: you can use \helpref{GetOptionInt}{wximagegetoptionint} to set the
hotspot before saving an image into a cursor file (default hotspot is in
This software is based in part on the work of the Independent JPEG Group.
-(Applies when wxWindows is linked with JPEG support. wxJPEGHandler uses libjpeg
+(Applies when wxWidgets is linked with JPEG support. wxJPEGHandler uses libjpeg
created by IJG.)
\wxheading{Derived from}
This event class contains information about keypress (character) events.
-Notice that there are three different kinds of keyboard events in wxWindows:
+Notice that there are three different kinds of keyboard events in wxWidgets:
key down and up events and char events. The difference between the first two
is clear - the first corresponds to a key press and the second to a key
release - otherwise they are identical. Just note that if the key is
$1$, the ASCII value of this key combination.
You may discover how the other keys on your system behave interactively by
-running the \helpref{text}{sampletext} wxWindows sample and pressing some keys
+running the \helpref{text}{sampletext} wxWidgets sample and pressing some keys
in any of the text controls shown in it.
{\bf Note:} If a key down ({\tt EVT\_KEY\_DOWN}) event is caught and
enables the programs that handle both types of events to be a bit
simpler.
-{\bf Note for Windows programmers:} The key and char events in wxWindows are
+{\bf Note for Windows programmers:} The key and char events in wxWidgets are
similar to but slightly different from Windows {\tt WM\_KEYDOWN} and
{\tt WM\_CHAR} events. In particular, Alt-x combination will generate a char
-event in wxWindows (unless it is used as an accelerator).
+event in wxWidgets (unless it is used as an accelerator).
{\bf Tip:} be sure to call {\tt event.Skip()} for events that you don't process in
key event function, otherwise menu shortcuts may cease to work under Windows.
\setheader{{\it CHAPTER \thechapter}}{}{}{}{}{{\it CHAPTER \thechapter}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
-Starting from version 2.5.0 wxWindows can be built either as a single large
+Starting from version 2.5.0 wxWidgets can be built either as a single large
library (this is called the {\it monolithic build}) or as several smaller
libraries ({\it multilib build}). Multilib build is the default.
-wxWindows library is divided into libraries briefly described below. This
+wxWidgets library is divided into libraries briefly described below. This
diagram show dependencies between them:
\begin{center}
{\large {\bf wxBase}}
-Every wxWindows application must link against this library. It contains
-mandatory classes that any wxWindows code depends on (e.g.
+Every wxWidgets application must link against this library. It contains
+mandatory classes that any wxWidgets code depends on (e.g.
\helpref{wxString}{wxstring}) and portability classes that abstract
differences between platforms. wxBase can be used to develop console mode
applications, it does not require any GUI libraries or running X Window System
their API {\em will} change in the future and backward
compatibility will not be preserved. Use of this library in your applications
is not recommended, it is only meant for use by XML resources system. Future
-versions of wxWindows will contain new XML handling classes with DOM-like API.
+versions of wxWidgets will contain new XML handling classes with DOM-like API.
Requires wxBase.
{\large {\bf wxCore}}
Basic GUI classes such as GDI classes or controls are in this library. All
-wxWindows GUI applications must link against this library, only console mode
+wxWidgets GUI applications must link against this library, only console mode
applications don't.
{\large {\bf wxAdvanced}}
{\large {\bf wxGL}}
This library contains \helpref{wxGLCanvas}{wxglcanvas} class for integrating
-OpenGL library with wxWindows. Unlike all others, this library is {\em not}
+OpenGL library with wxWidgets. Unlike all others, this library is {\em not}
part of the monolithic library, it is always built as separate library.
Requires wxCore and wxBase.
\section{\class{wxList}}\label{wxlist}
-wxList classes provide linked list functionality for wxWindows, and for an
+wxList classes provide linked list functionality for wxWidgets, and for an
application if it wishes. Depending on the form of constructor used, a list
can be keyed on integer or string keys to provide a primitive look-up ability,
but please note that this feature is {\bf deprecated}.
See \helpref{wxHashMap}{wxhashmap}\rtfsp for a faster method of storage
when random access is required.
-While wxList class in the previous versions of wxWindows only could contain
+While wxList class in the previous versions of wxWidgets only could contain
elements of type wxObject and had essentially untyped interface (thus allowing
you to put apples in the list and read back oranges from it), the new wxList
classes family may contain elements of any type and has much more strict type
checking. Unfortunately, it also requires an additional line to be inserted in
your program for each list class you use (which is the only solution short of
-using templates which is not done in wxWindows because of portability issues).
+using templates which is not done in wxWidgets because of portability issues).
The general idea is to have the base class wxListBase working with {\it void *}
data but make all of its dangerous (because untyped) functions protected, so
%% Created: 22.08.03
%% RCS-ID: $Id$
%% Copyright: (c) 2003 Vadim Zeitlin <vadim@wxwindows.org>
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxListbook}}\label{wxlistbook}
%% Created: 07.11.02
%% RCS-ID: $Id$
%% Copyright: (c) 2002 Vadim Zeitlin <vadim@wxwindows.org>
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxListView}}\label{wxlistview}
wxLocale class encapsulates all language-dependent settings and is a
generalization of the C locale concept.
-In wxWindows this class manages message catalogs which contain the translations
+In wxWidgets this class manages message catalogs which contain the translations
of the strings used to the current language.
\perlnote{In wxPerl you can't use the '\_' function name, so
\docparam{flags}{Combination of the following:
\begin{twocollist}\itemsep=0pt
\twocolitem{\windowstyle{wxLOCALE\_LOAD\_DEFAULT}}{Load the message catalog
-for the given locale containing the translations of standard wxWindows messages
+for the given locale containing the translations of standard wxWidgets messages
automatically.}
\twocolitem{\windowstyle{wxLOCALE\_CONV\_ENCODING}}{Automatically convert message
catalogs to platform's default encoding. Note that it will do only basic
platform-specific.}
\docparam{bLoadDefault}{May be set to false to prevent loading of the message catalog
-for the given locale containing the translations of standard wxWindows messages.
+for the given locale containing the translations of standard wxWidgets messages.
This parameter would be rarely used in normal circumstances.}
\docparam{bConvertEncoding}{May be set to true to do automatic conversion of message
%% Created: some time ago
%% RCS-ID: $Id$
%% Copyright: (c) 1997-2001 Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxLog}}\label{wxlog}
-wxLog class defines the interface for the {\it log targets} used by wxWindows
+wxLog class defines the interface for the {\it log targets} used by wxWidgets
logging functions as explained in the \helpref{wxLog overview}{wxlogoverview}.
The only situations when you need to directly use this class is when you want
to derive your own log target because the existing ones don't satisfy your
Otherwise, it is completely hidden behind the {\it wxLogXXX()} functions and
you may not even know about its existence.
-See \helpref{log overview}{wxlogoverview} for the descriptions of wxWindows
+See \helpref{log overview}{wxlogoverview} for the descriptions of wxWidgets
logging facilities.
\wxheading{Derived from}
\section{\class{wxLogGui}}\label{wxloggui}
-This is the default log target for the GUI wxWindows applications. It is passed
+This is the default log target for the GUI wxWidgets applications. It is passed
to \helpref{wxLog::SetActiveTarget}{wxlogsetactivetarget} at the program
-startup and is deleted by wxWindows during the program shut down.
+startup and is deleted by wxWidgets during the program shut down.
\wxheading{Derived from}
This class allows to temporarily suspend logging. All calls to the log
functions during the life time of an object of this class are just ignored.
-In particular, it can be used to suppress the log messages given by wxWindows
+In particular, it can be used to suppress the log messages given by wxWidgets
itself but it should be noted that it is rarely the best way to cope with this
problem as {\bf all} log messages are suppressed, even if they indicate a
completely different error than the one the programmer wanted to suppress.
This class can be used to redirect the log messages to a C file stream (not to
be confused with C++ streams). It is the default log target for the non-GUI
-wxWindows applications which send all the output to {\tt stderr}.
+wxWidgets applications which send all the output to {\tt stderr}.
\wxheading{Derived from}
This class can be used to redirect the log messages to a C++ stream.
-Please note that this class is only available if wxWindows was compiled with
+Please note that this class is only available if wxWidgets was compiled with
the standard iostream library support ({\tt wxUSE\_STD\_IOSTREAM} must be on).
\wxheading{Derived from}
%% Created: 07.03.00
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxLongLong}}\label{wxlonglong}
%\special{!/@scaleunit 1 def}
\parskip=10pt
\parindent=0pt
-\title{wxWindows 2.5.1: A portable C++ and Python GUI toolkit}
+\title{wxWidgets 2.5.1: A portable C++ and Python GUI toolkit}
\winhelponly{\author{by Julian Smart et al
%\winhelponly{\\$$\image{1cm;0cm}{wxwin.wmf}$$}
}}
% A special table of contents for the WinHelp manual
\begin{comment}
\winhelponly{
-\chapter{wxWindows class library reference}\label{winhelpcontents}
+\chapter{wxWidgets class library reference}\label{winhelpcontents}
\centerline{
%\image{}{wxwin.wmf}
\image{}{book1.bmp} \helpref{Topic overviews}{overviews}
-\image{}{hand1.bmp} \helpref{Guide to wxWindows}{wxwinchapters}
+\image{}{hand1.bmp} \helpref{Guide to wxWidgets}{wxwinchapters}
}
\sethotspotcolour{on}%
\sethotspotunderline{on}%
-\chapter*{Overview of wxWindows}\label{wxwinchapters}
+\chapter*{Overview of wxWidgets}\label{wxwinchapters}
\helpref{Introduction}{introduction}\\
%\helpref{Resource guide}{resguide}\\
%\helpref{Comparison with other GUI models}{comparison}\\
-%\helpref{Multi-platform development with wxWindows}{multiplat}\\
+%\helpref{Multi-platform development with wxWidgets}{multiplat}\\
%\helpref{Tutorial}{tutorial}\\
-\helpref{The wxWindows resource system}{resourceformats}\\
+\helpref{The wxWidgets resource system}{resourceformats}\\
\helpref{Utilities}{utilities}\\
\helpref{Programming strategies}{strategies}\\
\helpref{Bugs and future directions}{bugs}\\
\begin{center}
Copyright (c) 1992-2002 Julian Smart, Robert Roebling, Vadim Zeitlin and other
-members of the wxWindows team\\
+members of the wxWidgets team\\
Portions (c) 1996 Artificial Intelligence Applications Institute\\
\end{center}
-Please also see the wxWindows license files (preamble.txt, lgpl.txt, gpl.txt, license.txt,
+Please also see the wxWidgets license files (preamble.txt, lgpl.txt, gpl.txt, license.txt,
licendoc.txt) for conditions of software and documentation use.
-\section*{wxWindows Library License, Version 3}
+\section*{wxWidgets Library License, Version 3}
Copyright (c) 1992-2004 Julian Smart, Robert Roebling, Vadim Zeitlin et al.
1. As a special exception, the copyright holders of this library give
permission for additional uses of the text contained in this release of
-the library as licensed under the wxWindows Library License, applying
+the library as licensed under the wxWidgets Library License, applying
either version 3 of the License, or (at your option) any later version of
the License as published by the copyright holders of version 3 of the
License document.
%\special{!/@scaleunit 1 def}
\parskip=10pt
\parindent=0pt
-\title{wxWindows 2.4.1: A portable C++ and Python GUI toolkit}
+\title{wxWidgets 2.4.1: A portable C++ and Python GUI toolkit}
\winhelponly{\author{by Julian Smart et al
%\winhelponly{\\$$\image{1cm;0cm}{wxwin.wmf}$$}
}}
% A special table of contents for the WinHelp manual
\begin{comment}
\winhelponly{
-\chapter{wxWindows class library reference}\label{winhelpcontents}
+\chapter{wxWidgets class library reference}\label{winhelpcontents}
\centerline{
%\image{}{wxwin.wmf}
\image{}{book1.bmp} \helpref{Topic overviews}{overviews}
-\image{}{hand1.bmp} \helpref{Guide to wxWindows}{wxwinchapters}
+\image{}{hand1.bmp} \helpref{Guide to wxWidgets}{wxwinchapters}
}
\sethotspotcolour{on}%
\sethotspotunderline{on}%
-\chapter*{Overview of wxWindows}\label{wxwinchapters}
+\chapter*{Overview of wxWidgets}\label{wxwinchapters}
\helpref{Introduction}{introduction}\\
%\helpref{Resource guide}{resguide}\\
%\helpref{Comparison with other GUI models}{comparison}\\
-%\helpref{Multi-platform development with wxWindows}{multiplat}\\
+%\helpref{Multi-platform development with wxWidgets}{multiplat}\\
%\helpref{Tutorial}{tutorial}\\
-\helpref{The wxWindows resource system}{resourceformats}\\
+\helpref{The wxWidgets resource system}{resourceformats}\\
\helpref{Utilities}{utilities}\\
\helpref{Programming strategies}{strategies}\\
\helpref{Bugs and future directions}{bugs}\\
\begin{center}
Copyright (c) 1992-2002 Julian Smart, Robert Roebling, Vadim Zeitlin and other
-members of the wxWindows team\\
+members of the wxWidgets team\\
Portions (c) 1996 Artificial Intelligence Applications Institute\\
\end{center}
-Please also see the wxWindows license files (preamble.txt, lgpl.txt, gpl.txt, license.txt,
+Please also see the wxWidgets license files (preamble.txt, lgpl.txt, gpl.txt, license.txt,
licendoc.txt) for conditions of software and documentation use.
-\section*{wxWindows Library License, Version 3}
+\section*{wxWidgets Library License, Version 3}
Copyright (c) 1992-2002 Julian Smart, Robert Roebling, Vadim Zeitlin et al.
1. As a special exception, the copyright holders of this library give
permission for additional uses of the text contained in this release of
-the library as licensed under the wxWindows Library License, applying
+the library as licensed under the wxWidgets Library License, applying
either version 3 of the License, or (at your option) any later version of
the License as published by the copyright holders of version 3 of the
License document.
%% Created:
%% RCS-ID: $Id$
%% Copyright: (c) 2001 Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxMaximizeEvent}}\label{wxmaximizeevent}
\constfunc{wxWindow*}{GetCapturedWindow}{\void}
-Returns the window that gained the capture, or NULL if it was a non-wxWindows window.
+Returns the window that gained the capture, or NULL if it was a non-wxWidgets window.
\wxheading{Remarks}
-Although internally an MDI child frame is a child of the MDI client window, in wxWindows
+Although internally an MDI child frame is a child of the MDI client window, in wxWidgets
you create it as a child of \helpref{wxMDIParentFrame}{wxmdiparentframe}. You can usually
forget that the client window exists.
\docparam{title}{The caption to be displayed on the frame's title bar.}
\docparam{pos}{The window position. A value of (-1, -1) indicates a default position, chosen by
-either the windowing system or wxWindows, depending on platform.}
+either the windowing system or wxWidgets, depending on platform.}
\docparam{size}{The window size. A value of (-1, -1) indicates a default size, chosen by
-either the windowing system or wxWindows, depending on platform.}
+either the windowing system or wxWidgets, depending on platform.}
\docparam{style}{The window style. See \helpref{wxMDIChildFrame}{wxmdichildframe}.}
\docparam{title}{The caption to be displayed on the frame's title bar.}
\docparam{pos}{The window position. A value of (-1, -1) indicates a default position, chosen by
-either the windowing system or wxWindows, depending on platform.}
+either the windowing system or wxWidgets, depending on platform.}
\docparam{size}{The window size. A value of (-1, -1) indicates a default size, chosen by
-either the windowing system or wxWindows, depending on platform.}
+either the windowing system or wxWidgets, depending on platform.}
\docparam{style}{The window style. See \helpref{wxMDIParentFrame}{wxmdiparentframe}.}
\constfunc{wxMenu*}{GetWindowMenu}{\void}
-Returns the current Window menu (added by wxWindows to the menubar). This function
+Returns the current Window menu (added by wxWidgets to the menubar). This function
is available under Windows only.
\membersection{wxMDIParentFrame::OnCreateClient}\label{wxmdiparentframeoncreateclient}
Menu items may be either normal items, check items or radio items. Normal items
don't have any special properties while the check items have a boolean flag
associated to them and they show a checkmark in the menu when the flag is set.
-wxWindows automatically toggles the flag value when the item is clicked and its
+wxWidgets automatically toggles the flag value when the item is clicked and its
value may be retrieved using either \helpref{IsChecked}{wxmenuischecked} method
of wxMenu or wxMenuBar itself or by using
\helpref{wxEvent::IsChecked}{wxcommandeventischecked} when you get the menu
\section{\class{wxMetafile}}\label{wxmetafile}
A {\bf wxMetafile} represents the MS Windows metafile object, so metafile
-operations have no effect in X. In wxWindows, only sufficient functionality
+operations have no effect in X. In wxWidgets, only sufficient functionality
has been provided for copying a graphic to the clipboard; this may be extended
in a future version. Presently, the only way of creating a metafile
is to use a wxMetafileDC.
\docparam{title}{The caption to be displayed on the frame's title bar.}
\docparam{pos}{The window position. A value of (-1, -1) indicates a default position, chosen by
-either the windowing system or wxWindows, depending on platform.}
+either the windowing system or wxWidgets, depending on platform.}
\docparam{size}{The window size. A value of (-1, -1) indicates a default size, chosen by
-either the windowing system or wxWindows, depending on platform.}
+either the windowing system or wxWidgets, depending on platform.}
\docparam{style}{The window style. See \helpref{wxMiniFrame}{wxminiframe}.}
%% Created: 21.07.03
%% RCS-ID: $Id$
%% Copyright: (c) 2003 Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxMirrorDC}}\label{wxmirrordc}
coordinates which makes it possible to reuse the same code to draw a figure and
its mirror -- i.e. reflection related to the diagonal line $x == y$.
-wxMirrorDC has been added in wxWindows version 2.5.0.
+wxMirrorDC has been added in wxWidgets version 2.5.0.
\wxheading{Derived from}
\section{\class{wxModule}}\label{wxmodule}
-The module system is a very simple mechanism to allow applications (and parts of wxWindows itself) to
-define initialization and cleanup functions that are automatically called on wxWindows
+The module system is a very simple mechanism to allow applications (and parts of wxWidgets itself) to
+define initialization and cleanup functions that are automatically called on wxWidgets
startup and exit.
To define a new kind of module, derive a class from wxModule, override the OnInit and OnExit functions,
and add the DECLARE\_DYNAMIC\_CLASS and IMPLEMENT\_DYNAMIC\_CLASS to header and implementation files
-(which can be the same file). On initialization, wxWindows will find all classes derived from wxModule,
-create an instance of each, and call each OnInit function. On exit, wxWindows will call the OnExit
+(which can be the same file). On initialization, wxWidgets will find all classes derived from wxModule,
+create an instance of each, and call each OnInit function. On exit, wxWidgets will call the OnExit
function for each module instance.
Note that your module class does not have to be in a header file.
\func{static void}{CleanupModules}{\void}
-Calls Exit for each module instance. Called by wxWindows on exit, so there is no
+Calls Exit for each module instance. Called by wxWidgets on exit, so there is no
need for an application to call it.
\membersection{wxModule::Exit}\label{wxmoduleexit}
\func{void}{Exit}{\void}
-Calls OnExit. This function is called by wxWindows and should not need to be called
+Calls OnExit. This function is called by wxWidgets and should not need to be called
by an application.
\membersection{wxModule::Init}\label{wxmoduleinit}
\func{bool}{Init}{\void}
-Calls OnInit. This function is called by wxWindows and should not need to be called
+Calls OnInit. This function is called by wxWidgets and should not need to be called
by an application.
\membersection{wxModule::InitializeModules}\label{wxmoduleinitializemodules}
\func{static bool}{InitializeModules}{\void}
-Calls Init for each module instance. Called by wxWindows on startup, so there is no
+Calls Init for each module instance. Called by wxWidgets on startup, so there is no
need for an application to call it.
\membersection{wxModule::OnExit}\label{wxmoduleonexit}
\func{virtual bool}{OnInit}{\void}
Provide this function with appropriate initialization for your module. If the function
-returns false, wxWindows will exit immediately.
+returns false, wxWidgets will exit immediately.
\membersection{wxModule::RegisterModule}\label{wxmoduleregistermodule}
\func{static void}{RegisterModule}{\param{wxModule*}{ module}}
-Registers this module with wxWindows. Called by wxWindows on startup, so there is no
+Registers this module with wxWidgets. Called by wxWidgets on startup, so there is no
need for an application to call it.
\membersection{wxModule::RegisterModules}\label{wxmoduleregistermodules}
\func{static bool}{RegisterModules}{\void}
-Creates instances of and registers all modules. Called by wxWindows on startup, so there is no
+Creates instances of and registers all modules. Called by wxWidgets on startup, so there is no
need for an application to call it.
it.
{\bf NB:} Note that under Windows mouse enter and leave events are not natively supported
-by the system but are generated by wxWindows itself. This has several
+by the system but are generated by wxWidgets itself. This has several
drawbacks: the LEAVE\_WINDOW event might be received some time after the mouse
left the window and the state variables for it may have changed during this
time.
whether the left mouse button is (still) depressed. Also, by convention, if
\helpref{LeftDown}{wxmouseeventleftdown} returns {\tt true},
\helpref{LeftIsDown}{wxmouseeventleftisdown} will also return {\tt true} in
-wxWindows whatever the underlying GUI behaviour is (which is
+wxWidgets whatever the underlying GUI behaviour is (which is
platform-dependent). The same applies, of course, to other mouse buttons as
well.
\func{}{wxNotebookEvent}{\param{wxEventType}{ eventType = wxEVT\_NULL},
\param{int}{ id = 0}, \param{int}{ sel = $-1$}, \param{int}{ oldSel = $-1$}}
-Constructor (used internally by wxWindows only).
+Constructor (used internally by wxWidgets only).
\membersection{wxNotebookEvent::GetOldSelection}\label{wxnotebookeventgetoldselection}
\func{}{wxNotifyEvent}{\param{wxEventType}{ eventType = wxEVT\_NULL}, \param{int}{ id = 0}}
-Constructor (used internally by wxWindows only).
+Constructor (used internally by wxWidgets only).
\membersection{wxNotifyEvent::Allow}\label{wxnotifyeventallow}
\section{\class{wxObject}}\label{wxobject}
-This is the root class of all wxWindows classes.
+This is the root class of all wxWidgets classes.
It declares a virtual destructor which ensures that
destructors get called for all derived class objects where necessary.
\wxheading{Remarks}
-Currently wxWindows does not define Dump for derived classes, but
+Currently wxWidgets does not define Dump for derived classes, but
programmers may wish to use it for their own applications. Be sure to
call the Dump member of the class's base class to allow all information to be
dumped.
\section{\class{wxPageSetupDialog}}\label{wxpagesetupdialog}
This class represents the page setup common dialog. The page setup dialog is standard from
-Windows 95 on, replacing the print setup dialog (which is retained in Windows and wxWindows
+Windows 95 on, replacing the print setup dialog (which is retained in Windows and wxWidgets
for backward compatibility). On Windows 95 and NT 4.0 and above, the page setup dialog is
native to the windowing system, otherwise it is emulated.
\docparam{id}{An identifier for the panel. A value of -1 is taken to mean a default.}
\docparam{pos}{The panel position. A value of (-1, -1) indicates a default position, chosen by
-either the windowing system or wxWindows, depending on platform.}
+either the windowing system or wxWidgets, depending on platform.}
\docparam{size}{The panel size. A value of (-1, -1) indicates a default size, chosen by
-either the windowing system or wxWindows, depending on platform.}
+either the windowing system or wxWidgets, depending on platform.}
\docparam{style}{The window style. See \helpref{wxPanel}{wxpanel}.}
\wxheading{Remarks}
-On a monochrome display, wxWindows shows all non-white pens as black.
+On a monochrome display, wxWidgets shows all non-white pens as black.
Do not initialize objects on the stack before the program commences,
since other required structures may not have been set up yet. Instead,
Although all remaining pens are deleted when the application exits,
the application should try to clean up all pens itself. This is because
-wxWindows cannot know if a pointer to the pen object is stored in an
+wxWidgets cannot know if a pointer to the pen object is stored in an
application data structure, and there is a risk of double deletion.
\membersection{wxPen::GetCap}\label{wxpengetcap}
`memory leaks'. However, it is best not to rely on this automatic
cleanup because it can lead to double deletion in some circumstances.
-There are two mechanisms in recent versions of wxWindows which make the
+There are two mechanisms in recent versions of wxWidgets which make the
pen list less useful than it once was. Under Windows, scarce resources
are cleaned up internally if they are not being used. Also, a referencing
counting mechanism applied to all GDI objects means that some sharing
your application is using too many resources, you can resort to using
GDI lists to share objects explicitly.
-The only compelling use for the pen list is for wxWindows to keep
+The only compelling use for the pen list is for wxWidgets to keep
track of pens in order to clean them up on exit. It is also kept for
-backward compatibility with earlier versions of wxWindows.
+backward compatibility with earlier versions of wxWidgets.
\wxheading{See also}
\func{void}{AddPen}{\param{wxPen*}{ pen}}
-Used internally by wxWindows to add a pen to the list.
+Used internally by wxWidgets to add a pen to the list.
\membersection{wxPenList::FindOrCreatePen}\label{wxpenlistfindorcreatepen}
\func{void}{RemovePen}{\param{wxPen*}{ pen}}
-Used by wxWindows to remove a pen from the list.
+Used by wxWidgets to remove a pen from the list.
-\chapter{Porting from wxWindows 1.xx}\label{porting}
+\chapter{Porting from wxWidgets 1.xx}\label{porting}
This addendum gives guidelines and tips for porting applications from
-version 1.xx of wxWindows to version 2.0.
+version 1.xx of wxWidgets to version 2.0.
The first section offers tips for writing 1.xx applications in a way to
minimize porting time. The following sections detail the changes and
You may be worrying that porting to 2.0 will be a lot of work,
particularly if you have only recently started using 1.xx. In fact,
-the wxWindows 2.0 API has far more in common with 1.xx than it has differences.
+the wxWidgets 2.0 API has far more in common with 1.xx than it has differences.
The main challenges are using the new event system, doing without the default
panel item layout, and the lack of automatic labels in some controls.
changed to 2.0, we hope that you will appreciate the benefits in terms
of greater flexibility, better user interface aesthetics, improved C++ conformance,
improved compilation speed, and many other enhancements. The revised architecture
-of 2.0 will ensure that wxWindows can continue to evolve for the foreseeable
+of 2.0 will ensure that wxWidgets can continue to evolve for the foreseeable
future.
{\it Please note that this document is a work in progress.}
they are going.
\item {\bf Using member callbacks} called from global callback functions will make the transition
easier - see the FAQ
-for some notes on using member functions for callbacks. wxWindows 2.0 will banish global
+for some notes on using member functions for callbacks. wxWidgets 2.0 will banish global
callback functions (and OnMenuCommand), and nearly all event handling will be done by functions taking a single event argument.
So in future you will have code like:
but the option is there.
\item {\bf Use wxString wherever possible.} 2.0 replaces char * with wxString
in most cases, and if you use wxString to receive strings returned from
-wxWindows functions (except when you need to save the pointer if deallocation is required), there should
+wxWidgets functions (except when you need to save the pointer if deallocation is required), there should
be no conversion problems later on.
\item Be aware that under Windows, {\bf font sizes will change} to match standard Windows
font sizes (for example, a 12-point font will appear bigger than before). Write your application
to be flexible where fonts are concerned.
Don't rely on fonts being similarly-sized across platforms, as they were (by chance) between
-Windows and X under wxWindows 1.66. Yes, this is not easy... but I think it is better to conform to the
+Windows and X under wxWidgets 1.66. Yes, this is not easy... but I think it is better to conform to the
standards of each platform, and currently the size difference makes it difficult to
conform to Windows UI standards. You may eventually wish to build in a global 'fudge-factor' to compensate
for size differences. The old font sizing will still be available via wx\_setup.h, so do not panic...
or dialog; or you can use a wxPropertyListView to show attributes in a scrolling list - you don't even need
to lay panel items out.
-Because wxForm uses a number of features to be dropped in wxWindows 2.0, it cannot be
+Because wxForm uses a number of features to be dropped in wxWidgets 2.0, it cannot be
supported in the future, at least in its present state.
\item {\bf When creating a wxListBox}, put the wxLB\_SINGLE, wxLB\_MULTIPLE, wxLB\_EXTENDED styles in the window style parameter, and put
zero in the {\it multiple} parameter. The {\it multiple} parameter will be removed in 2.0.
\item {\bf For MDI applications}, don't reply on MDI being run-time-switchable in the way that the
-MDI sample is. In wxWindows 2.0, MDI functionality is separated into distinct classes.
+MDI sample is. In wxWidgets 2.0, MDI functionality is separated into distinct classes.
\end{itemize}
\section{The new event system}\label{portingeventsystem}
-The way that events are handled has been radically changed in wxWindows 2.0. Please
-read the topic `Event handling overview' in the wxWindows 2.0 manual for background
+The way that events are handled has been radically changed in wxWidgets 2.0. Please
+read the topic `Event handling overview' in the wxWidgets 2.0 manual for background
on this.
\subsection{Callbacks}
\wxheading{wxForm}
-Note that wxForm is no longer supported in wxWindows 2.0. Consider using the wxPropertyFormView class
+Note that wxForm is no longer supported in wxWidgets 2.0. Consider using the wxPropertyFormView class
instead, which takes standard dialogs and panels and associates controls with property objects.
You may also find that the new validation method, combined with dialog resources, is easier
and more flexible than using wxForm.
\section{Device contexts and painting}\label{portingdc}
-In wxWindows 2.0, device contexts are used for drawing into, as per 1.xx, but the way
+In wxWidgets 2.0, device contexts are used for drawing into, as per 1.xx, but the way
they are accessed and constructed is a bit different.
You no longer use {\bf GetDC} to access device contexts for panels, dialogs and canvases.
same. This is because C++ will automatically convert a char* or const char* to a wxString by virtue
of appropriate wxString constructors.
-However, when a wxString is returned from a function in wxWindows 2.0 where a char* was
-returned in wxWindows 1.xx, your application will need to be changed. Usually you can
+However, when a wxString is returned from a function in wxWidgets 2.0 where a char* was
+returned in wxWidgets 1.xx, your application will need to be changed. Usually you can
simplify your application's allocation and deallocation of memory for the returned string,
and simply assign the result to a wxString object. For example, replace this:
\section{Backward compatibility}\label{portingcompat}
-Some wxWindows 1.xx functionality has been left to ease the transition to 2.0. This functionality
+Some wxWidgets 1.xx functionality has been left to ease the transition to 2.0. This functionality
(usually) only works if you compile with WXWIN\_COMPATIBILITY set to 1 in setup.h.
Mostly this defines old names to be the new names (e.g. wxRectangle is defined to be wxRect).
\section{\class{wxPostScriptDC}}\label{wxpostscriptdc}
-This defines the wxWindows Encapsulated PostScript device context,
+This defines the wxWidgets Encapsulated PostScript device context,
which can write PostScript files on any platform. See \helpref{wxDC}{wxdc} for
descriptions of the member functions.
\func{}{wxProcess}{\param{int }{flags}}
Constructs a process object. {\it id} is only used in the case you want to
-use wxWindows events. It identifies this object, or another window that will
+use wxWidgets events. It identifies this object, or another window that will
receive the event.
If the {\it parent} parameter is different from NULL, it will receive
Returns {\tt true} if there is data to be read on the child process standard
output stream. This allows to write simple (and extremely inefficient)
-polling-based code waiting for a better mechanism in future wxWindows versions.
+polling-based code waiting for a better mechanism in future wxWidgets versions.
See the \helpref{exec sample}{sampleexec} for an example of using this
function.
\constfunc{void}{OnTerminate}{\param{int}{ pid}, \param{int}{ status}}
It is called when the process with the pid {\it pid} finishes.
-It raises a wxWindows event when it isn't overridden.
+It raises a wxWidgets event when it isn't overridden.
\docparam{pid}{The pid of the process which has just terminated.}
{\bf Obsolescence note:} This method is obsolete and was replaced with
\helpref{GetCount}{wxradioboxgetcount}, please use the new method in the new
-code. This method is only available if wxWindows was compiled with
+code. This method is only available if wxWidgets was compiled with
{\tt WXWIN\_COMPATIBILITY\_2\_2} defined and will disappear completely in
future versions.
%% Created: 14.08.03
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxRecursionGuard}}\label{wxrecursionguard}
\parskip=10pt
\parindent=0pt
-\title{Reference Manual for wxWindows 2.0: a portable C++ GUI toolkit}
+\title{Reference Manual for wxWidgets 2.0: a portable C++ GUI toolkit}
\author{Julian Smart}
\date{November 4th 1998}
\begin{center}
Copyright (c) 1998 Julian Smart, Robert Roebling and other
-members of the wxWindows team\\
+members of the wxWidgets team\\
Portions (c) 1996 Artificial Intelligence Applications Institute\\
\end{center}
\setheader{{\it CHAPTER \thechapter}}{}{}{}{}{{\it CHAPTER \thechapter}}%
\setfooter{\thepage}{}{}{}{}{\thepage}
-wxWindows is a class library for C++ providing GUI (Graphical User
+wxWidgets is a class library for C++ providing GUI (Graphical User
Interface) and other facilities on more than one platform. This document
gives detailed information about the classes and functions that make up
-the wxWindows API (Application Programming Interface). Please refer to the
-wxWindows user manual for a more general description of wxWindows.
+the wxWidgets API (Application Programming Interface). Please refer to the
+wxWidgets user manual for a more general description of wxWidgets.
\input{classes.tex}
\input{category.tex}
%% Created: 14.07.01
%% RCS-ID: $Id$
%% Copyright: (c) 2001 Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxRegEx}}\label{wxregex}
On platforms where a system library is available, the default is to use
the builtin library for Unicode builds, and the system library otherwise.
It is possible to use the other if preferred by selecting it when building
-the wxWindows.
+the wxWidgets.
\wxheading{Derived from}
provided array. {\it fillStyle} parameter may have values
{\tt wxWINDING\_RULE} or {\tt wxODDEVEN\_RULE}.
-{\bf NB:} This constructor is only implemented for Win32 and GTK+ wxWindows ports.
+{\bf NB:} This constructor is only implemented for Win32 and GTK+ wxWidgets ports.
\func{}{wxRegion}{\param{const wxBitmap\&}{ bmp},
\param{const wxColour\&}{ transColour = wxNullColour},
%% Created: 06.08.03
%% RCS-ID: $Id$
%% Copyright: (c) 2003 Vadim Zeitlin <vadim@wxwindows.org>
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxRendererNative}}\label{wxrenderernative}
First, a brief introduction to wxRenderer and why it is needed.
-Usually wxWindows uses the underlying low level GUI system to draw all the
+Usually wxWidgets uses the underlying low level GUI system to draw all the
controls -- this is what we mean when we say that it is a ``native'' framework.
However not all controls exist under all (or even any) platforms and in this
-case wxWindows provides a default, generic, implementation of them written in
-wxWindows itself.
+case wxWidgets provides a default, generic, implementation of them written in
+wxWidgets itself.
These controls don't have the native appearance if only the standard
line drawing and other graphics primitives are used, because the native
%% Created: 11.08.03
%% RCS-ID: $Id$
%% Copyright: (c) 2003 Vadim Zeitlin <vadim@wxwindows.org>
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxRendererVersion}}\label{wxrendererversion}
\wxheading{Example}
-Below is an example of using a wxWindows scoped smart pointer and
+Below is an example of using a wxWidgets scoped smart pointer and
pointer array.
\begin{verbatim}
\wxheading{Example}
-Below is an example of using a wxWindows scoped smart pointer and
+Below is an example of using a wxWidgets scoped smart pointer and
pointer array.
\begin{verbatim}
A scroll event holds information about events sent from stand-alone
\helpref{scrollbars}{wxscrollbar} and \helpref{sliders}{wxslider}. Note that
-starting from wxWindows 2.1, scrolled windows send the
+starting from wxWidgets 2.1, scrolled windows send the
\helpref{wxScrollWinEvent}{wxscrollwinevent} which does not derive from
wxCommandEvent, but from wxEvent directly - don't confuse these two kinds of
events and use the event table macros mentioned below only for the
the coordinates according to the scrollbar positions, and setting the
scroll positions, thumb sizes and ranges according to the area in view.
-Starting from version 2.4 of wxWindows, there are several ways to use a
+Starting from version 2.4 of wxWidgets, there are several ways to use a
wxScrolledWindow. In particular, there are now three ways to set the
size of the scrolling area:
One way is to set the scrollbars directly using a call to
\helpref{wxScrolledWindow::SetScrollbars}{wxscrolledwindowsetscrollbars}.
-This is the way it used to be in any previous version of wxWindows
+This is the way it used to be in any previous version of wxWidgets
and it will be kept for backwards compatibility.
An additional method of manual control, which requires a little less
controlled by a sizer by calling
\helpref{wxWindow::SetVirtualSizeHints}{wxwindowsetvirtualsizehints}.
(calling \helpref{wxScrolledWindow::SetScrollbars}{wxscrolledwindowsetscrollbars}
- has analogous effects in wxWindows 2.4 -- in later versions it may not continue
+ has analogous effects in wxWidgets 2.4 -- in later versions it may not continue
to override the sizer)
Note: if Maximum size hints are still supported by SetVirtualSizeHints, use
%% Created: 02.04.02
%% RCS-ID: $Id$
%% Copyright: (c) 2002 Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxSemaphore}}\label{wxsemaphore}
A {\bf wxSize} is a useful data structure for graphics operations.
It simply contains integer {\it width} and {\it height} members.
-wxSize is used throughout wxWindows as well as wxPoint which, although almost
+wxSize is used throughout wxWidgets as well as wxPoint which, although almost
equivalent to wxSize, has a different meaning: wxPoint represents a position
while wxSize - the size.
\constfunc{bool}{IsFullySpecified}{\void}
Returns \true if neither of the size object components is equal to $-1$, which
-is used as default for the size values in wxWindows (hence the predefined
+is used as default for the size values in wxWidgets (hence the predefined
\texttt{wxDefaultSize} has both of its components equal to $-1$).
This method is typically used before calling
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Name: sizeevt.tex
%% Purpose: wxSizeEvent documentation
-%% Author: wxWindows team
+%% Author: wxWidgets team
%% Modified by:
%% Created:
%% RCS-ID: $Id$
-%% Copyright: (c) wxWindows team
-%% License: wxWindows license
+%% Copyright: (c) wxWidgets team
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxSizeEvent}}\label{wxsizeevent}
\helpref{wxNotebookSizer}{wxnotebooksizer}, \helpref{wxGridSizer}{wxgridsizer}
\helpref{wxFlexGridSizer}{wxflexgridsizer} and \helpref{wxGridBagSizer}{wxgridbagsizer}.
-The layout algorithm used by sizers in wxWindows is closely related to layout
+The layout algorithm used by sizers in wxWidgets is closely related to layout
in other GUI toolkits, such as Java's AWT, the GTK toolkit or the Qt toolkit. It is
based upon the idea of the individual subwindows reporting their minimal required
size and their ability to get stretched if the size of the parent window has changed.
and thus do not interfere with tab ordering and requires very little resources compared
to a real window on screen.
-What makes sizers so well fitted for use in wxWindows is the fact that every control
+What makes sizers so well fitted for use in wxWidgets is the fact that every control
reports its own minimal size and the algorithm can handle differences in font sizes
or different window (dialog item) sizes on different platforms without problems. If e.g.
the standard font as well as the overall design of Motif widgets requires more space than
%% Created: 08.06.01
%% RCS-ID: $Id$
%% Copyright: (c) 2001 Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxSingleInstanceChecker}}\label{wxsingleinstancechecker}
%% Modified by:
%% Created: 1999
%% RCS-ID: $Id$
-%% Copyright: (c) wxWindows team
-%% License: wxWindows license
+%% Copyright: (c) wxWidgets team
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxSocketBase}}\label{wxsocketbase}
Callback functions are also available, but they are provided for backwards
compatibility only. Their use is strongly discouraged in favour of events,
and should be considered deprecated. Callbacks may be unsupported in future
-releases of wxWindows.
+releases of wxWidgets.
\helpref{Callback}{wxsocketbasecallback}\\
\helpref{CallbackData}{wxsocketbasecallbackdata}
%% Modified by:
%% Created: 14.01.02 (extracted from socket.tex)
%% RCS-ID: $Id$
-%% Copyright: (c) wxWindows team
-%% License: wxWindows license
+%% Copyright: (c) wxWidgets team
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% ---------------------------------------------------------------------------
%% Created: 29.03.00
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxSpinEvent}}\label{wxspinevent}
\func{}{wxSplitterEvent}{\param{wxEventType}{ eventType = wxEVT\_NULL},
\param{wxSplitterWindow *}{ splitter = NULL}}
-Constructor. Used internally by wxWindows only.
+Constructor. Used internally by wxWidgets only.
\membersection{wxSplitterEvent::GetSashPosition}\label{wxsplittereventgetsashposition}
%% Created: 11.08.03
%% RCS-ID: $Id$
%% Copyright: (c) 2003 Vadim Zeitlin <vadim@wxwindows.org>
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Please note that a static box should {\bf not} be used as the parent for the
controls it contains, instead they should be siblings of each other. Although
-using a static box as a parent might work in some versions of wxWindows, it
+using a static box as a parent might work in some versions of wxWidgets, it
results in a crash under, for example, wxGTK.
Also, please note that because of this, the order in which you create new
\section{Standard event identifiers}\label{stdevtid}
-wxWindows defines a special identifier value {\tt wxID\_ANY} which is used in
+wxWidgets defines a special identifier value {\tt wxID\_ANY} which is used in
the following two situations:
\begin{itemize}
\item when creating a new window you may specify {\tt wxID\_ANY} to let
-wxWindows assign an unused identifier to it automatically
+wxWidgets assign an unused identifier to it automatically
\item when installing an event handler using either the event table
macros or \helpref{wxEvtHandler::Connect}{wxevthandlerconnect},
you may use it to indicate that you want to handle the events
coming from any control, regardless of its identifier
\end{itemize}
-wxWindows also defines a few standard command identifiers which may be used by
-the user code and also are sometimes used by wxWindows itself. These reserved
+wxWidgets also defines a few standard command identifiers which may be used by
+the user code and also are sometimes used by wxWidgets itself. These reserved
identifiers are all in the range between {\tt wxID\_LOWEST} and
{\tt wxID\_HIGHEST} and, accordingly, the user code should avoid defining its
own constants in this range.
% -----------------------------------------------------------------------------
\section{\class{wxStreamBase}}\label{wxstreambase}
-This class is the base class of most stream related classes in wxWindows. It must
+This class is the base class of most stream related classes in wxWidgets. It must
not be used directly.
\wxheading{Derived from}
%% Modified by:
%% Created: 1999
%% RCS-ID: $Id$
-%% Copyright: (c) wxWindows team
-%% License: wxWindows license
+%% Copyright: (c) wxWidgets team
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% -----------------------------------------------------------------------------
%% Created: 19.10.01
%% RCS-ID: $Id$
%% Copyright: (c) 2001 Vadim Zeitlin <vadim@wxwindows.org>
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxStreamToTextRedirector}}\label{wxstreamtotextredirector}
\section{\class{wxSystemOptions}}\label{wxsystemoptions}
-wxSystemOptions stores option/value pairs that wxWindows itself or
+wxSystemOptions stores option/value pairs that wxWidgets itself or
applications can use to alter behaviour at run-time. It can be
used to optimize behaviour that doesn't deserve a distinct API,
but is still important to be able to configure.
-These options are currently recognised by wxWindows:
+These options are currently recognised by wxWidgets:
\twocolwidtha{7cm}
\begin{twocollist}\itemsep=0pt
Classes: \helpref{wxApp}{wxapp}
-A wxWindows application does not have a {\it main} procedure; the equivalent is the
+A wxWidgets application does not have a {\it main} procedure; the equivalent is the
\rtfsp\helpref{OnInit}{wxapponinit} member defined for a class derived from wxApp.\rtfsp
\rtfsp{\it OnInit} will usually create a top window as a bare minimum.
-Unlike in earlier versions of wxWindows, OnInit does not return a frame. Instead it
+Unlike in earlier versions of wxWidgets, OnInit does not return a frame. Instead it
returns a boolean value which indicates whether processing should continue (true) or not (false).
-You call \helpref{wxApp::SetTopWindow}{wxappsettopwindow} to let wxWindows know
+You call \helpref{wxApp::SetTopWindow}{wxappsettopwindow} to let wxWidgets know
about the top window.
Note that the program's command line arguments, represented by {\it argc}
}
\end{verbatim}
-Note the use of IMPLEMENT\_APP(appClass), which allows wxWindows to dynamically create an instance of the application object
-at the appropriate point in wxWindows initialization. Previous versions of wxWindows used
+Note the use of IMPLEMENT\_APP(appClass), which allows wxWidgets to dynamically create an instance of the application object
+at the appropriate point in wxWidgets initialization. Previous versions of wxWidgets used
to rely on the creation of a global application object, but this is no longer recommended,
because required global initialization may not have been performed at application object
construction time.
call \helpref{Close()}{wxwindowclose} in response to the {\tt "Exit"} menu
command if your program has a single top level window. If this behaviour is not
desirable \helpref{wxApp::SetExitOnFrameDelete}{wxappsetexitonframedelete} can
-be called to change it. Note that starting from wxWindows 2.3.3 such logic
+be called to change it. Note that starting from wxWidgets 2.3.3 such logic
doesn't apply for the windows shown before the program enters the main loop: in
other words, you can safely show a dialog from
\helpref{wxApp::OnInit}{wxapponinit} and not be afraid that your application
Another aspect of the application shutdown is the \helpref{OnExit}{wxapponexit}
-which is called when the application exits but {\it before} wxWindows cleans up
-its internal structures. Your should delete all wxWindows object that your
+which is called when the application exits but {\it before} wxWidgets cleans up
+its internal structures. Your should delete all wxWidgets object that your
created by the time OnExit finishes. In particular, do {\bf not} destroy them
from application class' destructor!
The reason for that is that {\tt m\_helpCtrl} is a member object and is
thus destroyed from MyApp destructor. But MyApp object is deleted after
-wxWindows structures that wxCHMHelpController depends on were
+wxWidgets structures that wxCHMHelpController depends on were
uninitialized! The solution is to destroy HelpCtrl in {\it OnExit}:
\begin{verbatim}
See \helpref{wxMemoryDC}{wxmemorydc} for an example of drawing onto a bitmap.
-All wxWindows platforms support XPMs for small bitmaps and icons.
+All wxWidgets platforms support XPMs for small bitmaps and icons.
You may include the XPM inline as below, since it's C code, or you
can load it at run-time.
that missing or partially-implemented formats are automatically supplemented
by the \helpref{wxImage}{wximage} to load the data, and then converting
it to wxBitmap form. Note that using wxImage is the preferred way to
-load images in wxWindows, with the exception of resources (XPM-files or
+load images in wxWidgets, with the exception of resources (XPM-files or
native Windows resources). Writing an image format handler for wxImage
is also far easier than writing one for wxBitmap, because wxImage has
exactly one format on all platforms whereas wxBitmap can store pixel data
See also: \helpref{Drag and drop overview}{wxdndoverview} and \helpref{DnD sample}{samplednd}
This overview discusses data transfer through clipboard or drag and drop. In
-wxWindows, these two ways to transfer data (either between different
+wxWidgets, these two ways to transfer data (either between different
applications or inside one and the same) are very similar which allows to
implement both of them using almost the same code - or, in other
words, if you implement drag and drop support for your application, you get
presents a dialog box with controls for font name, point size, style, weight,
underlining, strikeout and text foreground colour. A sample of the
font is shown on a white area of the dialog box. Note that
-in the translation from full MS Windows fonts to wxWindows font
+in the translation from full MS Windows fonts to wxWidgets font
conventions, strikeout is ignored and a font family (such as
Swiss or Modern) is deduced from the actual font name (such as Arial
or Courier).
and two for the window size. By setting some or all of these constraints appropriately,
the user can achieve quite complex layout by defining relationships between windows.
-In wxWindows, each window can be constrained relative to either its {\it
+In wxWidgets, each window can be constrained relative to either its {\it
siblings} on the same window, or the {\it parent}. The layout algorithm
therefore operates in a top-down manner, finding the correct layout for
the children of a window, then the layout for the grandchildren, and so
on. Note that this differs markedly from native Motif layout, where
constraints can ripple upwards and can eventually change the frame
-window or dialog box size. We assume in wxWindows that the {\it user} is
+window or dialog box size. We assume in wxWidgets that the {\it user} is
always `boss' and specifies the size of the outer window, to which
subwindows must conform. Obviously, this might be a limitation in some
circumstances, but it suffices for most situations, and the
Classes: \helpref{wxList}{wxlist}, \helpref{wxArray}{wxarray}
-wxWindows uses itself several container classes including doubly-linked lists
+wxWidgets uses itself several container classes including doubly-linked lists
and dynamic arrays (i.e. arrays which expand automatically when they become
-full). For both historical and portability reasons wxWindows does not
+full). For both historical and portability reasons wxWidgets does not
use STL which provides the standard implementation of many container classes in
-C++. First of all, wxWindows has existed since well before STL was written, and
+C++. First of all, wxWidgets has existed since well before STL was written, and
secondly we don't believe that today compilers can deal really well with all of
STL classes (this is especially true for some less common platforms). Of
course, the compilers are evolving quite rapidly and hopefully their progress
-will allow to base future versions of wxWindows on STL - but this is not yet
+will allow to base future versions of wxWidgets on STL - but this is not yet
the case.
-wxWindows container classes don't pretend to be as powerful or full as STL
+wxWidgets container classes don't pretend to be as powerful or full as STL
ones, but they are quite useful and may be compiled with absolutely any C++
-compiler. They're used internally by wxWindows, but may, of course, be used in
+compiler. They're used internally by wxWidgets, but may, of course, be used in
your programs as well if you wish.
-The list classes in wxWindows are doubly-linked lists which may either own the
+The list classes in wxWidgets are doubly-linked lists which may either own the
objects they contain (meaning that the list deletes the object when it is
removed from the list or the list itself is destroyed) or just store the
pointers depending on whether you called or not
"int" or "bool" or the pointers to arbitrary objects, or "object arrays" which
own the object pointers to which they store.
-For the same portability reasons, the container classes implementation in wxWindows
+For the same portability reasons, the container classes implementation in wxWidgets
does not use templates, but is rather based on C preprocessor i.e. is done with
the macros: {\it WX\_DECLARE\_LIST} and {\it WX\_DEFINE\_LIST} for the linked
lists and {\it WX\_DECLARE\_ARRAY}, {\it WX\_DECLARE\_OBJARRAY} and {\it WX\_DEFINE\_OBJARRAY} for
Examples of usage of these macros may be found in \helpref{wxList}{wxlist} and
\helpref{wxArray}{wxarray} documentation.
-Finally, wxWindows predefines several commonly used container classes. wxList
+Finally, wxWidgets predefines several commonly used container classes. wxList
is defined for compatibility with previous versions as a list containing
wxObjects and wxStringList as a list of C-style strings (char *), both of these
classes are deprecated and should not be used in new programs. The following
%% Created: 07.03.00
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Date and time classes overview}\label{wxdatetimeoverview}
\subsection{Introduction}
-wxWindows provides a set of powerful classes to work with dates and times. Some
+wxWidgets provides a set of powerful classes to work with dates and times. Some
of the supported features of \helpref{wxDateTime}{wxdatetime} class are:
\twocolwidtha{7cm}
\subsection{Compatibility}\label{tdatecompatibility}
-The old classes for date/time manipulations ported from wxWindows version 1.xx
+The old classes for date/time manipulations ported from wxWidgets version 1.xx
are still included but are reimplemented in terms of wxDateTime. However, using
them is strongly discouraged because they have a few quirks/bugs and were not
`Y2K' compatible.
\section{Database classes overview}\label{odbcoverview}
-Following is a detailed overview of how to use the wxWindows ODBC classes - \helpref{wxDb}{wxdb}
+Following is a detailed overview of how to use the wxWidgets ODBC classes - \helpref{wxDb}{wxdb}
and \helpref{wxDbTable}{wxdbtable} and their associated functions. These are
the ODBC classes donated by Remstar International, and are collectively
referred to herein as the wxODBC classes.
For each result set, a cursor is maintained (typically by the database)
which keeps track of where in the result set the user currently is.
Depending on the database, ODBC driver, and how you configured the
-wxWindows ODBC settings in setup.h (see \helpref{wxODBC - Compiling}{wxodbccompiling}), cursors can be
+wxWidgets ODBC settings in setup.h (see \helpref{wxODBC - Compiling}{wxodbccompiling}), cursors can be
either forward or backward scrolling. At a minimum, cursors must scroll
forward. For example, if a query resulted in a result set with 100 rows,
as the data is read by the client application, it will read row 1, then 2,
Under Unix, iODBC is used for implementation of the ODBC API. To compile the
wxODBC classes, you must first obtain iODBC from \urlref{http://www.iodbc.org}{www.iodbc.org} and install it.
-(Note: wxWindows currently includes a version of iODBC.) Then you must create the file "~/.odbc.ini" (or optionally create
+(Note: wxWidgets currently includes a version of iODBC.) Then you must create the file "~/.odbc.ini" (or optionally create
"/etc/odbc.ini" for access for all users on the system). This file contains
the settings for your system/datasource. Below is an example section of a
odbc.ini file for use with the "samples/db" sample program using MySQL:
\subsection{wxODBC - Compiling}\label{wxodbccompiling}
-The wxWindows setup.h file has several settings in it pertaining to compiling
+The wxWidgets setup.h file has several settings in it pertaining to compiling
the wxODBC classes.
\begin{twocollist}\itemsep=0pt
\helpref{wxDb constructor}{wxdbconstr}. The default is 1.}
\twocolitem{wxODBC\_BACKWARD\_COMPATABILITY}{Between v2.0 and 2.2, massive
renaming efforts were done to the ODBC classes to get naming conventions
-similar to those used throughout wxWindows, as well as to preface all wxODBC
+similar to those used throughout wxWidgets, as well as to preface all wxODBC
classes names and functions with a wxDb preface. Because this renaming would
affect applications written using the v2.0 names, this compile-time directive
was added to allow those programs written for v2.0 to still compile using the
You are required to include the "odbc32.lib" provided by your compiler vendor
in the list of external libraries to be linked in. If using the makefiles
-supplied with wxWindows, this library should already be included for use with
+supplied with wxWidgets, this library should already be included for use with
makefile.b32, makefile.vc, and makefile.g95.
\normalbox{MORE TO COME}
directory indicating where the data file is stored, is required for Text and
dBase drivers for ODBC.
-The wxWindows data class wxDbConnectInf exists for holding all of these
+The wxWidgets data class wxDbConnectInf exists for holding all of these
values, plus some others that may be desired.
The 'Henv' member is the environment handle used to access memory for use by the
will default to only allowing cursor scrolling to be either forward only,
or both backward and forward scrolling. The default behavior is
determined by the setting {\tt wxODBC\_FWD\_ONLY\_CURSORS} in setup.h when you
-compile the wxWindows library. The library default is to only support
+compile the wxWidgets library. The library default is to only support
forward scrolling cursors only, though this can be overridden by parameters
for wxDb() constructor or the \helpref{wxDbGetConnection}{wxdbfunctions}
function. All datasources and ODBC drivers must support forward scrolling
\subsection{wxODBC - Known Issues}\label{wxodbcknownissues}
-As with creating wxWindows, writing the wxODBC classes was not the simple
+As with creating wxWidgets, writing the wxODBC classes was not the simple
task of writing an application to run on a single type of computer system.
The classes need to be cross-platform for different operating systems, and
they also needed to take in to account different database manufacturers and
\begin{itemize}\itemsep=0pt
\item If a column is part of the Primary Key, the column cannot be NULL.
\item Cannot support selecting for update [\helpref{wxDbTable::CanSelectForUpdate}{wxdbtablecanselectforupdate}]. Always returns false.
-\item Columns that are part of primary or secondary keys must be defined as being NOT NULL when they are created. Some code is added in \helpref{wxDbTable::CreateIndex}{wxdbtablecreateindex} to try to adjust the column definition if it is not defined correctly, but it is experimental (as of wxWindows v2.2.1)
+\item Columns that are part of primary or secondary keys must be defined as being NOT NULL when they are created. Some code is added in \helpref{wxDbTable::CreateIndex}{wxdbtablecreateindex} to try to adjust the column definition if it is not defined correctly, but it is experimental (as of wxWidgets v2.2.1)
\item Does not support sub-queries in SQL statements
\end{itemize}
Classes, functions and macros: \helpref{wxDebugContext}{wxdebugcontext}, \helpref{wxObject}{wxobject}, \helpref{wxLog}{wxlog},
\rtfsp\helpref{Log functions}{logfunctions}, \helpref{Debug macros}{debugmacros}
-Various classes, functions and macros are provided in wxWindows to help you debug
-your application. Most of these are only available if you compile both wxWindows,
-your application and {\it all} libraries that use wxWindows with the \_\_WXDEBUG\_\_ symbol
+Various classes, functions and macros are provided in wxWidgets to help you debug
+your application. Most of these are only available if you compile both wxWidgets,
+your application and {\it all} libraries that use wxWidgets with the \_\_WXDEBUG\_\_ symbol
defined. You can also test the \_\_WXDEBUG\_\_ symbol in your own applications to execute
code that should be active only in debug mode.
check memory for errors.
It is good practice to define a \helpref{wxObject::Dump}{wxobjectdump} member function for each class you derive
-from a wxWindows class, so that \helpref{wxDebugContext::Dump}{wxdebugcontextdump} can call it and
+from a wxWidgets class, so that \helpref{wxDebugContext::Dump}{wxdebugcontextdump} can call it and
give valuable information about the state of the application.
If you have difficulty tracking down a memory leak, recompile
in debugging mode and call \helpref{wxDebugContext::Dump}{wxdebugcontextdump} and \helpref{wxDebugContext::PrintStatistics}{wxdebugcontextprintstatistics} at
appropriate places. They will tell you what objects have not yet been
-deleted, and what kinds of object they are. In fact, in debug mode wxWindows will automatically
+deleted, and what kinds of object they are. In fact, in debug mode wxWidgets will automatically
detect memory leaks when your application is about to exit, and if there are any leaks,
will give you information about the problem. (How much information depends on the operating system
and compiler -- some systems don't allow all memory logging to be enabled). See the
\end{verbatim}
}%
-All occurrences of 'new' in wxWindows and your own application will use
+All occurrences of 'new' in wxWidgets and your own application will use
the overridden form of the operator with two extra arguments. This means that the debugging
output (and error messages reporting memory problems) will tell you what
file and on what line you allocated the object. Unfortunately not all
You can use wxDebugContext if \_\_WXDEBUG\_\_ is defined, or you can use it
at any other time (if wxUSE\_DEBUG\_CONTEXT is set to 1 in setup.h). It is not disabled
-in non-debug mode because you may not wish to recompile wxWindows and your entire application
+in non-debug mode because you may not wish to recompile wxWidgets and your entire application
just to make use of the error logging facility.
Note: wxDebugContext::SetFile has a problem at present, so use the default stream instead.
\wxheading{What is the sequence of events in a window deletion?}
When the user clicks on the system close button or system close command,
-in a frame or a dialog, wxWindows calls \helpref{wxWindow::Close}{wxwindowclose}. This
+in a frame or a dialog, wxWidgets calls \helpref{wxWindow::Close}{wxwindowclose}. This
in turn generates an EVT\_CLOSE event: see \helpref{wxCloseEvent}{wxcloseevent}.
It is the duty of the application to define a suitable event handler, and
The wxCloseEvent handler should only call \helpref{wxWindow::Destroy}{wxwindowdestroy} to
delete the window, and not use the {\bf delete} operator. This is because
-for some window classes, wxWindows delays actual deletion of the window until all events have been processed,
+for some window classes, wxWidgets delays actual deletion of the window until all events have been processed,
since otherwise there is the danger that events will be sent to a non-existent window.
As reinforced in the next section, calling Close does not guarantee that the window
\wxheading{What should I do to upgrade my 1.xx OnClose to 2.0?}
-In wxWindows 1.xx, the {\bf OnClose} function did not actually delete 'this', but signaled
-to the calling function (either {\bf Close}, or the wxWindows framework) to delete
+In wxWidgets 1.xx, the {\bf OnClose} function did not actually delete 'this', but signaled
+to the calling function (either {\bf Close}, or the wxWidgets framework) to delete
or not delete the window.
To update your code, you should provide an event table entry in your frame or
\wxheading{How do I exit the application gracefully?}
-A wxWindows application automatically exits when the designated top window, or the
+A wxWidgets application automatically exits when the designated top window, or the
last frame or dialog, is destroyed. Put any application-wide cleanup code in \helpref{wxApp::OnExit}{wxapponexit} (this
is a virtual function, not an event handler).
modeless dialogs and a message loop. This is because Windows 3 expects
the contents of a modal dialog to be loaded from a resource file or
created on receipt of a dialog initialization message. This is too
-restrictive for wxWindows, where any window may be created and displayed
+restrictive for wxWidgets, where any window may be created and displayed
before its contents are created.
For a set of dialog convenience functions, including file selection, see
\helpref{wxFileDropTarget}{wxfiledroptarget}
Note that wxUSE\_DRAG\_AND\_DROP must be defined in setup.h in order
-to use drag and drop in wxWindows.
+to use drag and drop in wxWidgets.
See also: \helpref{wxDataObject overview}{wxdataobjectoverview} and \helpref{DnD sample}{samplednd}
derive from \helpref{wxTextDropTarget}{wxtextdroptarget} or
\helpref{wxFileDropTarget}{wxfiledroptarget} and override their OnDropText()
or OnDropFiles() method.
-\item {\bf Drop:} When the user releases the mouse over a window, wxWindows
+\item {\bf Drop:} When the user releases the mouse over a window, wxWidgets
asks the associated wxDropTarget object if it accepts the data. For this,
a \helpref{wxDataObject}{wxdataobject} must be associated with the drop target
and this data object will be responsible for the format negotiation between
\end{itemize}
Note that to activate framework functionality, you need to use some or all of
-the wxWindows \helpref{predefined command identifiers}{predefinedids} in your menus.
+the wxWidgets \helpref{predefined command identifiers}{predefinedids} in your menus.
\perlnote{The document/view framework is available in wxPerl. To use it,
you will need the following statements in your application code:\par
Class: \helpref{wxDocument}{wxdocument}
The wxDocument class can be used to model an application's file-based
-data. It is part of the document/view framework supported by wxWindows,
+data. It is part of the document/view framework supported by wxWidgets,
and cooperates with the \helpref{wxView}{wxview}, \helpref{wxDocTemplate}{wxdoctemplate}\rtfsp
and \helpref{wxDocManager}{wxdocmanager} classes.
should pass CLASSINFO(YourDocumentClass) to the wxDocTemplate constructor
so that it knows how to create an instance of this class.
-If you do not wish to use the wxWindows method of creating document
+If you do not wish to use the wxWidgets method of creating document
objects dynamically, you must override wxDocTemplate::CreateDocument
to return an instance of the appropriate class.
Class: \helpref{wxView}{wxview}
The wxView class can be used to model the viewing and editing component of
-an application's file-based data. It is part of the document/view framework supported by wxWindows,
+an application's file-based data. It is part of the document/view framework supported by wxWidgets,
and cooperates with the \helpref{wxDocument}{wxdocument}, \helpref{wxDocTemplate}{wxdoctemplate}
and \helpref{wxDocManager}{wxdocmanager} classes.
should pass CLASSINFO(YourViewClass) to the wxDocTemplate constructor
so that it knows how to create an instance of this class.
-If you do not wish to use the wxWindows method of creating view
+If you do not wish to use the wxWidgets method of creating view
objects dynamically, you must override wxDocTemplate::CreateView
to return an instance of the appropriate class.
a single document template is constructed, and dialogs will be appropriately
simplified.
-wxDocTemplate is part of the document/view framework supported by wxWindows,
+wxDocTemplate is part of the document/view framework supported by wxWidgets,
and cooperates with the \helpref{wxView}{wxview}, \helpref{wxDocument}{wxdocument}
and \helpref{wxDocManager}{wxdocmanager} classes.
To use the wxDocTemplate class, you do not need to derive a new class.
Just pass relevant information to the constructor including CLASSINFO(YourDocumentClass) and
CLASSINFO(YourViewClass) to allow dynamic instance creation.
-If you do not wish to use the wxWindows method of creating document
+If you do not wish to use the wxWidgets method of creating document
objects dynamically, you must override wxDocTemplate::CreateDocument
and wxDocTemplate::CreateView to return instances of the appropriate class.
{\it NOTE}: the document template has nothing to do with the C++ template construct. C++
-templates are not used anywhere in wxWindows.
+templates are not used anywhere in wxWidgets.
\subsection{wxDocManager overview}\label{wxdocmanageroverview}
Class: \helpref{wxDocManager}{wxdocmanager}
-The wxDocManager class is part of the document/view framework supported by wxWindows,
+The wxDocManager class is part of the document/view framework supported by wxWidgets,
and cooperates with the \helpref{wxView}{wxview}, \helpref{wxDocument}{wxdocument}\rtfsp
and \helpref{wxDocTemplate}{wxdoctemplate} classes.
to a \helpref{wxCommandProcessor}{wxcommandprocessoroverview} object to execute and
store.
-The wxWindows document/view framework handles Undo and Redo by use of
+The wxWidgets document/view framework handles Undo and Redo by use of
wxCommand and wxCommandProcessor objects. You might find further uses
for wxCommand, such as implementing a macro facility that stores, loads
and replays commands.
\end{verbatim}
}
-\subsection{wxWindows predefined command identifiers}\label{predefinedids}
+\subsection{wxWidgets predefined command identifiers}\label{predefinedids}
To allow communication between the application's menus and the
document/view framework, several command identifiers are predefined for you
Write to the file, return {\tt true} on success, {\tt false} on failure.
-The second argument is only meaningful in Unicode build of wxWindows when
+The second argument is only meaningful in Unicode build of wxWidgets when
{\it conv} is used to convert {\it str} to multibyte representation.
\membersection{wxTempFile::Commit}\label{wxtempfilecommit}
%\setfooter{\thepage}{}{}{}{}{\thepage}%
This section describes all environment variables that affect execution of
-wxWindows programs.
+wxWidgets programs.
\twocolwidtha{5cm}%
\begin{twocollist}\itemsep=0pt
This variable can be set to comma-separated list of trace masks used in
\helpref{wxLogTrace}{wxlogtrace} calls;
\helpref{wxLog::AddTraceMask}{wxlogaddtracemask} is called for every mask
-in the list during wxWindows initialization.}
+in the list during wxWidgets initialization.}
\twocolitem{\tt{WXPREFIX}}{(Unix only.)
Overrides installation prefix. Normally, the prefix
\subsection{Introduction}
-Before version 2.0 of wxWindows, events were handled by the application
+Before version 2.0 of wxWidgets, events were handled by the application
either by supplying callback functions, or by overriding virtual member
functions such as {\bf OnSize}.
-From wxWindows 2.0, {\it event tables} are used instead, with a few exceptions.
+From wxWidgets 2.0, {\it event tables} are used instead, with a few exceptions.
-An event table is placed in an implementation file to tell wxWindows how to map
+An event table is placed in an implementation file to tell wxWidgets how to map
events to member functions. These member functions are not virtual functions, but
they are all similar in form: they take a single wxEvent-derived argument, and have a void return
type.
\subsection{How events are processed}\label{eventprocessing}
-When an event is received from the windowing system, wxWindows calls
+When an event is received from the windowing system, wxWidgets calls
\helpref{wxEvtHandler::ProcessEvent}{wxevthandlerprocessevent} on the first
event handler object belonging to the window generating the event.
-It may be noted that wxWindows' event processing system implements something
+It may be noted that wxWidgets' event processing system implements something
very close to virtual methods in normal C++, i.e. it is possible to alter
the behaviour of a class by overriding its event handling functions. In
many cases this works even for changing the behaviour of native controls.
if ( isalpha( event.KeyCode() ) )
{
// key code is within legal range. we call event.Skip() so the
- // event can be processed either in the base wxWindows class
+ // event can be processed either in the base wxWidgets class
// or the native control.
event.Skip();
\end{enumerate}
{\bf Pay close attention to Step 5.} People often overlook or get
-confused by this powerful feature of the wxWindows event processing
+confused by this powerful feature of the wxWidgets event processing
system. To put it a different way, events set to propagate
(\helpref{See: wxEvent::ShouldPropagate}{wxeventshouldpropagate})
(most likely derived either directly or indirectly from wxCommandEvent)
doesn't call \helpref{event.Skip()}{wxeventskip}.
Finally, there is another additional complication (which, in fact, simplifies
-life of wxWindows programmers significantly): when propagating the command
+life of wxWidgets programmers significantly): when propagating the command
events upwards to the parent window, the event propagation stops when it
reaches the parent dialog, if any. This means that you don't risk to get
unexpected events from the dialog controls (which might be left unprocessed by
and their parent-child relation are well understood by the programmer while it
may be very difficult, if not impossible, to track down all the dialogs which
may be popped up in a complex program (remember that some are created
-automatically by wxWindows). If you need to specify a different behaviour for
+automatically by wxWidgets). If you need to specify a different behaviour for
some reason, you can use
\helpref{SetExtraStyle(wxWS\_EX\_BLOCK\_EVENTS)}{wxwindowsetextrastyle}
explicitly to prevent the events from being propagated beyond the given window
long as you don't have several within the same dialog.
If you pass {\tt wxID\_ANY} to a window constructor, an identifier will be
-generated for you automatically by wxWindows. This is useful when you don't
+generated for you automatically by wxWidgets. This is useful when you don't
care about the exact identifier either because you're not going to process the
events from the control being created at all or because you process the events
from all controls in one place (in which case you should specify {\tt wxID\_ANY}
htmlBrowseButtons = bitmap
winHelpContents = yes
winHelpVersion = 3 ; 3 for Windows 3.x, 4 for Windows 95
-winHelpTitle = "wxWindows Manual"
+winHelpTitle = "wxWidgets Manual"
truncateFilenames = yes
combineSubSections = yes
;;
htmlBrowseButtons = bitmap
winHelpContents = yes
winHelpVersion = 3 ; 3 for Windows 3.x, 4 for Windows 95
-winHelpTitle = "wxWindows Manual"
+winHelpTitle = "wxWidgets Manual"
truncateFilenames = no
combineSubSections = yes
;;
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Name: texcept.tex
-%% Purpose: C++ exceptions and wxWindows overview
+%% Purpose: C++ exceptions and wxWidgets overview
%% Author: Vadim Zeitlin
%% Modified by:
%% Created: 17.09.03
%% RCS-ID: $Id$
%% Copyright: (c) 2003 Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{C++ exceptions overview}\label{exceptionsoverview}
\subsection{Introduction}
-wxWindows had been started long before the exceptions were introduced in C++ so
+wxWidgets had been started long before the exceptions were introduced in C++ so
it is not very surprizing that it is not built around using them as some more
modern C++ libraries are. For instance, the library doesn't throw exceptions to
signal about the errors. Moreover, up to (and including) the version 2.4 of
-wxWindows, even using the exceptions in the user code was dangerous because the
+wxWidgets, even using the exceptions in the user code was dangerous because the
library code wasn't exception-safe and so an exception propagating through it
could result in memory and/or resource leaks, and also not very convenient.
-Starting from the version 2.5.1 wxWindows becomes more exception-friendly. It
+Starting from the version 2.5.1 wxWidgets becomes more exception-friendly. It
still doesn't use the exceptions by itself but it should be now safe to use the
exceptions in the user code and the library tries to help you with this. Please
note that making the library exception-safe is still work in progress.
\subsection{Strategies for exceptions handling}
-There are several choice for using the exceptions in wxWindows programs. First
+There are several choice for using the exceptions in wxWidgets programs. First
of all, you may not use them at all. As stated above, the library doesn't throw
any exceptions by itself and so you don't have to worry about exceptions at all
unless your own code throws them. This is, of course, the simplest solution but
supporting objects attribute/value pairs.
wxExpr can be used to develop programs with readable and
-robust data files. Within wxWindows itself, it is used to parse
+robust data files. Within wxWidgets itself, it is used to parse
the {\tt .wxr} dialog resource files.
{\bf History of wxExpr}
\end{verbatim}
}%
-But wxWindows provides a convenient class to make it even simpler so instead
+But wxWidgets provides a convenient class to make it even simpler so instead
you may just do
{\small%
This functions inserts into the control the character which would have been
inserted if the given key event had occured in the text control. The
{\it event} object should be the same as the one passed to {\tt EVT\_KEY\_DOWN}
-handler previously by wxWindows.
+handler previously by wxWidgets.
Please note that this function doesn't currently work correctly for all keys
under any platform but MSW.
\wxheading{Compatibility}
-Only implemented in wxMSW/wxGTK starting with wxWindows 2.3.2.
+Only implemented in wxMSW/wxGTK starting with wxWidgets 2.3.2.
\membersection{wxTextCtrl::SetSelection}\label{wxtextctrlsetselection}
\section{\class{wxTextEntryDialog}}\label{wxtextentrydialog}
This class represents a dialog that requests a one-line text string from the user.
-It is implemented as a generic wxWindows dialog.
+It is implemented as a generic wxWidgets dialog.
\wxheading{Derived from}
success. It will fail if the file does not exist,
\helpref{Create}{wxtextfilecreate} should be used in this case.
-The {\it conv} argument is only meaningful in Unicode build of wxWindows when
+The {\it conv} argument is only meaningful in Unicode build of wxWidgets when
it is used to convert the file to wide character representation.
\membersection{wxTextFile::RemoveLine}\label{wxtextfileremoveline}
file format (default argument means "don't change type") and may be used to
convert, for example, DOS files to Unix.
-The {\it conv} argument is only meaningful in Unicode build of wxWindows when
+The {\it conv} argument is only meaningful in Unicode build of wxWidgets when
it is used to convert all lines to multibyte representation before writing them
them to physical file.
Functions: see \helpref{file functions}{filefunctions}.
-wxWindows provides some functions and classes to facilitate working with files.
+wxWidgets provides some functions and classes to facilitate working with files.
As usual, the accent is put on cross-platform features which explains, for
example, the \helpref{wxTextFile}{wxtextfile} class which may be used to convert
between different types of text files (DOS/Unix/Mac).
%% Created: 03.11.99
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Font encoding overview}\label{wxfontencodingoverview}
-wxWindows has support for multiple font encodings starting from release 2.2.
+wxWidgets has support for multiple font encodings starting from release 2.2.
By encoding we mean here the mapping between the character codes and the
letters. Probably the most well-known encoding is (7 bit) ASCII one which is
used almost universally now to represent the letters of the English alphabet
%% Created: 20.11.01
%% RCS-ID: $Id$
%% Copyright: (c) 2001 Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxToggleButton}}\label{wxtogglebutton}
-\section{Writing a wxWindows application: a rough guide}\label{roughguide}
+\section{Writing a wxWidgets application: a rough guide}\label{roughguide}
-To set a wxWindows application going, you will need to derive a \helpref{wxApp}{wxapp} class and
+To set a wxWidgets application going, you will need to derive a \helpref{wxApp}{wxapp} class and
override \helpref{wxApp::OnInit}{wxapponinit}.
An application must have a top-level \helpref{wxFrame}{wxframe} or \helpref{wxDialog}{wxdialog} window.
easier to shoot oneself in the foot, so careful use of synchronization objects
such as \helpref{mutexes}{wxmutex} and/or \helpref{critical sections}{wxcriticalsection} is recommended.
-There are two types of threads in wxWindows: {\it detached} and {\it joinable}
+There are two types of threads in wxWidgets: {\it detached} and {\it joinable}
ones, just as in the POSIX thread API (but unlike Win32 threads where all threads
are joinable). The difference between the two is that only joinable threads
can return a return code -- this is returned by the Wait() function. Detached
The returned value is the thread exit code which is only useful for
joinable threads and is the value returned by \helpref{Wait}{wxthreadwait}.
-This function is called by wxWindows itself and should never be called
+This function is called by wxWidgets itself and should never be called
directly.
joinable threads and is the value returned by
\helpref{GetThread()->Wait()}{wxthreadwait}.
-This function is called by wxWindows itself and should never be called
+This function is called by wxWidgets itself and should never be called
directly.
\membersection{wxThreadHelper::GetThread}\label{wxthreadhelpergetthread}
The returned value is the thread exit code which is the value returned by
\helpref{Wait()}{wxthreadwait}.
-This function is called by wxWindows itself and should never be called
+This function is called by wxWidgets itself and should never be called
directly.
\membersection{wxThreadHelperThread::CallEntry}\label{wxthreadhelperthreadcallentry}
The returned value is the thread exit code which is the value returned by
\helpref{Wait()}{wxthreadwait}.
-This function is called by wxWindows itself and should never be called
+This function is called by wxWidgets itself and should never be called
directly.
more than just translating its text messages to another message -- date, time and
currency formats need changing too, some languages are written left to right
and others right to left, character encoding may differ and many other things
-may need changing too -- it is a necessary first step. wxWindows provides
+may need changing too -- it is a necessary first step. wxWidgets provides
facilities for message translation with its
\helpref{wxLocale}{wxlocale} class and is itself fully translated into several
-languages. Please consult wxWindows home page for the most up-to-date
+languages. Please consult wxWidgets home page for the most up-to-date
translations - and if you translate it into one of the languages not done
yet, your translations would be gratefully accepted for inclusion into the
future versions of the library!
-The wxWindows approach to i18n closely follows GNU gettext package. wxWindows uses the
+The wxWidgets approach to i18n closely follows GNU gettext package. wxWidgets uses the
message catalogs which are binary compatible with gettext catalogs and this
allows to use all of the programs in this package to work with them. But note
that no additional libraries are needed during the run-time, however, so you
\end{enumerate}
See also the GNU gettext documentation linked from {\tt docs/html/index.htm} in
-your wxWindows distribution.
+your wxWidgets distribution.
See also \helpref{Writing non-English applications}{nonenglishoverview}.
It focuses on handling charsets related problems.
%% Created: 04.04.00
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxTimeSpan}}\label{wxtimespan}
%\helpref{wxTCPServer}{wxtcpserver}, \helpref{wxTCPConnection}{wxtcpconnection},
%\helpref{wxTCPClient}{wxtcpclient}
-wxWindows has a number of different classes to help with
+wxWidgets has a number of different classes to help with
interprocess communication and network programming. This section
only discusses one family of classes -- the DDE-like protocol --
but here's a list of other useful classes:
for programming popular Internet protocols.
\end{itemize}
-wxWindows' DDE-like protocol is a high-level protocol based on
+wxWidgets' DDE-like protocol is a high-level protocol based on
Windows DDE. There are two implementations of this DDE-like
protocol: one using real DDE running on Windows only, and another
using TCP/IP (sockets) that runs on most platforms. Since the API
\end{verbatim}
Note that it is no longer necessary to call wxDDEInitialize or wxDDECleanUp, since
-wxWindows will do this itself if necessary.
+wxWidgets will do this itself if necessary.
\helpref{wxLogPassThrough}{wxlogpassthrough},\\
\helpref{wxStreamToTextRedirector}{wxstreamtotextredirector}
-This is a general overview of logging classes provided by wxWindows. The word
+This is a general overview of logging classes provided by wxWidgets. The word
logging here has a broad sense, including all of the program output, not only
-non interactive messages. The logging facilities included in wxWindows provide
+non interactive messages. The logging facilities included in wxWidgets provide
the base {\it wxLog} class which defines the standard interface for a {\it log
target} as well as several standard implementations of it and a family of
functions to use with them.
wxLogInfo}).
\item{\bf wxLogStatus} is for status messages - they will go into the status
bar of the active or specified (as the first argument) \helpref{wxFrame}{wxframe} if it has one.
-\item{\bf wxLogSysError} is mostly used by wxWindows itself, but might be
+\item{\bf wxLogSysError} is mostly used by wxWidgets itself, but might be
handy for logging errors after system call (API function) failure. It logs the
specified message text as well as the last system error
code ({\it errno} or {\it ::GetLastError()} depending on the platform) and
The usage of these functions should be fairly straightforward, however it may
be asked why not use the other logging facilities, such as C standard stdio
functions or C++ streams. The short answer is that they're all very good
-generic mechanisms, but are not really adapted for wxWindows, while the log
-classes are. Some of advantages in using wxWindows log functions are:
+generic mechanisms, but are not really adapted for wxWidgets, while the log
+classes are. Some of advantages in using wxWidgets log functions are:
\begin{itemize}\itemsep=0pt
\item{\bf Portability} It is a common practice to use {\it printf()}
\item{\bf Completeness} Usually, an error message should be presented to the user
when some operation fails. Let's take a quite simple but common case of a file
error: suppose that you're writing your data file on disk and there is not
-enough space. The actual error might have been detected inside wxWindows code
+enough space. The actual error might have been detected inside wxWidgets code
(say, in {\it wxFile::Write}), so the calling function doesn't really know the
exact reason of the failure, it only knows that the data file couldn't be
-written to the disk. However, as wxWindows uses {\it wxLogError()} in this
+written to the disk. However, as wxWidgets uses {\it wxLogError()} in this
situation, the exact error code (and the corresponding error message) will be
given to the user together with "high level" message about data file writing
error.
messages, and why would you want to use them we now describe how all this
works.
-wxWindows has the notion of a {\it log target}: it is just a class deriving
+wxWidgets has the notion of a {\it log target}: it is just a class deriving
from \helpref{wxLog}{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 {\it active} at any moment, this is the one used by {\it wxLogXXX()}
stderr by default as its name suggests.
\item{\bf wxLogStream} This class has the same functionality as wxLogStderr,
but uses {\it ostream} and cerr instead of {\it FILE *} and stderr.
-\item{\bf wxLogGui} This is the standard log target for wxWindows
+\item{\bf wxLogGui} This is the standard log target for wxWidgets
applications (it is used by default if you don't do anything) and provides the
most reasonable handling of all types of messages for given platform.
\item{\bf wxLogWindow} This log target provides a "log console" which
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Name: tmbconv.tex
-%% Purpose: Overview of the wxMBConv classes in wxWindows
+%% Purpose: Overview of the wxMBConv classes in wxWidgets
%% Author: Ove Kaaven
%% Modified by:
%% Created: 25.03.00
%% RCS-ID: $Id$
%% Copyright: (c) 2000 Ove Kaaven
-%% Licence: wxWindows license
+%% Licence: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{wxMBConv classes overview}\label{mbconvclasses}
\helpref{wxCSConv}{wxcsconv},
\helpref{wxMBConvUTF16}{wxmbconvutf16}, \helpref{wxMBConvUTF32}{wxmbconvutf32}
-The wxMBConv classes in wxWindows enables an Unicode-aware application to
+The wxMBConv classes in wxWidgets enables an Unicode-aware application to
easily convert between Unicode and the variety of 8-bit encoding systems still
in use.
\subsection{Background: The wxString class}
-If you have compiled wxWindows in Unicode mode, the wxChar type will become
+If you have compiled wxWidgets in Unicode mode, the wxChar type will become
identical to wchar\_t rather than char, and a wxString stores wxChars. Hence,
all wxString manipulation in your application will then operate on Unicode
strings, and almost as easily as working with ordinary char strings (you
\subsection{wxMBConv objects}
-Several of the wxWindows-provided wxMBConv classes have predefined instances
+Several of the wxWidgets-provided wxMBConv classes have predefined instances
(wxConvLibc, wxConvFile, wxConvUTF7, wxConvUTF8, wxConvLocal). You can use
these predefined objects directly, or you can instantiate your own objects.
Once you have chosen which object you want to use to convert your text,
here is how you would use them with wxString. These examples all assume
-that you are using a Unicode build of wxWindows, although they will still
+that you are using a Unicode build of wxWidgets, although they will still
compile in a non-Unicode build (they just won't convert anything).
Example 1: Constructing a wxString from input in current encoding.
If you have specialized needs, or just don't want to use wxString, you
can also use the conversion methods of the conversion objects directly.
This can even be useful if you need to do conversion in a non-Unicode
-build of wxWindows; converting a string from UTF-8 to the current
+build of wxWidgets; converting a string from UTF-8 to the current
encoding should be possible by doing this:
\begin{verbatim}
Here, cMB2WC of the UTF8 object returns a wxWCharBuffer containing a Unicode
string. The wxString constructor then converts it back to an 8-bit character
set using the passed conversion object, *wxConvCurrent. (In a Unicode build
-of wxWindows, the constructor ignores the passed conversion object and
+of wxWidgets, the constructor ignores the passed conversion object and
retains the Unicode data.)
This could also be done by first making a wxString of the original data:
situation even more complicated). These charsets usually differ in so
many characters it is impossible to use same texts under all platforms.
-wxWindows library provides mechanism that helps you avoid distributing many
+wxWidgets library provides mechanism that helps you avoid distributing many
identical, only differently encoded, packages with your application
(e.g. help files and menu items in iso8859-13 and windows-1257). Thanks
to this mechanism you can, for example, distribute only iso8859-13 data
(Make sure that the header is {\bf not} marked as {\it fuzzy}.)
-wxWindows is able to use this catalog under any supported platform
+wxWidgets is able to use this catalog under any supported platform
(although iso8859-2 is a Unix encoding and is normally not understood by
Windows).
\wxheading{Include files}
-<wx/toolbar.h> (to allow wxWindows to select an appropriate toolbar class)\\
+<wx/toolbar.h> (to allow wxWidgets to select an appropriate toolbar class)\\
<wx/tbarbase.h> (the base class)\\
<wx/tbarmsw.h> (the non-Windows 95 Windows toolbar class)\\
<wx/tbar95.h> (the Windows 95/98 toolbar class)\\
\docparam{id}{Window identifier. If -1, will automatically create an identifier.}
-\docparam{pos}{Window position. wxDefaultPosition is (-1, -1) which indicates that wxWindows
+\docparam{pos}{Window position. wxDefaultPosition is (-1, -1) which indicates that wxWidgets
should generate a default position for the window. If using the wxWindow class directly, supply
an actual position.}
-\docparam{size}{Window size. wxDefaultSize is (-1, -1) which indicates that wxWindows
+\docparam{size}{Window size. wxDefaultSize is (-1, -1) which indicates that wxWidgets
should generate a default size for the window.}
\docparam{style}{Window style. See \helpref{wxToolBar}{wxtoolbar} for details.}
\wxheading{Remarks}
-With some derived toolbar classes, if the mouse moves quickly out of the toolbar, wxWindows may not be able to
+With some derived toolbar classes, if the mouse moves quickly out of the toolbar, wxWidgets may not be able to
detect it. Therefore this function may not always be called when expected.
\membersection{wxToolBar::OnRightClick}\label{wxtoolbaronrightclick}
The printing framework relies on the application to provide classes
whose member functions can respond to particular requests, such
as `print this page' or `does this page exist in the document?'.
-This method allows wxWindows to take over the housekeeping duties of
+This method allows wxWidgets to take over the housekeeping duties of
turning preview pages, calling the print dialog box, creating
the printer device context, and so on: the application can concentrate
on the rendering of the information onto a device context.
it is to initiate printing, previewing and the print setup dialog, once the wxPrintout
functionality has been defined. Notice the use of MyPrintout for
both printing and previewing. All the preview user interface functionality
-is taken care of by wxWindows. For details on how MyPrintout is defined,
+is taken care of by wxWidgets. For details on how MyPrintout is defined,
please look at the printout sample code.
\begin{verbatim}
storage hard to implement.
Most C++ GUI frameworks overcome these limitations by means of a set of
-macros and functions and wxWindows is no exception. As it originated before the
+macros and functions and wxWidgets is no exception. As it originated before the
addition of RTTI to the standard C++ and as support for it still missing from
-some (albeit old) compilers, wxWindows doesn't (yet) use it, but provides its
+some (albeit old) compilers, wxWidgets doesn't (yet) use it, but provides its
own macro-based RTTI system.
In the future, the standard C++ RTTI will be used though and you're encouraged
to use whenever possible \helpref{wxDynamicCast()}{wxdynamiccast} macro which,
for the implementations that support it, is defined just as dynamic\_cast<> and
-uses wxWindows RTTI for all the others. This macro is limited to wxWindows
+uses wxWidgets RTTI for all the others. This macro is limited to wxWidgets
classes only and only works with pointers (unlike the real dynamic\_cast<> which
also accepts references).
%% Modified by:
%% Created: 02.11.99
%% RCS-ID: $Id$
-%% Copyright: (c) wxWindows team
-%% License: wxWindows license
+%% Copyright: (c) wxWidgets team
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% NB: please keep the subsections in alphabetic order!
-\section{wxWindows samples}\label{samples}
+\section{wxWidgets samples}\label{samples}
-Probably the best way to learn wxWindows is by reading the source of some 50+
-samples provided with it. Many aspects of wxWindows programming can be learnt
+Probably the best way to learn wxWidgets is by reading the source of some 50+
+samples provided with it. Many aspects of wxWidgets programming can be learnt
from them, but sometimes it is not simple to just choose the right sample to
look at. This overview aims at describing what each sample does/demonstrates to
make it easier to find the relevant one if a simple grep through all sources
didn't help. They also provide some notes about using the samples and what
-features of wxWindows are they supposed to test.
+features of wxWidgets are they supposed to test.
-There are currently more than 50 different samples as part of wxWindows and
-this list is not complete. You should start your tour of wxWindows with the
-\helpref{minimal sample}{sampleminimal} which is the wxWindows version of
-"Hello, world!". It shows the basic structure of wxWindows program and is the
+There are currently more than 50 different samples as part of wxWidgets and
+this list is not complete. You should start your tour of wxWidgets with the
+\helpref{minimal sample}{sampleminimal} which is the wxWidgets version of
+"Hello, world!". It shows the basic structure of wxWidgets program and is the
most commented sample of all - looking at its source code is recommended.
The next most useful sample is probably the \helpref{controls}{samplecontrols}
-one which shows many of wxWindows standard controls, such as buttons,
+one which shows many of wxWidgets standard controls, such as buttons,
listboxes, checkboxes, comboboxes etc.
Other, more complicated controls, have their own samples. In this category you
Finally, it might be helpful to do a search in the entire sample directory if
you can't find the sample you showing the control you are interested in by
-name. Most of wxWindows classes, occur in at least one of the samples.
+name. Most of wxWidgets classes, occur in at least one of the samples.
\subsection{Minimal sample}\label{sampleminimal}
The minimal sample is what most people will know under the term Hello World,
i.e. a minimal program that doesn't demonstrate anything apart from what is
needed to write a program that will display a "hello" dialog. This is usually
-a good starting point for learning how to use wxWindows.
+a good starting point for learning how to use wxWidgets.
\subsection{Art provider sample}\label{sampleartprovider}
The {\tt artprov} sample shows how you can customize the look of standard
-wxWindows dialogs by replacing default bitmaps/icons with your own versions.
+wxWidgets dialogs by replacing default bitmaps/icons with your own versions.
It also shows how you can use wxArtProvider to
get stock bitmaps for use in your application.
\subsection{Controls sample}\label{samplecontrols}
The controls sample is the main test program for most simple controls used in
-wxWindows. The sample tests their basic functionality, events, placement,
+wxWidgets. The sample tests their basic functionality, events, placement,
modification in terms of colour and font as well as the possibility to change
the controls programmatically, such as adding item to a list box etc. Apart
from that, the sample uses a \helpref{wxNotebook}{wxnotebook} and tests most
\subsection{Dialogs sample}\label{sampledialogs}
-This sample shows how to use the common dialogs available from wxWindows. These
+This sample shows how to use the common dialogs available from wxWidgets. These
dialogs are described in details in the \helpref{Common dialogs overview}{commondialogsoverview}.
shown in a new frame.
So far, everything we mentioned was implemented with minimal amount of code
-using standard wxWindows classes. The more advanced features are demonstrated
+using standard wxWidgets classes. The more advanced features are demonstrated
if you create a shape frame from the main frame menu. A shape is a geometric
object which has a position, size and color. It models some
application-specific data in this sample. A shape object supports its own
should be used whenever it is not known at compile time, which control
will receive which event or which controls are actually going to be in
a dialog or frame. This is most typically the case for any scripting
-language that would work as a wrapper for wxWindows or programs where
+language that would work as a wrapper for wxWidgets or programs where
forms or similar datagrams can be created by the uses.
See also the \helpref{event sample}{sampleevent}
\subsection{Event sample}\label{sampleevent}
-The event sample demonstrates various features of the wxWindows events. It
+The event sample demonstrates various features of the wxWidgets events. It
shows using dynamic events and connecting/disconnecting the event handlers
during the run time and also using
\helpref{PushEventHandler()}{wxwindowpusheventhandler} and
\subsection{Except(ions) sample}\label{sampleexcept}
-This very simple sample shows how to use C++ exceptions in wxWindows programs,
+This very simple sample shows how to use C++ exceptions in wxWidgets programs,
i.e. where to catch the exception which may be thrown by the program code. It
doesn't do anything very exciting by itself, you need to study its code to
understand what goes on.
The font sample demonstrates \helpref{wxFont}{wxfont},
\helpref{wxFontEnumerator}{wxfontenumerator} and
\helpref{wxFontMapper}{wxfontmapper} classes. It allows you to see the fonts
-available (to wxWindows) on the computer and shows all characters of the
+available (to wxWidgets) on the computer and shows all characters of the
chosen font as well.
{\bf About} may give you an idea how to write good-looking about boxes.
{\bf Zip} demonstrates use of virtual file systems in wxHTML. The zip archives
-handler (ships with wxWindows) allows you to access HTML pages stored
+handler (ships with wxWidgets) allows you to access HTML pages stored
in compressed archive as if they were ordinary files.
{\bf Virtual} is yet another virtual file systems demo. This one generates pages at run-time.
\subsection{Internat(ionalization) sample}\label{sampleinternat}
-The not very clearly named internat sample demonstrates the wxWindows
+The not very clearly named internat sample demonstrates the wxWidgets
internatationalization (i18n for short from now on) features. To be more
precise, it only shows localization support, i.e. support for translating the
program messages in another language while true i18n would also involve
\subsection{Layout sample}\label{samplelayout}
The layout sample demonstrates the two different layout systems offered
-by wxWindows. When starting the program, you will see a frame with some
+by wxWidgets. When starting the program, you will see a frame with some
controls and some graphics. The controls will change their size whenever
you resize the entire frame and the exact behaviour of the size changes
is determined using the \helpref{wxLayoutConstraints}{wxlayoutconstraints}
\subsection{Render sample}\label{samplerender}
-This sample shows how to replace the default wxWindows
+This sample shows how to replace the default wxWidgets
\helpref{renderer}{wxrenderernative} and also how to write a shared library
(DLL) implementing a renderer and load and unload it during the run-time.
\helpref{SetTargetWindow}{wxscrolledwindowsettargetwindow} method and thus the effect
of scrolling does not show in the scrolled window itself, but in one of its subwindows.
-Additionally, this samples demonstrates how to optimize drawing operations in wxWindows,
+Additionally, this samples demonstrates how to optimize drawing operations in wxWidgets,
in particular using the \helpref{wxWindow::IsExposed}{wxwindowisexposed} method with
the aim to prevent unnecessary drawing in the window and thus reducing or removing
flicker on screen.
access the GUI class simultaneously. One way to prevent that is have a normal
GUI program in the main thread and some worker threads which work in the
background. In order to make communication between the main thread and the
-worker threads possible, wxWindows offers the \helpref{wxPostEvent}{wxpostevent}
+worker threads possible, wxWidgets offers the \helpref{wxPostEvent}{wxpostevent}
function and this sample makes use of this function.
The other way to use a so called Mutex (such as those offered in the \helpref{wxMutex}{wxmutex}
class) that prevent threads from accessing the GUI classes as long as any other
-thread accesses them. For this, wxWindows has the \helpref{wxMutexGuiEnter}{wxmutexguienter}
+thread accesses them. For this, wxWidgets has the \helpref{wxMutexGuiEnter}{wxmutexguienter}
and \helpref{wxMutexGuiLeave}{wxmutexguileave} functions, both of which are
used and tested in the sample as well.
Classes: \helpref{wxWindow}{wxwindow}, \helpref{wxScrolledWindow}{wxscrolledwindow}, \helpref{wxIcon}{wxicon}, \helpref{wxScrollBar}{wxscrollbar}.
-Scrollbars come in various guises in wxWindows. All windows have the potential
+Scrollbars come in various guises in wxWidgets. All windows have the potential
to show a vertical scrollbar and/or a horizontal scrollbar: it is a basic capability of a window.
However, in practice, not all windows do make use of scrollbars, such as a single-line wxTextCtrl.
call into a function named AdjustScrollbars, which can be called initially and also
from your \helpref{wxSizeEvent}{wxsizeevent} handler function.
-%\normalbox{{\bf For Windows programmers:} note that scrollbar range in wxWindows has a different meaning
+%\normalbox{{\bf For Windows programmers:} note that scrollbar range in wxWidgets has a different meaning
%from that in Windows. In native Windows scrollbar calls, range is the number of positions that the scrollbar
%can physically scroll through - in our example above, it would be 34. But it is easier
%to think in terms of the number of units that the whole scrollbar represents - the virtual
-%window size - which is why wxWindows does it differently.}
+%window size - which is why wxWidgets does it differently.}
\helpref{CreateButtonSizer}{createbuttonsizer}
Sizers, as represented by the wxSizer class and its descendants in
-the wxWindows class hierarchy, have become the method of choice to
-define the layout of controls in dialogs in wxWindows because of
+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. Unlike the original wxWindows Dialog Editor,
+the individual controls. Unlike the original wxWidgets Dialog Editor,
editors such as wxDesigner, DialogBlocks, wxrcedit, XRCed and wxWorkshop create dialogs based exclusively on sizers,
practically forcing the user to create platform independent layouts without compromises.
The next section describes and shows what can be done with sizers.
The following sections briefly describe how to program with individual sizer classes.
-For information about the new wxWindows resource system, which can describe
+For information about the new wxWidgets resource system, which can describe
sizer-based dialogs, see the \helpref{XML-based resource system overview}{xrcoverview}.
\subsection{The idea behind sizers}\label{ideabehindsizers}
-The layout algorithm used by sizers in wxWindows is closely related to layout
+The layout algorithm used by sizers in wxWidgets is closely related to layout
systems in other GUI toolkits, such as Java's AWT, the GTK toolkit or the Qt toolkit. It is
based upon the idea of individual subwindows reporting their minimal required
size and their ability to get stretched if the size of the parent window has changed.
and thus does not interfere with tab ordering and requires very few resources compared
to a real window on screen.
-What makes sizers so well fitted for use in wxWindows is the fact that every control
+What makes sizers so well fitted for use in wxWidgets is the fact that every control
reports its own minimal size and the algorithm can handle differences in font sizes
or different window (dialog item) sizes on different platforms without problems. For example, if
the standard font as well as the overall design of Linux/GTK widgets requires more space than
on Windows, the initial dialog size will automatically be bigger on Linux/GTK than on Windows.
-There are currently five different kinds of sizers available in wxWindows. Each represents
+There are currently five different kinds of sizers available in wxWidgets. Each represents
either a certain way to lay out dialog items in a dialog or it fulfils a special task
such as wrapping a static box around a dialog item (or another sizer). These sizers will
be discussed one by one in the text below. For more detailed information on how to use sizers
{\bf A minimal size:} This minimal size is usually identical to
the initial size of the controls and may either be set explicitly in the wxSize field
-of the control constructor or may be calculated by wxWindows, typically by setting
+of the control constructor or may be calculated by wxWidgets, typically by setting
the height and/or the width of the item to -1. Note that only some controls can
calculate their size (such as a checkbox) whereas others (such as a listbox)
don't have any natural width or height and thus require an explicit size. Some controls
with them and using iostreams on Linux makes writing programs, that are
binary compatible across different Linux distributions, impossible.
-Therefore, wxStreams have been added to wxWindows because an application should
+Therefore, wxStreams have been added to wxWidgets because an application should
compile and run on all supported platforms and we don't want users to depend on release
X.XX of libg++ or some other compiler to run the program.
As I said previously, we could add a filter stream so it takes an istream
argument and builds a wxInputStream from it: I don't think it should
-be difficult to implement it and it may be available in the fix of wxWindows 2.0.
+be difficult to implement it and it may be available in the fix of wxWidgets 2.0.
which may be enabled to fine tune the memory allocation strategy for your
particular application - and the gain might be quite big.
\item {\bf Compatibility} This class tries to combine almost full compatibility
-with the old wxWindows 1.xx wxString class, some reminiscence to MFC CString
+with the old wxWidgets 1.xx wxString class, some reminiscence to MFC CString
class and 90\% of the functionality of std::string class.
\item {\bf Rich set of functions} Some of the functions present in wxString are
very useful but don't exist in most of other string classes: for example,
to and from ANSI and Unicode strings in any build mode (see the
\helpref{Unicode overview}{unicode} for more details) and maps to either
{\tt string} or {\tt wstring} transparently depending on the current mode.
-\item {\bf Used by wxWindows} And, of course, this class is used everywhere
-inside wxWindows so there is no performance loss which would result from
+\item {\bf Used by wxWidgets} And, of course, this class is used everywhere
+inside wxWidgets so there is no performance loss which would result from
conversions of objects of any other string class (including std::string) to
-wxString internally by wxWindows.
+wxString internally by wxWidgets.
\end{enumerate}
However, there are several problems as well. The most important one is probably
length(), \helpref{Len()}{wxstringlen} or
\helpref{Length()}{wxstringlength} may be used. The first function, as almost
all the other functions in lowercase, is std::string compatible. The second one
-is "native" wxString version and the last one is wxWindows 1.xx way. So the
+is "native" wxString version and the last one is wxWidgets 1.xx way. So the
question is: which one is better to use? And the answer is that:
{\bf The usage of std::string compatible functions is strongly advised!} It will
both make your code more familiar to other C++ programmers (who are supposed to
have knowledge of std::string but not of wxString), let you reuse the same code
-in both wxWindows and other programs (by just typedefing wxString as std::string
-when used outside wxWindows) and by staying compatible with future versions of
-wxWindows which will probably start using std::string sooner or later too.
+in both wxWidgets and other programs (by just typedefing wxString as std::string
+when used outside wxWidgets) and by staying compatible with future versions of
+wxWidgets which will probably start using std::string sooner or later too.
In the situations where there is no corresponding std::string function, please
-try to use the new wxString methods and not the old wxWindows 1.xx variants
+try to use the new wxString methods and not the old wxWidgets 1.xx variants
which are deprecated and may disappear in future versions.
\subsection{Some advice about using wxString}\label{wxstringadvices}
\helpref{wxCriticalSection}{wxcriticalsection},
\helpref{wxCondition}{wxcondition}
-wxWindows provides a complete set of classes encapsulating objects necessary in
+wxWidgets provides a complete set of classes encapsulating objects necessary in
multithreaded (MT) programs: the \helpref{thread}{wxthread} class itself and different
synchronization objects: \helpref{mutexes}{wxmutex} and
\helpref{critical sections}{wxcriticalsection} with
-\helpref{conditions}{wxcondition}. The thread API in wxWindows resembles to
+\helpref{conditions}{wxcondition}. The thread API in wxWidgets resembles to
POSIX1.c threads API (a.k.a. pthreads), although several functions have
different names and some features inspired by Win32 thread API are there as
well.
the advanced users of the program, the experience shows that the tips may be
quite helpful for the novices and so more and more programs now do this.
-For a wxWindows programmer, implementing this feature is extremely easy. To
+For a wxWidgets programmer, implementing this feature is extremely easy. To
show a tip, it is enough to just call \helpref{wxShowTip}{wxshowtip} function
like this:
menus, which have to be popped up and selected rather laboriously.
Instead of supplying one toolbar class with a number
-of different implementations depending on platform, wxWindows separates
+of different implementations depending on platform, wxWidgets separates
out the classes. This is because there are a number of different toolbar
styles that you may wish to use simultaneously, and also, future
toolbar implementations will emerge which
\begin{itemize}\itemsep=0pt
\item {\bf wxToolBarBase.} This is a base class with pure virtual functions,
and should not be used directly.
-\item {\bf wxToolBarSimple.} A simple toolbar class written entirely with generic wxWindows
+\item {\bf wxToolBarSimple.} A simple toolbar class written entirely with generic wxWidgets
functionality. A simple 3D effect for buttons is possible, but it is not consistent
with the Windows look and feel. This toolbar can scroll, and you can have arbitrary
numbers of rows and columns.
// Created: 04/01/98
// RCS-ID: $Id$
// Copyright: (c) Julian Smart
-// License: wxWindows license
+// License: wxWidgets license
/////////////////////////////////////////////////////////////////////////////
// For compilers that support precompilation, includes "wx/wx.h".
frame->OnSize(event);
frame->Show(true);
- frame->SetStatusText("Hello, wxWindows");
+ frame->SetStatusText("Hello, wxWidgets");
SetTopWindow(frame);
void MyFrame::OnAbout(wxCommandEvent& WXUNUSED(event))
{
- (void)wxMessageBox("wxWindows toolbar sample", "About wxToolBar");
+ (void)wxMessageBox("wxWidgets toolbar sample", "About wxToolBar");
}
// Define the behaviour for the frame closing
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Name: tunicode.tex
-%% Purpose: Overview of the Unicode support in wxWindows
+%% Purpose: Overview of the Unicode support in wxWidgets
%% Author: Vadim Zeitlin
%% Modified by:
%% Created: 22.09.99
%% RCS-ID: $Id$
%% Copyright: (c) 1999 Vadim Zeitlin <zeitlin@dptmaths.ens-cachan.fr>
-%% Licence: wxWindows license
+%% Licence: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\section{Unicode support in wxWindows}\label{unicode}
+\section{Unicode support in wxWidgets}\label{unicode}
-This section briefly describes the state of the Unicode support in wxWindows.
+This section briefly describes the state of the Unicode support in wxWidgets.
Read it if you want to know more about how to write programs able to work with
characters from languages other than English.
\subsection{What is Unicode?}
-Starting with release 2.1 wxWindows has support for compiling in Unicode mode
+Starting with release 2.1 wxWidgets has support for compiling in Unicode mode
on the platforms which support it. Unicode is a standard for character
encoding which addresses the shortcomings of the previous, 8 bit standards, by
using at least 16 (and possibly 32) bits for encoding each character. This
\subsection{Unicode and ANSI modes}
-As not all platforms supported by wxWindows support Unicode (fully) yet, in
+As not all platforms supported by wxWidgets support Unicode (fully) yet, in
many cases it is unwise to write a program which can only work in Unicode
environment. A better solution is to write programs in such way that they may
be compiled either in ANSI (traditional) mode or in the Unicode one.
-This can be achieved quite simply by using the means provided by wxWindows.
+This can be achieved quite simply by using the means provided by wxWidgets.
Basically, there are only a few things to watch out for:
\begin{itemize}
And finally, the standard preprocessor tokens enumerated above expand to ANSI
strings but it is more likely that Unicode strings are wanted in the Unicode
-build. wxWindows provides the macros {\tt \_\_TFILE\_\_}, {\tt \_\_TDATE\_\_}
+build. wxWidgets provides the macros {\tt \_\_TFILE\_\_}, {\tt \_\_TDATE\_\_}
and {\tt \_\_TTIME\_\_} which behave exactly as the standard ones except that
they produce ANSI strings in ANSI build and Unicode ones in the Unicode build.
program would have had!). Luckily, there is another way - see the next
section.
-\subsection{Unicode support in wxWindows}
+\subsection{Unicode support in wxWidgets}
-In wxWindows, the code fragment from above should be written instead:
+In wxWidgets, the code fragment from above should be written instead:
\begin{verbatim}
wxChar ch = wxT('*');
\item Always use {\tt wxChar} instead of {\tt char}
\item Always enclose literal string constants in \helpref{wxT()}{wxt} macro
unless they're already converted to the right representation (another standard
-wxWindows macro \helpref{\_()}{underscore} does it, for example, so there is no
+wxWidgets macro \helpref{\_()}{underscore} does it, for example, so there is no
need for {\tt wxT()} in this case) or you intend to pass the constant directly
to an external function which doesn't accept wide-character strings.
\item Use {\tt wxString} instead of C style strings.
\subsection{Unicode and the outside world}
-We have seen that it was easy to write Unicode programs using wxWindows types
+We have seen that it was easy to write Unicode programs using wxWidgets types
and macros, but it has been also mentioned that it isn't quite enough.
Although everything works fine inside the program, things can get nasty when
it tries to communicate with the outside world which, sadly, often expects
You should define {\tt wxUSE\_UNICODE} to $1$ to compile your program in
Unicode mode. Note that it currently only works in Win32 and GTK 2.0 and
that some parts of
-wxWindows are not Unicode-compliant yet (ODBC classes, for example). If you
+wxWidgets are not Unicode-compliant yet (ODBC classes, for example). If you
compile your program in ANSI mode you can still define {\tt wxUSE\_WCHAR\_T}
to get some limited support for {\tt wchar\_t} type.
\section{Notes on using the reference}\label{referencenotes}
-In the descriptions of the wxWindows classes and their member
+In the descriptions of the wxWidgets classes and their member
functions, note that descriptions of inherited member functions are not
duplicated in derived classes unless their behaviour is different. So in
using a class such as wxScrolledWindow, be aware that wxWindow functions may be
Note also that arguments with default values may be omitted from a
function call, for brevity. Size and position arguments may usually be
-given a value of -1 (the default), in which case wxWindows will choose a
+given a value of -1 (the default), in which case wxWidgets will choose a
suitable value.
Most strings are returned as wxString objects. However, for remaining
char * return values, the strings are allocated and
-deallocated by wxWindows. Therefore, return values should always be
+deallocated by wxWidgets. Therefore, return values should always be
copied for long-term use, especially since the same buffer is often
-used by wxWindows.
+used by wxWidgets.
The member functions are given in alphabetical order except for
constructors and destructors which appear first.
You can optionally define event handlers for the validator, to implement filtering. These handlers
will capture events before the control itself does.
-For an example implementation, see the valtext.h and valtext.cpp files in the wxWindows library.
+For an example implementation, see the valtext.h and valtext.cpp files in the wxWidgets library.
\wxheading{How validators interact with dialogs}
Classes: \helpref{wxXmlResource}{wxxmlresource}, \helpref{wxXmlResourceHandler}{wxxmlresourcehandler}
-{\bf IMPORTANT NOTE:} XRC is not yet a part of the core wxWindows library, so
+{\bf IMPORTANT NOTE:} XRC is not yet a part of the core wxWidgets library, so
please see the next section for how to compile and link it. Otherwise if you
try to use it, you will get link errors.
\item You can choose between different alternative resource files at run time, if necessary.
\item The XRC format uses sizers for flexibility, allowing dialogs to be resizable
and highly portable.
-\item The XRC format is a wxWindows standard,
+\item The XRC format is a wxWidgets standard,
and can be generated or postprocessed by any program that understands it. As it is based
on the XML standard, existing XML editors can be used for simple editing purposes.
\end{itemize}
and compile. Also compile contrib/utils/wxrc using wxBase if you wish to compile
resource files.
\item Under Unix, XRC should be configured when you configured
-wxWindows. Make XRC by changing directory to contrib/src/xrc and
+wxWidgets. Make XRC by changing directory to contrib/src/xrc and
type 'make'. Similarly compile contrib/utils/wxrc using wxBase if you wish to compile
resource files. {\bf Note:} there is currently a
-problem with the wxWindows build system that means that
+problem with the wxWidgets build system that means that
only the static version of library can be built at present.
\end{itemize}
\item use \urlref{wxDesigner}{http://www.roebling.de}, a commercial dialog designer/RAD tool;
\item use \urlref{DialogBlocks}{http://www.anthemion.co.uk/dialogblocks}, a commercial dialog editor;
\item use \urlref{XRCed}{http://xrced.sf.net}, a wxPython-based
-dialog editor that you can find in the {\tt wxPython/tools} subdirectory of the wxWindows
+dialog editor that you can find in the {\tt wxPython/tools} subdirectory of the wxWidgets
CVS archive;
\item use \urlref{Glade}{http://wxglade.sf.net}, a GUI designer written in wxPython. At the moment it can generate Python, C++ and XRC;
\item use wxrcedit ({\tt utils/contrib/wxrcedit}) (under development);
\item convert WIN32 RC files to XRC with the tool in {\tt contrib/utils/convertrc}.
\end{itemize}
-A complete list of third-party tools that write to XRC can be found at \urlref{www.wxwindows.org/lnk\_tool.htm}{http://www.wxwindows.org/lnk\_tool.in}.
+A complete list of third-party tools that write to XRC can be found at \urlref{www.wxwidgets.org/lnk\_tool.htm}{http://www.wxwidgets.org/lnk\_tool.in}.
It is highly recommended that you use a resource editing tool, since it's fiddly writing
XRC files by hand.
void OnDlg2(wxCommandEvent& event);
private:
- // any class wishing to process wxWindows events must use this macro
+ // any class wishing to process wxWidgets events must use this macro
DECLARE_EVENT_TABLE()
};
// ----------------------------------------------------------------------------
-// event tables and other macros for wxWindows
+// event tables and other macros for wxWidgets
// ----------------------------------------------------------------------------
BEGIN_EVENT_TABLE(MyFrame, wxFrame)
\subsection{XRC file format}\label{xrcfileformat}
-Please see Technical Note 14 (docs/tech/tn0014.txt) in your wxWindows
+Please see Technical Note 14 (docs/tech/tn0014.txt) in your wxWidgets
distribution.
\subsection{C++ header file generation}\label{xrccppheader}
Returns the text associated with the data object. You may wish to override
this method when offering data on-demand, but this is not required by
-wxWindows' internals. Use this method to get data in text form from
+wxWidgets' internals. Use this method to get data in text form from
the \helpref{wxClipboard}{wxclipboard}.
\membersection{wxTextDataObject::SetText}\label{wxtextdataobjectsettext}
\section{\class{wxUpdateUIEvent}}\label{wxupdateuievent}
-This class is used for pseudo-events which are called by wxWindows
+This class is used for pseudo-events which are called by wxWidgets
to give an application the chance to update various user interface elements.
\wxheading{Derived from}
an action is invoked for a menu item or button.
With update UI events, you define an event handler to look at the state of
-the application and change UI elements accordingly. wxWindows will call your
+the application and change UI elements accordingly. wxWidgets will call your
member functions in idle time, so you don't have to worry where to call this code.
In addition to being a clearer and more declarative method, it also means you
don't have to worry whether you're updating a toolbar or menubar identifier.
The same handler can update a menu item and toolbar button, if the identifier is the same.
Instead of directly manipulating the menu or button, you call functions in the event
-object, such as \helpref{wxUpdateUIEvent::Check}{wxupdateuieventcheck}. wxWindows
+object, such as \helpref{wxUpdateUIEvent::Check}{wxupdateuieventcheck}. wxWidgets
will determine whether such a call has been made, and which UI element to update.
These events will work for popup menus as well as menubars. Just before a menu is popped
handler for a window does not affect this because the events are sent from \helpref{wxWindow::OnInternalIdle}{wxwindowoninternalidle}
which is {\bf always} called in idle time.
-wxWindows tries to optimize update events on some platforms. On Windows
+wxWidgets tries to optimize update events on some platforms. On Windows
and GTK+, events for menubar items are only sent when the menu is about
to be shown, and not in idle time.
\constfunc{bool}{GetSetChecked}{\void}
-Returns true if the application has called {\bf SetChecked}. For wxWindows internal use only.
+Returns true if the application has called {\bf SetChecked}. For wxWidgets internal use only.
\membersection{wxUpdateUIEvent::GetSetEnabled}\label{wxupdateuieventgetsetenabled}
\constfunc{bool}{GetSetEnabled}{\void}
-Returns true if the application has called {\bf SetEnabled}. For wxWindows internal use only.
+Returns true if the application has called {\bf SetEnabled}. For wxWidgets internal use only.
\membersection{wxUpdateUIEvent::GetSetText}\label{wxupdateuieventgetsettext}
\constfunc{bool}{GetSetText}{\void}
-Returns true if the application has called {\bf SetText}. For wxWindows internal use only.
+Returns true if the application has called {\bf SetText}. For wxWidgets internal use only.
\membersection{wxUpdateUIEvent::GetText}\label{wxupdateuieventgettext}
\func{static wxUpdateUIMode}{GetMode}{\void}
-Static function returning a value specifying how wxWindows
+Static function returning a value specifying how wxWidgets
will send update events: to all windows, or only to those which specify that they
will process the events.
\func{static void}{SetMode}{\param{wxIdleMode }{mode}}
-Specify how wxWindows will send update events: to
+Specify how wxWidgets will send update events: to
all windows, or only to those which specify that they
will process the events.
\section{\class{wxView}}\label{wxview}
The view class can be used to model the viewing and editing component of
-an application's file-based data. It is part of the document/view framework supported by wxWindows,
+an application's file-based data. It is part of the document/view framework supported by wxWidgets,
and cooperates with the \helpref{wxDocument}{wxdocument}, \helpref{wxDocTemplate}{wxdoctemplate}
and \helpref{wxDocManager}{wxdocmanager} classes.
%% Created: 01.06.03
%% RCS-ID: $Id$
%% Copyright: (c) 2003 Vadim Zeitlin <vadim@wxwindows.org>
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxVListBox}}\label{wxvlistbox}
%% Created: 30.05.03
%% RCS-ID: $Id$
%% Copyright: (c) 2003 Vadim Zeitlin <vadim@wxwindows.org>
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxVScrolledWindow}}\label{wxvscrolledwindow}
have to worry about deleting them manually. Please see the \helpref{window
deletion overview}{windowdeletionoverview} for more information.
-Also note that in this, and many others, wxWindows classes some
+Also note that in this, and many others, wxWidgets classes some
\texttt{GetXXX()} methods may be overloaded (as, for example,
\helpref{GetSize}{wxwindowgetsize} or
\helpref{GetClientSize}{wxwindowgetclientsize}). In this case, the overloads
results in a virtual function name hiding at the derived class level (in
English, this means that the derived class has to override all overloaded
variants if it overrides any of them). To allow overriding them in the derived
-class, wxWindows uses a unique protected virtual \texttt{DoGetXXX()} method
+class, wxWidgets uses a unique protected virtual \texttt{DoGetXXX()} method
and all \texttt{GetXXX()} ones are forwarded to it, so overriding the former
changes the behaviour of the latter.
\docparam{id}{Window identifier. If -1, will automatically create an identifier.}
-\docparam{pos}{Window position. wxDefaultPosition is (-1, -1) which indicates that wxWindows
+\docparam{pos}{Window position. wxDefaultPosition is (-1, -1) which indicates that wxWidgets
should generate a default position for the window. If using the wxWindow class directly, supply
an actual position.}
-\docparam{size}{Window size. wxDefaultSize is (-1, -1) which indicates that wxWindows
+\docparam{size}{Window size. wxDefaultSize is (-1, -1) which indicates that wxWidgets
should generate a default size for the window. If no suitable size can be found, the
window will be sized to 20x20 pixels so that the window is visible but obviously not
correctly sized. }
Destructor. Deletes all subwindows, then deletes itself. Instead of using
the {\bf delete} operator explicitly, you should normally
-use \helpref{wxWindow::Destroy}{wxwindowdestroy} so that wxWindows
+use \helpref{wxWindow::Destroy}{wxwindowdestroy} so that wxWidgets
can delete a window only when it is safe to do so, in idle time.
\wxheading{See also}
Adds a child window. This is called automatically by window creation
functions so should not be required by the application programmer.
-Notice that this function is mostly internal to wxWindows and shouldn't be
+Notice that this function is mostly internal to wxWidgets and shouldn't be
called by the user code.
\wxheading{Parameters}
Directs all mouse input to this window. Call \helpref{wxWindow::ReleaseMouse}{wxwindowreleasemouse} to
release the capture.
-Note that wxWindows maintains the stack of windows having captured the mouse
+Note that wxWidgets maintains the stack of windows having captured the mouse
and when the mouse is released the capture returns to the window which had had
captured it previously and it is only really released if there were no previous
window. In particular, this means that you must release the mouse as many times
Does the window-specific updating after processing the update event.
This function is called by \helpref{wxWindow::UpdateWindowUI}{wxwindowupdatewindowui}
in order to check return values in the \helpref{wxUpdateUIEvent}{wxupdateuievent} and
-act appropriately. For example, to allow frame and dialog title updating, wxWindows
+act appropriately. For example, to allow frame and dialog title updating, wxWidgets
implements this function as follows:
\begin{verbatim}
This method is useful for visual appearance optimization (for example, it
is a good idea to use it before inserting large amount of text into a
wxTextCtrl under wxGTK) but is not implemented on all platforms nor for all
-controls so it is mostly just a hint to wxWindows and not a mandatory
+controls so it is mostly just a hint to wxWidgets and not a mandatory
directive.
%% The default implementation for \helpref{wxFrame::OnMenuHighlight}{wxframeonmenuhighlight} displays help
%% text in the first field of the status bar.
%%
-%% This function was known as {\bf OnMenuSelect} in earlier versions of wxWindows, but this was confusing
+%% This function was known as {\bf OnMenuSelect} in earlier versions of wxWidgets, but this was confusing
%% since a selection is normally a left-click action.
%%
%% \wxheading{See also}
Removes a child window. This is called automatically by window deletion
functions so should not be required by the application programmer.
-Notice that this function is mostly internal to wxWindows and shouldn't be
+Notice that this function is mostly internal to wxWidgets and shouldn't be
called by the user code.
\wxheading{Parameters}
created without a parent. It is useful for the windows which can disappear at
any moment as creating children of such windows results in fatal problems.}
\twocolitem{\windowstyle{wxFRAME\_EX\_CONTEXTHELP}}{Under Windows, puts a query button on the
-caption. When pressed, Windows will go into a context-sensitive help mode and wxWindows will send
+caption. When pressed, Windows will go into a context-sensitive help mode and wxWidgets will send
a wxEVT\_HELP event if the user clicked on an application window.
This style cannot be used together with wxMAXIMIZE\_BOX or wxMINIMIZE\_BOX, so
you should use the style of
\func{virtual void}{SetFocusFromKbd}{\void}
-This function is called by wxWindows keyboard navigation code when the user
+This function is called by wxWidgets keyboard navigation code when the user
gives the focus to this window from keyboard (e.g. using {\tt TAB} key).
By default this method simply calls \helpref{SetFocus}{wxwindowsetfocus} but
can be overridden to do something in addition to this in the derived classes.
\docparam{sizeFlags}{Indicates the interpretation of other parameters. It is a bit list of the following:
{\bf wxSIZE\_AUTO\_WIDTH}: a -1 width value is taken to indicate
-a wxWindows-supplied default width.\\
+a wxWidgets-supplied default width.\\
{\bf wxSIZE\_AUTO\_HEIGHT}: a -1 height value is taken to indicate
-a wxWindows-supplied default width.\\
+a wxWidgets-supplied default width.\\
{\bf wxSIZE\_AUTO}: -1 size values are taken to indicate
-a wxWindows-supplied default size.\\
+a wxWidgets-supplied default size.\\
{\bf wxSIZE\_USE\_EXISTING}: existing dimensions should be used
if -1 values are supplied.\\
{\bf wxSIZE\_ALLOW\_MINUS\_ONE}: allow dimensions of -1 and less to be interpreted
The first form sets the position and optionally size, of the window.
Parameters may be -1 to indicate either that a default should be supplied
-by wxWindows, or that the current value of the dimension should be used.
+by wxWidgets, or that the current value of the dimension should be used.
\wxheading{See also}
\wxheading{Remarks}
-SetSizer now enables and disables Layout automatically, but prior to wxWindows 2.3.3
+SetSizer now enables and disables Layout automatically, but prior to wxWidgets 2.3.3
the following applied:
You must call \helpref{wxWindow::SetAutoLayout}{wxwindowsetautolayout} to tell a window to use
are concerned). This may be necessary if you have called
\helpref{wxUpdateUIEvent::SetMode}{wxupdateuieventsetmode} or
\helpref{wxUpdateUIEvent::SetUpdateInterval}{wxupdateuieventsetupdateinterval} to
-limit the overhead that wxWindows incurs by sending update UI events in idle time.
+limit the overhead that wxWidgets incurs by sending update UI events in idle time.
{\it flags} should be a bitlist of one or more of the following values.
%% Created: 02.04.00
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxWizard}}\label{wxwizard}
Constructor which really creates the wizard -- if you use this constructor, you
shouldn't call \helpref{Create}{wxwizardcreate}.
-Notice that unlike almost all other wxWindows classes, there is no {\it size}
+Notice that unlike almost all other wxWidgets classes, there is no {\it size}
parameter in wxWizard constructor because the wizard will have a predefined
default size by default. If you want to change this, you should use the
\helpref{GetPageAreaSizer}{wxwizardgetpageareasizer} function.
Creates the wizard dialog. Must be called if the default constructor had been
used to create the object.
-Notice that unlike almost all other wxWindows classes, there is no {\it size}
+Notice that unlike almost all other wxWidgets classes, there is no {\it size}
parameter in wxWizard constructor because the wizard will have a predefined
default size by default. If you want to change this, you should use the
\helpref{GetPageAreaSizer}{wxwizardgetpageareasizer} function.
%% Created: 02.04.00
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxWizardEvent}}\label{wxwizardevent}
%% Created: 02.04.00
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxWizardPage}}\label{wxwizardpage}
%% Created: 03.03.00
%% RCS-ID: $Id$
%% Copyright: (c) Vadim Zeitlin
-%% License: wxWindows license
+%% License: wxWidgets license
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{\class{wxWindowDisabler}}\label{wxwindowdisabler}
%----------------------------------------------------------------------
\subsection{What is wxPython?}\label{wxpwhat}
-wxPython is a blending of the wxWindows GUI classes and the
+wxPython is a blending of the wxWidgets GUI classes and the
\urlref{Python}{http://www.python.org/} programming language.
\wxheading{Python}
wxPython is a Python package that can be imported at runtime that
includes a collection of Python modules and an extension module
(native code). It provides a series of Python classes that mirror (or
-shadow) many of the wxWindows GUI classes. This extension module
-attempts to mirror the class hierarchy of wxWindows as closely as
+shadow) many of the wxWidgets GUI classes. This extension module
+attempts to mirror the class hierarchy of wxWidgets as closely as
possible. This means that there is a wxFrame class in wxPython that
looks, smells, tastes and acts almost the same as the wxFrame class in
the C++ version.
%----------------------------------------------------------------------
\subsection{Why use wxPython?}\label{wxpwhy}
-So why would you want to use wxPython over just C++ and wxWindows?
+So why would you want to use wxPython over just C++ and wxWidgets?
Personally I prefer using Python for everything. I only use C++ when I
absolutely have to eke more performance out of an algorithm, and even
then I usually code it as an extension module and leave the majority
of the program in Python.
Another good thing to use wxPython for is quick prototyping of your
-wxWindows apps. With C++ you have to continuously go though the
+wxWidgets apps. With C++ you have to continuously go though the
edit-compile-link-run cycle, which can be quite time consuming. With
Python it is only an edit-run cycle. You can easily build an
application in a few hours with Python that would normally take a few
-days or longer with C++. Converting a wxPython app to a C++/wxWindows app
+days or longer with C++. Converting a wxPython app to a C++/wxWidgets app
should be a straight forward task.
%----------------------------------------------------------------------
I'm not going to try and teach the Python language here. You can do
that at the \urlref{Python Tutorial}{http://www.python.org/doc/tut/tut.html}.
-I'm also going to assume that you know a bit about wxWindows already,
+I'm also going to assume that you know a bit about wxWidgets already,
enough to notice the similarities in the classes used.
Take a look at the following wxPython program. You can find a similar
052: self.posCtrl.SetValue("%s, %s" % (pos.x, pos.y))
053:
054:
-055: # Every wxWindows application must have a class derived from wxApp
+055: # Every wxWidgets application must have a class derived from wxApp
056: class MyApp(wxApp):
057:
-058: # wxWindows calls this method to initialize the application
+058: # wxWidgets calls this method to initialize the application
059: def OnInit(self):
060:
061: # Create an instance of our customized Frame class
062: frame = MyFrame(NULL, -1, "This is a test")
063: frame.Show(true)
064:
-065: # Tell wxWindows that this is our main window
+065: # Tell wxWidgets that this is our main window
066: self.SetTopWindow(frame)
067:
068: # Return a success flag
example, "{\tt wx.wxFrame}".
\item At line 13 the frame's sizing and moving events are connected to
methods of the class. These helper functions are intended to be like
-the event table macros that wxWindows employs. But since static event
+the event table macros that wxWidgets employs. But since static event
tables are impossible with wxPython, we use helpers that are named the
same to dynamically build the table. The only real difference is
that the first argument to the event helpers is always the window that
have a \_\_del\_\_ method that explicitly causes the C++ object to be
deleted. If you ever have the need to forcibly delete a window, use
the Destroy() method as shown on line 36.
-\item Just like wxWindows in C++, wxPython apps need to create a class
+\item Just like wxWidgets in C++, wxPython apps need to create a class
derived from {\tt wxApp} (line 56) that implements a method named
{\tt OnInit}, (line 59.) This method should create the application's
main window (line 62) and use {\tt wxApp.SetTopWindow()} (line 66) to
-inform wxWindows about it.
+inform wxWidgets about it.
\item And finally, at line 72 an instance of the application class is
created. At this point wxPython finishes initializing itself, and calls
the {\tt OnInit} method to get things started. (The zero parameter here is
\end{enumerate}
%----------------------------------------------------------------------
-\subsection{wxWindows classes implemented in wxPython}\label{wxpclasses}
+\subsection{wxWidgets classes implemented in wxPython}\label{wxpclasses}
The following classes are supported in wxPython. Most provide nearly
full implementations of the public interfaces specified in the C++
\section{wxGTK port}\label{wxgtkport}
-wxGTK is a port of wxWindows using the GTK+ library available
+wxGTK is a port of wxWidgets using the GTK+ library available
from www.gtk.org. It makes use of GTK+'s native widgets wherever
-possible and uses wxWindows' generic controls when needed. GTK+
+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 the recently released
GTK+ 2.0 including Unicode support is work in progress.
\urlref{http://www.gtk.org}{http://www.gtk.org}
-In order to configure wxWindows to compile wxGTK you will
+In order to configure wxWidgets to compile wxGTK you will
need to type:
\begin{verbatim}
\section{wxMac port}\label{wxmacport}
-wxMac is a port of wxWindows for the Macintosh OS platform.
+wxMac is a port of wxWidgets for the Macintosh OS platform.
Currently MacOS 8.6 or higher, MacOS 9.0 or higher and
MacOS X 10.0 or higher are supported, although most development
effort goes into MacOS X support. wxMac can be compiled both
different versions. Support for MacOS 8.X and MacOS 9.X is
only available through CodeWarrior. wxMac uses the Carbon
API (and optionally the Classic API under MacOS 8.X). You
-will need wxWindows version 2.3.3 or higher for a stable
+will need wxWidgets version 2.3.3 or higher for a stable
version of wxMac.
For further information, please see the files in docs/mac
\section{wxMGL port}\label{wxmglport}
-wxMGL is a port of wxWindows using the MGL library available
+wxMGL is a port of wxWidgets using the MGL library available
from SciTech as the underlying graphics backend. wxMGL draws
its widgets using the wxUniversal widget set which is now
-part of wxWindows. MGL itself runs on a variety of platforms
+part of wxWidgets. MGL itself runs on a variety of platforms
including DOS, Linux hardware (similar to the Linux framebuffer)
and various graphics systems such as Win32, X11 and OS/2.
Note that currently MGL for Linux runs only on x86-based systems.
-You will need wxWindows 2.3.3 or higher and MGL 5.0 or higher.
+You will need wxWidgets 2.3.3 or higher and MGL 5.0 or higher.
The latter is available from
\urlref{http://www.scitechsoft.com/products/product\_download.html}{http://www.scitechsoft.com/products/product\_download.html}
-In order to configure wxWindows to compile wxMGL you will
+In order to configure wxWidgets to compile wxMGL you will
need to type:
\begin{verbatim}
\section{wxMSW port}\label{wxmswport}
-wxMSW is a port of wxWindows for the Windows platforms
+wxMSW is a port of wxWidgets for the Windows platforms
including Windows 95, 98, ME, 2000, NT, XP in ANSI and
Unicode mode (for Windows 95 through the MSLU extension
library). wxMSW ensures native look and feel for XP
-as well when using wxWindows version 2.3.3 or higher.
+as well when using wxWidgets version 2.3.3 or higher.
wxMSW can be compile with a great variety of compilers
including MS VC++, Borland 5.5, MinGW32, Cygwin and
Watcom as well as cross-compilation with a Linux hosted
\section{wxOS2 port}\label{wxos2port}
-wxOS2 is a port of wxWindows for the IBM OS/2 platform.
+wxOS2 is a port of wxWidgets for the IBM OS/2 platform.
It is currently under construction.
\helpref{Len()}{wxstringlen} and {\tt length()} which all return the string
length. In all cases of such duplication the {\tt std::string}-compatible
method ({\tt length()} in this case, always the lowercase version) should be
-used as it will ensure smoother transition to {\tt std::string} when wxWindows
+used as it will ensure smoother transition to {\tt std::string} when wxWidgets
starts using it instead of wxString.
\wxheading{Derived from}
\helpref{Pad}{wxstringpad}\\
\helpref{Truncate}{wxstringtruncate}
-\membersection{wxWindows 1.xx compatibility functions}
+\membersection{wxWidgets 1.xx compatibility functions}
-These functions are deprecated, please consider using new wxWindows 2.0
+These functions are deprecated, please consider using new wxWidgets 2.0
functions instead of them (or, even better, std::string compatible variants).
\helpref{SubString}{wxstringsubstring}\\
Converts the string or character from an ASCII, 7-bit form
to the native wxString representation. Most useful when using
-a Unicode build of wxWindows.
+a Unicode build of wxWidgets.
\membersection{wxString::GetChar}\label{wxstringgetchar}
\constfunc{const char*}{GetData}{\void}
-wxWindows compatibility conversion. Returns a constant pointer to the data in the string.
+wxWidgets compatibility conversion. Returns a constant pointer to the data in the string.
\membersection{wxString::GetWritableChar}\label{wxstringgetwritablechar}
\section{wxX11 port}\label{wxx11port}
-wxX11 is a port of wxWindows using X11 (The X Window System)
+wxX11 is a port of wxWidgets using X11 (The X Window System)
as the underlying graphics backend. wxX11 draws its widgets
-using the wxUniversal widget set which is now part of wxWindows.
+using the wxUniversal widget set which is now part of wxWidgets.
wxX11 is well-suited for a number of special applications such
as those running on systems with few resources (PDAs) or for
applications which need to use a special themed look. You will need
-wxWindows 2.3.2 or higher.
+wxWidgets 2.3.2 or higher.
-In order to configure wxWindows to compile wxX11 you will
+In order to configure wxWidgets to compile wxX11 you will
need to type:
\begin{verbatim}
For further information, please see the files in docs/x11
in the distribution. There is also a page on the use of
-wxWindows for embedded applications on the wxWindows web site.
+wxWidgets for embedded applications on the wxWidgets web site.
See \helpref{XML-based resource system overview}{xrcoverview} for details.
-{\bf NOTE:} XRC is not yet a part of the core wxWindows library, so
+{\bf NOTE:} XRC is not yet a part of the core wxWidgets library, so
please see the overview for how to compile and link it. Otherwise if you
try to use it, you will get link errors.
Initializes handlers for all supported controls/windows. This will
make the executable quite big because it forces linking against
-most of the wxWindows library.
+most of the wxWidgets library.
\membersection{wxXmlResource::Load}\label{wxxmlresourceload}
See \helpref{XML-based resource system overview}{xrcoverview} for details.
-{\bf NOTE:} XRC is not yet a part of the core wxWindows library, so
+{\bf NOTE:} XRC is not yet a part of the core wxWidgets library, so
please see the overview for how to compile and link it. Otherwise if you
try to use it, you will get link errors.
- wxWindows Library Licence, Version 3
+ wxWidgets Library Licence, Version 3
====================================
Copyright (c) 1998 Julian Smart, Robert Roebling et al
1. As a special exception, the copyright holders of this library give
permission for additional uses of the text contained in this release of
- the library as licenced under the wxWindows Library Licence, applying
+ the library as licenced under the wxWidgets Library Licence, applying
either version 3 of the Licence, or (at your option) any later version of
the Licence as published by the copyright holders of version 3 of the
Licence document.
- wxWindows Free Documentation Licence, Version 3
+ wxWidgets Free Documentation Licence, Version 3
===============================================
Copyright (c) 1998 Julian Smart, Robert Roebling et al
manual or piece of documentation under the conditions for verbatim
copying, provided also that any sections describing licensing conditions
for this manual, such as, in particular, the GNU General Public Licence,
- the GNU Library General Public Licence, and any wxWindows Licence are
+ the GNU Library General Public Licence, and any wxWidgets Licence are
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.
-wxWindows 2.5 for Mac installation
+wxWidgets 2.5 for Mac installation
----------------------------------
On MacOS X, you can download Apple's free developer tools (gcc
and associated headers and libraries, such as the Carbon API).
You can then use configure in a similar way to compiling
-wxWindows on Linux (or on Windows using MinGW or Cygwin). See
+wxWidgets on Linux (or on Windows using MinGW or Cygwin). See
'Apple Developer Tools' below for more details on using
configure.
7) type <YOUR OWN PASSWORD>
Note that while using this method is okay for development, it is not
-recommended that you require endusers to install wxWindows into their
+recommended that you require endusers to install wxWidgets into their
system directories in order to use your program. One way to avoid this
-is to configure wxWindows with --disable-shared. Another way to avoid
-it is to make a framework for wxWindows. Making frameworks is beyond
+is to configure wxWidgets with --disable-shared. Another way to avoid
+it is to make a framework for wxWidgets. Making frameworks is beyond
the scope of this document.
Note:
-Welcome to wxWindows/Mac 2
+Welcome to wxWidgets/Mac 2
-More Information is available from the wxWindows project home page at
+More Information is available from the wxWidgets project home page at
-http://www.wxwindows.org
+http://www.wxwidgets.org
For more information, please see install.txt, todo.txt, and the
manuals.
Please send problems concerning installation, feature requests,
-bug reports or comments to the wxWindows users list. Information
-on how to subscribe is available from the wxWindows.org homepage.
+bug reports or comments to the wxWidgets users list. Information
+on how to subscribe is available from the wxWidgets.org homepage.
Questions/Problems related directly to the mac port can be sent directly
csomor@advancedconcepts.ch.
-wxWindows/Mac doesn't come with any guarantee whatsoever. It
+wxWidgets/Mac doesn't come with any guarantee whatsoever. It
might crash your harddisk or destroy your monitor. It doesn't
claim to be suitable for any special or general purpose.
-wxWindows 2.5 for MGL installation
+wxWidgets 2.5 for MGL installation
------------------------------------
IMPORTANT NOTE:
mailing wxwin-users or the author. Preferably, try to fix the
problem first and then send a patch to the author.
- When sending bug reports tell us what version of wxWindows you are
+ When sending bug reports tell us what version of wxWidgets you are
using (including the beta) and what compiler on what system. One
example: wxMGL 2.5.1, gcc 2.95.3, Redhat 7.0
- Download wxMGL-x.y.z.tgz, where x.y.z is the version number.
Download documentation in a preferred format, such as
- wxWindows-HTML.zip or wxWindows-PDF.zip.
+ wxWidgets-HTML.zip or wxWidgets-PDF.zip.
- Make a directory such as ~/wx and unarchive the files into this
directory.
- It is recommended that you install bison and flex; using yacc
and lex may require tweaking of the makefiles.
-- You can now use configure or makefiles to build wxWindows and the samples.
+- You can now use configure or makefiles to build wxWidgets and the samples.
In case of problems, please use GNU make.
These instructions apply to installation on a Unix system (such as Linux). Please
see bellow for information on using configure on non-Unix platforms.
-If you compile wxWindows on Linux for the first time and don't like to read
+If you compile wxWidgets on Linux for the first time and don't like to read
install instructions just do (in the base dir):
> ./configure --with-mgl
> ldconfig
> exit
-If you want to remove wxWindows on Unix you can do this:
+If you want to remove wxWidgets on Unix you can do this:
> su <type root password>
> make uninstall
'make install' will install wx-config script that can (and should) be used
to get compiler flags that are needed to build your program. wx-config --cxxflags
will output necessary C++ compiler flags and wx-config --libs will list all
-needed libraries. See an example of wxWindows application makefile:
+needed libraries. See an example of wxWidgets application makefile:
minimal: minimal.o
$(CC) -o minimal minimal.o `wx-config --libs`
> ./configure --with-mgl
> make
-in wxWindows top directory. You can build wxMGL in MS-DOS with configure, sorry.
+in wxWidgets top directory. You can build wxMGL in MS-DOS with configure, sorry.
* Building wxMGL for MS-DOS using Watcom C/C++
- Welcome to wxWindows/MGL 2.3
+ Welcome to wxWidgets/MGL 2.3
You have downloaded version 2.3 of the MGL port of
-the wxWindows GUI library. This runs on top of SciTech MGL library
+the wxWidgets GUI library. This runs on top of SciTech MGL library
(http://www.scitechsoft.com) that is available for variety of
operating systems and comes with support for embedded devices.
-More information about the wxWindows project as a whole
+More information about the wxWidgets project as a whole
can be found at:
- http://www.wxwindows.org
+ http://www.wxwidgets.org
Information on how to install can be found in the file
install.txt
Regards,
- The wxWindows team
+ The wxWidgets team
Julian Smart 2001-12-08
-This is a port of wxWindows to MicroWindows, under Linux.
+This is a port of wxWidgets to MicroWindows, under Linux.
Widgets are supplied by the wxUniversal project, while the
underlying port uses the Windows ports with small modifications
for the MicroWindows API.
Note: these are already applied by the patch below.
-- apply microwindows.patches (from wxWindows:
+- apply microwindows.patches (from wxWidgets:
docs/microwin/microwindows.patches) to fix PeekMessage
and other issues. If the patch doesn't apply automatically,
you may need to apply it by hand, and the relevant changed
for FILE_IO, even though for inline XPMs we don't need file I/O.
(Embedded systems tend not to have file I/O, anyway.)
-Now, wxWindows has its own XPM decoder, src/common/xpmdecod.cpp,
+Now, wxWidgets has its own XPM decoder, src/common/xpmdecod.cpp,
so in theory we don't need to use MicroWindows' code there.
wxImage can load an inline XPM, _but_ we need to convert to
a wxBitmap since this is what the widgets need.
-Notes for wxWindows compilation on AIX
+Notes for wxWidgets compilation on AIX
--------------------------------------
-wxWindows 2.0 has been compiled under AIX with the C set ++ 3.1.
+wxWidgets 2.0 has been compiled under AIX with the C set ++ 3.1.
The environment variables CC and CXX should be set accordingly before running
configure for the first time:
-wxWindows 2.5 for Motif installation
+wxWidgets 2.5 for Motif installation
------------------------------------
IMPORTANT NOTE:
mailing wx-users or the author. Preferably, try to fix the
problem first and then send a patch to the author.
- When sending bug reports tell us what version of wxWindows you are
+ When sending bug reports tell us what version of wxWidgets you are
using (including the beta) and what compiler on what system. One
example: wxMotif 2.5.1, gcc 2.95.4, Redhat 6.1
- Download wxX11-x.y.z.tgz, where x.y.z is the version number.
(wxMotif is included in the wxX11 distribution).
Download documentation in a preferred format, such as
- wxWindows-HTML.zip or wxWindows-PDF.zip.
+ wxWidgets-HTML.zip or wxWidgets-PDF.zip.
- Make a directory such as ~/wx and unarchive the files into this
directory.
- It is recommended that you install bison and flex; using yacc
and lex may require tweaking of the makefiles. You also need
libXpm (see comments in the Notes section below) if you want to have
- XPM support in wxWindows (recommended).
+ XPM support in wxWidgets (recommended).
-- You can now use configure to build wxWindows and the samples.
+- You can now use configure to build wxWidgets and the samples.
Using configure is the only way to build the library. If it doesn't
work for you for whatever reason, please report it (together with detailed
* The simplest case
-------------------
-If you compile wxWindows on Linux for the first time and don't like to read
+If you compile wxWidgets on Linux for the first time and don't like to read
install instructions just do (in the base dir):
> ./configure --with-motif
> ldconfig
> exit
-If you want to remove wxWindows on Unix you can do this:
+If you want to remove wxWidgets on Unix you can do this:
> su <type root password>
> make uninstall
* The expert case
-----------------
-If you want to do some more serious cross-platform programming with wxWindows,
+If you want to do some more serious cross-platform programming with wxWidgets,
such as for GTK and Motif, you can now build two complete libraries and use
them concurrently. For this end, you have to create a directory for each build
-of wxWindows - you may also want to create different versions of wxWindows
+of wxWidgets - you may also want to create different versions of wxWidgets
and test them concurrently. Most typically, this would be a version configured
with --enable-debug and one without. Note, that only one build can
currently be installed, so you'd have to use local version of the library for
* General
---------
-The Unix variants of wxWindows use GNU configure. If you have problems with
+The Unix variants of wxWidgets use GNU configure. If you have problems with
your make use GNU make instead.
-If you have general problems with installation, see the wxWindows website at
+If you have general problems with installation, see the wxWidgets website at
- http://www.wxwindows.org/
+ http://www.wxwidgets.org/
for newest information. If you still don't have any success, please send a bug
report to one of our mailing lists (see my homepage) INCLUDING A DESCRIPTION OF
* GUI libraries
---------------
-wxWindows/Motif requires the Motif library to be installed on your system. As
+wxWidgets/Motif requires the Motif library to be installed on your system. As
an alternative, you may also use the free library "lesstif" which implements
most of the Motif API without the licence restrictions of Motif.
* Additional libraries
----------------------
-wxWindows/Motif requires a thread library and X libraries known to work with
+wxWidgets/Motif requires a thread library and X libraries known to work with
threads. This is the case on all commercial Unix-Variants and all
Linux-Versions that are based on glibc 2 except RedHat 5.0 which is broken in
many aspects. As of writing this, virtually all Linux distributions have
Please send comments and question about the OS/2 installation
to Stefan Neis <Stefan.Neis@t-online.de> and patches to
-the wxWindows mailing list.
+the wxWidgets mailing list.
In the following list, the version numbers indicate the configuration that
was actually used by myself, newer version should cause no problems and
are enabled by default.
Many of the configure options have been thoroughly tested
-in wxWindows snapshot 6, but not yet all (ODBC not).
+in wxWidgets snapshot 6, but not yet all (ODBC not).
You have to add --with-motif on platforms, where Motif is
not the default (on Linux, configure will default to GTK).
--disable-shared Do not create shared libraries.
- --enable-monolithic Build wxWindows as single library instead
+ --enable-monolithic Build wxWidgets as single library instead
of as several smaller libraries (which is
- the default since wxWindows 2.5.0).
+ the default since wxWidgets 2.5.0).
--disable-optimise Do not optimise the code. Can
sometimes be useful for debugging
such as gdb (or its many frontends).
--enable-debug_flag Define __DEBUG__ and __WXDEBUG__ when
- compiling. This enable wxWindows' very
+ compiling. This enable wxWidgets' very
useful internal debugging tricks (such
as automatically reporting illegal calls)
to work. Note that program and library
-----------------
Many of the configure options have been thoroughly tested
-in wxWindows snapshot 6, but not yet all (ODBC not).
+in wxWidgets snapshot 6, but not yet all (ODBC not).
When producing an executable that is linked statically with wxGTK
you'll be surprised at its immense size. This can sometimes be
-drastically reduced by removing features from wxWindows that
+drastically reduced by removing features from wxWidgets that
are not used in your program. The most relevant such features
are
make install
-You can remove any traces of wxWindows by typing
+You can remove any traces of wxWidgets by typing
make uninstall
This is certain to become the standard way unless we decide
to stick to tmake.
-If your application uses only some of wxWindows libraries, you can
+If your application uses only some of wxWidgets libraries, you can
specify required libraries when running wx-config. For example,
`wx-config --libs=html,core` will only output link command to link
with libraries required by core GUI classes and wxHTML classes. See
the manual for more information on the libraries.
2) The other way creates a project within the source code
-directories of wxWindows. For this endeavour, you'll need
+directories of wxWidgets. For this endeavour, you'll need
GNU autoconf version 2.14 and add an entry to your Makefile.in
to the bottom of the configure.in script and run autoconf
and configure before you can type make.
# makewxmotif
# Sets permissions (in case we extracted wxMotif from zip files)
# and makes wxMotif.
- # Call from top-level wxWindows directory.
+ # Call from top-level wxWidgets directory.
# Note that this uses standard (but commonly-used) configure options;
# if you're feeling brave, you may wish to compile with threads:
# if they're not supported by the target platform, they will be disabled
-------:x-----Cut here-----:x-----
This script will build wxMotif using shared libraries. If you want to build
- a static wxWindows library, use --disable-shared.
+ a static wxWidgets library, use --disable-shared.
Troubleshooting
---------------
- Welcome to wxWindows/Motif 2.5.1
+ Welcome to wxWidgets/Motif 2.5.1
You have downloaded version 2.5.1 of the Motif port of
-the wxWindows GUI library.
+the wxWidgets GUI library.
-More information about the wxWindows project as a whole
+More information about the wxWidgets project as a whole
can be found at:
- http://www.wxwindows.org/
+ http://www.wxwidgets.org/
Information on how to install can be found in the file
install.txt, but if you cannot wait, this should work on
When you run into problems, please read the install.txt and
follow those instructions. If you still don't have any success,
please send a bug report to one of our mailing lists (see
-the wxWindows homepage) INCLUDING A DESCRIPTION OF YOUR SYSTEM AND
+the wxWidgets homepage) INCLUDING A DESCRIPTION OF YOUR SYSTEM AND
YOUR PROBLEM, SUCH AS YOUR VERSION OF MOTIF, WXMOTIF, WHAT
DISTRIBUTION YOU USE AND WHAT ERROR WAS REPORTED.
Alternatively, you may also use the bug reporting system
-linked from the wxWindows web page.
+linked from the wxWidgets web page.
The library produced by the install process will be called
libwx_motif.a (static) and libwx_motif-2.5.so.0.0.0 (shared) so that
-once a binary incompatible version of wxWindows/Motif comes out
+once a binary incompatible version of wxWidgets/Motif comes out
we'll augment the library version number to avoid linking problems.
Please send problems concerning installation, feature requests,
-bug reports or comments to the wxWindows users list. Information
-on how to subscribe is available from www.wxwindows.org.
+bug reports or comments to the wxWidgets users list. Information
+on how to subscribe is available from www.wxwidgets.org.
-wxWindows/Motif doesn't come with any guarantee whatsoever. It might
+wxWidgets/Motif doesn't come with any guarantee whatsoever. It might
crash your hard disk or destroy your monitor. It doesn't claim to be
suitable for any special or general purpose.
Regards,
- The wxWindows team
+ The wxWidgets team
-Installing wxWindows 2.5.1
+Installing wxWidgets 2.5.1
--------------------------
-This is wxWindows 2.5.1 for Microsoft Windows 9x/ME, Windows NT, Windows 2000
+This is wxWidgets 2.5.1 for Microsoft Windows 9x/ME, Windows NT, Windows 2000
and Windows XP. This is an unstable development release. Note that unstable in
this context doesn't mean that it crashes a lot, just that the library API may
change in backwards incompatible way during the 2.5 branch lifetime.
The setup program contains the following:
-- All common, generic and MSW-specific wxWindows source;
+- All common, generic and MSW-specific wxWidgets source;
- samples and demos;
- documentation in MS HTML Help format;
- makefiles for most Windows compilers, plus CodeWarrior,
If installing from the CVS server, copy include/wx/msw/setup0.h to
include/wx/msw/setup.h and edit the resulting file to choose
-the features you would like to compile wxWindows with[out].
+the features you would like to compile wxWidgets with[out].
Compilation
===========
-The following sections explain how to compile wxWindows with each supported
+The following sections explain how to compile wxWidgets with each supported
compiler. Search for one of Microsoft/Borland/Watcom/Symantec/Metrowerks/
Cygwin/Mingw32 to quickly locate the instructions for your compiler.
lib\bcc_lib Static libraries for Borland C++
lib\wat_dll Watcom C++ DLLs
-Names of compiled wxWindows libraries follow this scheme: libraries that don't
+Names of compiled wxWidgets libraries follow this scheme: libraries that don't
depend on GUI components begin with "wxbase" followed by version number and
letters indicating if the library is compiled as Unicode ('u') and/or debug
-build ('d'). Last component of them name is name of wxWindows component
+build ('d'). Last component of them name is name of wxWidgets component
(unless you built the library as single monolithic library; look for
"Configuring the build" below). This is a typical set of release ANSI build
libraries (release versions on left, debug on right side):
Using project files (VC++ 6 and later):
-1. Unarchive wxWindows-x.y.z-vc.zip, the VC++ 6 project
+1. Unarchive wxWidgets-x.y.z-vc.zip, the VC++ 6 project
makefiles (already included in wxMSW-x.y.z.zip and the setup version).
2. Open build\msw\wx.dsw, which has configurations for static
compilation or DLL compilation, and each of these available in
'nmake -f makefile.vc'
- to make the wxWindows core library as release DLL.
+ to make the wxWidgets core library as release DLL.
See "Configuring the build" for instruction how to build debug or static
libraries.
the headers. Alternatively, #undef new before including template headers.
You will also need to set wxUSE_IOSTREAMH to 0 if you will be
using templates, to avoid the non-template stream files being included
-within wxWindows.
+within wxWidgets.
Note (2): libraries and applications generated with makefiles and
project files are now (hopefully) compatible where static libraries
the project. After this, delete everything (including PCH) and recompile.
Note (4): to create your own IDE files, copy .dsp and .dsw
-files from an existing wxWindows sample and adapt them, or
+files from an existing wxWidgets sample and adapt them, or
visit http://wiki.wxwindows.org/wiki.pl?MSVC.
Borland C++ 5.0/5.5 compilation
Compiling using the makefiles (updated 24 Sept 02):
1. Change directory to build\msw. Type 'make -f makefile.bcc' to
- make the wxWindows core library. Ignore the compiler warnings.
+ make the wxWidgets core library. Ignore the compiler warnings.
This produces a couple of libraries in the lib\bcc_lib directory.
2. Change directory to a sample or demo such as samples\minimal, and type
'make -f makefile.bcc'. This produces a windows exe file - by default
in the bcc_mswd subdirectory.
-Note (1): the wxWindows makefiles assume dword structure alignment. Please
+Note (1): the wxWidgets makefiles assume dword structure alignment. Please
make sure that your own project or makefile settings use the
same alignment, or you could experience mysterious crashes. To
change the alignment, change CPPFLAGS in build\msw\config.bcc.
Note (2): if you get undefined _SQL... symbols at link time,
either install odbc32.lib from the BC++ CD-ROM into your BC++ lib
directory, or set wxUSE_ODBC to 0 in include\wx\msw\setup.h and
-recompile wxWindows. The same applies if compiling using the IDE.
+recompile wxWidgets. The same applies if compiling using the IDE.
Note (3): If you wish debug messages to be sent to the console in
debug mode, edit makefile.bcc and change /aa to /Tpe in link commands.
** REMEMBER **
-In all of your wxWindows applications, your source code should include
+In all of your wxWidgets applications, your source code should include
the following preprocessor directive:
#ifdef __BORLANDC__
Borland 16 Bit compilation for Windows 3.1
------------------------------------------
-The last version of wxWindows to support 16-bit compilation with Borland was
+The last version of wxWidgets to support 16-bit compilation with Borland was
2.2.7 - Please download and read the instructions in that release
Watcom C++ 10.6/11 and OpenWatcom compilation
---------------------------------------------
1. Change directory to build\msw. Type 'wmake -f makefile.wat' to
- make the wxWindows core library.
+ make the wxWidgets core library.
2. Change directory to samples\minimal and type 'wmake -f makefile.wat'
to make this sample. Repeat for other samples of interest.
will be rather confusing due to interactions with the MSL ANSI
and runtime libs.
-3. The project file to build the Win32 wxWindows libraries relies on the
+3. The project file to build the Win32 wxWidgets libraries relies on the
Batch File Runner plug-in. This plug-in is not installed as part of
a normal CW7 installation. However, you can find this plug-in on the
CodeWarrior Reference CD, in the Thrill Seekers folder; it's call the
include\wx\msw\setup.h (or include\wx\msw\setup0.h if you are
working from the CVS version) to lib\cw7mswd\include\wx\setup.h
-5. Import src\wxWindowsW7.xml to create the project file wxWindowsW7.mcp.
+5. Import src\wxWidgetsW7.xml to create the project file wxWidgetsW7.mcp.
Store this project file in directory src. You may get warnings about
not being able to find certain project paths; ignore these warnings, the
appropriate paths will be created during the build by the Batch File Runner.
Cygwin/MinGW compilation
------------------------
-wxWindows 2 supports Cygwin (formerly GnuWin32) betas and
+wxWidgets 2 supports Cygwin (formerly GnuWin32) betas and
releases, and MinGW. Cygwin can be downloaded from:
http://sources.redhat.com/cygwin/
Both Cygwin and MinGW can be used with configure (assuming you have MSYS
installed in case of MinGW). You will need new enough MinGW version, preferably
MinGW 2.0 (ships with gcc3) or at least 1.0 (gcc-2.95.3). GCC versions older
-than 2.95.3 don't work; you can use wxWindows 2.4 with them.
+than 2.95.3 don't work; you can use wxWidgets 2.4 with them.
NOTE: some notes specific to old Cygwin (< 1.1.x) are at the end of this
section (see OLD VERSIONS)
-There are two methods of compiling wxWindows, by using the
+There are two methods of compiling wxWidgets, by using the
makefiles provided or by using 'configure'.
Retrieve and install the latest version of Cygwin, or MinGW, as per
the instructions with either of these packages.
If using MinGW, you can download the add-on MSYS package to
-provide Unix-like tools that you'll need to build wxWindows using configure.
+provide Unix-like tools that you'll need to build wxWidgets using configure.
Using makefiles directly
------------------------
- If you are compiling with GCC 3.x using makefiles and with wxUSE_STL == 1
you need to manually add -DNO_GCC_PRAGMA to CXXFLAGS in config.gcc.
-- Use the makefile.gcc files for compiling wxWindows and samples,
- e.g. to compile a debugging version of wxWindows:
+- Use the makefile.gcc files for compiling wxWidgets and samples,
+ e.g. to compile a debugging version of wxWidgets:
> cd c:\wx\build\msw
> make -f makefile.gcc BUILD=debug
> cd c:\wx\samples\minimal
system to generate appropriate makefiles, as used on Unix
and Mac OS X systems.
-Change directory to the root of the wxWindows distribution,
+Change directory to the root of the wxWidgets distribution,
make a build directory, and run configure and make in this directory.
For example:
Notes:
1. See also the Cygwin/MinGW on the web site or CD-ROM for
- further information about using wxWindows with these compilers.
+ further information about using wxWidgets with these compilers.
2. libwx.a is 100 MB or more - but much less if compiled with no
debug info (-g0) and level 4 optimization (-O4).
as follows:
/usr/local/lib - wxmswXYZd.dll.a and wxmswXYZd.dll
- /usr/local/include/wx - wxWindows header files
+ /usr/local/include/wx - wxWidgets header files
/usr/local/bin - wx-config
You may need to do this if using wx-config with the
- For Cygwin, make sure there's a \tmp directory on your
Windows drive or bison will crash (actually you don't need
- bison for ordinary wxWindows compilation: a pre-generated .c file is
+ bison for ordinary wxWidgets compilation: a pre-generated .c file is
supplied).
- If using GnuWin32 b18, you will need to copy windres.exe
from http://www.digitalmars.com/download/freecompiler.html
2. Change directory to build\msw and type 'make -f makefile.dmc' to
- make the wxWindows core library.
+ make the wxWidgets core library.
3. Change directory to samples\minimal and type 'make -f makefile.dmc'
to make this sample. Most of the other samples also work.
Configuring the build
=====================
-So far the instructions only explained how to build release DLLs of wxWindows
+So far the instructions only explained how to build release DLLs of wxWidgets
and did not cover any configuration. It is possible to change many aspects of
the build, including debug/release and ANSI/Unicode settings. All makefiles in
build\msw directory use same options (with a few exceptions documented below)
where $(compiler) is same extension as the makefile you use has (see below).
The latter is good for setting options that never change in your development
process (e.g. GCC_VERSION or VENDOR). If you want to build several versions of
-wxWindows and use them side by side, the former method is better. Settings in
+wxWidgets and use them side by side, the former method is better. Settings in
config.* files are shared by all makefiles (samples, contrib, main library),
but if you pass the options as arguments, you must use same arguments you used
for the library when building samples or contrib libraries!
WXUNIV=1
Build wxUniversal instead of native wxMSW (see
- http://www.wxwindows.org/wxuniv.htm for more information).
+ http://www.wxwidgets.org/wxuniv.htm for more information).
Advanced options
----------------
MONOLITHIC=1
- Starting with version 2.5.1, wxWindows has the ability to be built as
+ Starting with version 2.5.1, wxWidgets has the ability to be built as
several smaller libraries instead of single big one as used to be the case
in 2.4 and older versions. This is called "multilib build" and is the
default behaviour of makefiles. You can still build single library
VENDOR=<your company name>
Set this to a short string identifying your company if you are planning to
- distribute wxWindows DLLs with your application. Default value is 'custom'.
- This string is included as part of DLL name. wxWindows DLLs contain compiler
+ distribute wxWidgets DLLs with your application. Default value is 'custom'.
+ This string is included as part of DLL name. wxWidgets DLLs contain compiler
name, version information and vendor name in them. For example
wxmsw250_core_bcc_custom.dll is one of DLLs build using Borland C++ with
default settings. If you set VENDOR=mycorp, the name will change to
wxmsw250_core_bcc_mycorp.dll.
CFG=<configuration name>
- Sets configuration name so that you can have multiple wxWindows builds with
+ Sets configuration name so that you can have multiple wxWidgets builds with
different setup.h settings coexisting in same tree. See "Object and library
directories" below for more information.
The solution is probably to load wxResourceBitListTable
dynamically using LoadString to load the names, and initialize the table
-at wxWindows start-up.
+at wxWidgets start-up.
Meanwhile the work-around is to switch wxUSE_WX_RESOURCES to 0
(done in setup.h if BC++/16-bit mode is detected).
-This is wxWindows for Windows (wxMSW)
+This is wxWidgets for Windows (wxMSW)
-------------------------------------
-For information on installing wxWindows, please see install.txt.
+For information on installing wxWidgets, please see install.txt.
For further information, please see docs/html/index.htm and the
-wxWindows reference manual.
+wxWidgets reference manual.
=================================================
- Welcome to wxWindows/CE 2.5.1
+ Welcome to wxWidgets/CE 2.5.1
=================================================
You have downloaded version 2.5.1 of the Windows CE port of
-the wxWindows GUI library. This runs on PocketPC 2002,
+the wxWidgets GUI library. This runs on PocketPC 2002,
SmartPhone 2002, and Windows CE .NET 4.x.
-More information about the wxWindows project as a whole
+More information about the wxWidgets project as a whole
can be found at:
- http://www.wxwindows.org
+ http://www.wxwidgets.org
Information about the Windows CE port in particular
can be found here:
You can install other targets but you will need
to create new configurations for them in the
-wxWindows project files.
+wxWidgets project files.
-wxWindows/CE Configuration
+wxWidgets/CE Configuration
================================
You may wish to customize the following file
Set this to 1 if you wish to compile for the SmartPhone
platform (with eVC++ 3).
-wxWindows/CE Compilation
+wxWidgets/CE Compilation
================================
-Open src/msw/wince/wxWindowsCE.vcp, select an
+Open src/msw/wince/wxWidgetsCE.vcp, select an
ARM or x86 target (or emulator target for eVC++ 4),
and compile.
To compile using the emulator on eVC++3:
-- Open src/msw/wince/wxWindowsCE.vcp, select the
+- Open src/msw/wince/wxWidgetsCE.vcp, select the
WIN32 (WCE x86) Debug Unicode configuration, close the dialog,
then select Pocket PC 2002 and Pocket PC 2002 Emulation on the toolbar,
and compile.
To compile using the emulator on eVC++4:
-- Open src/msw/wince/wxWindowsCE.vcp, select the
+- Open src/msw/wince/wxWidgetsCE.vcp, select the
WIN32 (WCE Emulator) Debug Unicode configuration, and compile.
- Open samples/minimal/minimalCE.vcp with eCV 4.0, select the
-Microsoft Windows XP Support from wxWindows
+Microsoft Windows XP Support from wxWidgets
-------------------------------------------
Windows XP introduces the themes (called "visual styles" in the Microsoft
-documentation) in Windows world. As wxWindows uses the standard Windows
+documentation) in Windows world. As wxWidgets uses the standard Windows
controls for most of its classes, it can take advantage of it without
(almost) any effort from your part. The only thing you need to do if you
want your program to honour the visual style setting of Windows XP is to
add the manifest file to your program (this is not at all specific to
-wxWindows programs but is required for all Windows applications).
+wxWidgets programs but is required for all Windows applications).
-wxWindows now includes manifest resources in wx.rc, so it should be enough to
+wxWidgets now includes manifest resources in wx.rc, so it should be enough to
include "wx/msw/wx.rc" in your application's resource file and you get
XP look automatically. If it doesn't work, follow the instructions below:
name="Controls"
type="win32"
/>
-<description>Controls: wxWindows sample application</description>
+<description>Controls: wxWidgets sample application</description>
<dependency>
<dependentAssembly>
<assemblyIdentity
--- cut here ---
-There are a few minor problems with theme support in wxWindows currently
+There are a few minor problems with theme support in wxWidgets currently
which will be fixed in the next releases:
- the buttons with non-default colours are owner-drawn and thus don't
-Installing wxWindows 2.5.1
+Installing wxWidgets 2.5.1
--------------------------
-This is wxWindows 2.5.1 for IBM OS/2 Warp3 and Warp4. This is an unstable
+This is wxWidgets 2.5.1 for IBM OS/2 Warp3 and Warp4. This is an unstable
development release and OS/2 is considered to be in beta.
IMPORTANT NOTE: If you experience problems installing, please
readme.txt, notes on the Web site) carefully before mailing
wx-users or the author. Preferably, try to fix the problem first and
then send a patch to the author. Please report bugs using the
-bug report form on the wxWindows web site.
+bug report form on the wxWidgets web site.
Unarchiving
-----------
At this time there is no comprehensive setup.exe type installation program.
-wxWindows for OS/2 requires you download various .zip files and unpack them
+wxWidgets for OS/2 requires you download various .zip files and unpack them
to your desired location on your system. Pick a location say,
-C:\wx\wxWindows-2.5.1, copy the .zip files to there and unzip them ensuring you
+C:\wx\wxWidgets-2.5.1, copy the .zip files to there and unzip them ensuring you
unzip the subdirectories as well. You will need:
-- All common, generic and OS2-specific wxWindows source;
+- All common, generic and OS2-specific wxWidgets source;
- samples;
- documentation in HTML Help format;
- makefiles for VisualAge V3.0 (possibly for EMX and Watcom C++);
- ZLIB library source;
All but the documentation is included in wxOS2-2.5.1.zip, documentation
-must be downloaded separately from the wxWindows Web site.
+must be downloaded separately from the wxWidgets Web site.
-Other add-on packages are available from the wxWindows Web site, such as:
+Other add-on packages are available from the wxWidgets Web site, such as:
- mmedia.zip. Audio, CD, video access for Windows and Linux.
- ogl3.zip. Object Graphics Library: build network diagrams, CASE tools etc.
After unzipping everything your directory tree should look something like
this:
-x:\wx\wxWindows-2.5.1\docs (your HTML reference manual)
-x:\wx\wxWindows-2.5.1\include\wx
-x:\wx\wxWindows-2.5.1\include\wx\generic
-x:\wx\wxWindows-2.5.1\include\wx\html
-x:\wx\wxWindows-2.5.1\include\wx\os2
-x:\wx\wxWindows-2.5.1\samples\.... (all the sample directories)
-x:\wx\wxWindows-2.5.1\src
-x:\wx\wxWindows-2.5.1\src\common
-x:\wx\wxWindows-2.5.1\src\generic
-x:\wx\wxWindows-2.5.1\src\html
-x:\wx\wxWindows-2.5.1\src\jpeg
-x:\wx\wxWindows-2.5.1\src\os2
-x:\wx\wxWindows-2.5.1\src\png
-x:\wx\wxWindows-2.5.1\src\tiff
-x:\wx\wxWindows-2.5.1\src\zlib
+x:\wx\wxWidgets-2.5.1\docs (your HTML reference manual)
+x:\wx\wxWidgets-2.5.1\include\wx
+x:\wx\wxWidgets-2.5.1\include\wx\generic
+x:\wx\wxWidgets-2.5.1\include\wx\html
+x:\wx\wxWidgets-2.5.1\include\wx\os2
+x:\wx\wxWidgets-2.5.1\samples\.... (all the sample directories)
+x:\wx\wxWidgets-2.5.1\src
+x:\wx\wxWidgets-2.5.1\src\common
+x:\wx\wxWidgets-2.5.1\src\generic
+x:\wx\wxWidgets-2.5.1\src\html
+x:\wx\wxWidgets-2.5.1\src\jpeg
+x:\wx\wxWidgets-2.5.1\src\os2
+x:\wx\wxWidgets-2.5.1\src\png
+x:\wx\wxWidgets-2.5.1\src\tiff
+x:\wx\wxWidgets-2.5.1\src\zlib
If you are using VisualAge, you will also need to ensure you have a
-\lib directory as well, x:\wx\wxWindows-2.5.1\lib
+\lib directory as well, x:\wx\wxWidgets-2.5.1\lib
and you will have to set a WXWIN environment variable in your
config.sys,
SET WXWIN=X:\WX\WXWINDOWS-2.5.1;
--------------------------
In addition to VisualAge V3.0 Fixpack 8 you will need the following inorder
-to successfully build and use wxWindows for OS/2:
+to successfully build and use wxWidgets for OS/2:
1. IBM OS/2 Toolkit Version 4.5 or later
2. IBM TCPIP V4.0 or later
both the wx23.def and the temp.def file. Copy the header of the wx23.def to
the clipboard and paste it into the top of the temp.def file. If you have
a valid SQL database client with its SDK on your system you can skip the next
-step. wxWindows included some ODBC and SQL modules. They expect the standard
+step. wxWidgets included some ODBC and SQL modules. They expect the standard
sql.h and such to available. If you do not have a database client with its
SDK (such as DB/2) then for the .dll build you need to delete the exports for
the following three modules from your temp.def file, db.cpp, dbgrid.cpp and
the WXUSINGDLL=1 macro. For example to build the minimal sample you would
go to \samples\minimal and execute nmake all -f makefile.va WXUSINGDLL=1.
-I strongly suggest when developing apps using wxWindows for OS/2 under old
+I strongly suggest when developing apps using wxWidgets for OS/2 under old
VisualAge 3.0, that you use the dynamically linked library. The library is
very large and even the most trivial statically linked .exe can be very
large and take a long time to link. The release builds are much smaller,
The first thing to do is to decide on a build directory. You can either
do in-tree builds or you can do the build in a directory separated from
the source directory. The later has the advantage, that it is much easier
-to compile and maintain several ports of wxWindows on OS/2 - if you are
+to compile and maintain several ports of wxWidgets on OS/2 - if you are
developping cross-platform applications you might want to compile (and
update) e.g. wxGTK or wxX11 as well.
In the following, let's assume you decided to build in
-\wx\wxWindows-2.5.1\build\pm. Now we need to set some environment
+\wx\wxWidgets-2.5.1\build\pm. Now we need to set some environment
variables, namely MAKESHELL (to a Unix like shell, let's assume ash)
and INSTALL (to point to the install script. If you omit this, configure
might find something like the system's tcpip\pcomos\install.exe which will
not do the thing you want), e.g.
SET MAKESHELL=ash
-SET INSTALL=/wx/wxWindows-2.5.1/install-sh -c
+SET INSTALL=/wx/wxWidgets-2.5.1/install-sh -c
Be warned that depending on the precise version of your make, the
variable that needs to be set might be MAKE_SHELL instead of MAKESHELL.
Now run the provided configure script by executing e.g.
`ash -c "../../configure \
- --prefix=directory_where_you_want_wxWindows_to_be_installed"'
+ --prefix=directory_where_you_want_wxWidgets_to_be_installed"'
from within the build directory (the relative path might be different
depending on the build directory you selected).
If you are already running some unix-like shell and not cmd, you may
prefer to change into the directory of a specific sample
(e.g. samples\minimal) and call make there to just build this one example.
Essentially, each sample that's not working indicates an area, where help
-in porting wxWindows to OS/2 would be appreciated.
+in porting wxWidgets to OS/2 would be appreciated.
-Finally, you can run `make install' which should install wxWindows to
+Finally, you can run `make install' which should install wxWidgets to
the desired place.
Note that we also install the wx-config script which wants to help you
compiling your own applications, e.g. `wx-config --cxxflags` will emit the
-flags that are needed for compiling source code which includes wxWindows
+flags that are needed for compiling source code which includes wxWidgets
headers, `wx-config --libs` will emit the flags needed for linking against
-wxWindows (wx-config is assuming you are calling it from a unix-like shell!).
+wxWidgets (wx-config is assuming you are calling it from a unix-like shell!).
For building a DLL, the only supported way currently is to first build the
static library and then use Andrew Zabolotny's dllar.cmd. However, this
essentially have to use the procedure described above, the only difference
being that you have to pass a switch to configure indicating which port
to build. If you do not do this in a separate build directory (e.g.
-\wxWindows-2.5.1\build\gtk), you'll have to do a `make clean' first.
+\wxWidgets-2.5.1\build\gtk), you'll have to do a `make clean' first.
The magical switches that have to be passed to configure for the various
ports are --with-gtk (wxGTK), --with-motif (wxMotif), --with-x11 (wxX11),
and --disable-gui (wxBase). Note that contrary to the native, PM based
Preamble
========
-The licensing of the wxWindows library is intended to protect the wxWindows
+The licensing of the wxWidgets library is intended to protect the wxWidgets
library, its developers, and its users, so that the considerable investment
it represents is not abused.
-Under the terms of the wxWindows Licence, you as a user are not
-obliged to distribute wxWindows source code with your products, if you
+Under the terms of the wxWidgets Licence, you as a user are not
+obliged to distribute wxWidgets source code with your products, if you
distribute these products in binary form. However, you are prevented from
restricting use of the library in source code form, or denying others the
-rights to use or distribute wxWindows library source code in the way
+rights to use or distribute wxWidgets library source code in the way
intended.
-The wxWindows Licence establishes the copyright for the code and related
+The wxWidgets Licence establishes the copyright for the code and related
material, and it gives you legal permission to copy, distribute and/or
modify the library. It also asserts that no warranty is given by the authors
for this or derived code.
-The core distribution of the wxWindows library contains files
+The core distribution of the wxWidgets library contains files
under two different licences:
- Most files are distributed under the GNU Library General Public
different licence), and distribute such binaries under your own
terms.
-- Most core wxWindows manuals are made available under the "wxWindows
+- Most core wxWidgets manuals are made available under the "wxWidgets
Free Documentation Licence", which allows you to distribute modified
versions of the manuals, such as versions documenting any modifications
made by you in your version of the library. However, you may not restrict
Other relevant files:
-- licence.txt: a statement that the wxWindows library is
+- licence.txt: a statement that the wxWidgets library is
covered by the GNU Library General Public Licence, with an
exception notice for binary distribution.
-- licendoc.txt: the wxWindows Documentation Licence.
+- licendoc.txt: the wxWidgets Documentation Licence.
- lgpl.txt: the text of the GNU Library General Public Licence.
To get wxWidgets, go to the Download page at:
- http://www.wxwindows.org
+ http://www.wxwidgets.org
This is a development snapshot, sometimes known as
an 'unstable' release. Improvements include:
If you're considering wxWidgets, do check out some of these links:
- http://www.wxwindows.org/feedback.htm ; Comments from users
- http://www.wxwindows.org/screensh.htm ; Screenshots
- http://www.wxwindows.org/users.htm ; A list of some of our
+ http://www.wxwidgets.org/feedback.htm ; Comments from users
+ http://www.wxwidgets.org/screensh.htm ; Screenshots
+ http://www.wxwidgets.org/users.htm ; A list of some of our
; users
Have fun!
[where is the announcement text? TODO]
-c) update www.wxwindows.org
+c) update www.wxwidgets.org
d) GNOME (very effective, stays on front page for days):
- http://www.gnome.org/applist
- - Search for wxWindows
+ - Search for wxWidgets
- Update the version number
- Ignore the error message
-wxWindows slogan ideas
+wxWidgets slogan ideas
CafePress products:
(perhaps highlighted in different colours)
-wxWindows: "Practically Perfect in Every Way"
+wxWidgets: "Practically Perfect in Every Way"
-----------
Build an app for Windows, Mac and Linux in a week?
No sweat.
-<wxWindows logo>
+<wxWidgets logo>
wxwindows.org
-----------
On hat:
-wxWindows
+wxWidgets
Brim-full of cool GUI tools
-----------
Suggested slogans from wx-users:
-wxWindows: The API for programmers who aren't sheep.
+wxWidgets: The API for programmers who aren't sheep.
(Robin Dunn)
Better printed on a shirt:
.. and templates.
-Hmm. I might buy a mug that had, say, a wxLogo and "wxWindows" (and
+Hmm. I might buy a mug that had, say, a wxLogo and "wxWidgets" (and
maybe the website URL underneath in smaller type) on one side and
"Specialization is for insects ... and templates" on the other.
============================
-wxWindows: Write it once and for all.
+wxWidgets: Write it once and for all.
Matt Gregory <msgregory@earthlink.net>
At front:
Need an API?
- <wxWindows>
+ <wxWidgets>
and get THE API
C++, Python, Basic, Lua ...
At back
<windows> OR <linux> OR <mac> ?
- <wxWindows> is
+ <wxWidgets> is
<windows> AND <linux> AND <mac>
where <xxxxx> is the respective logo
One API to rule them all, one API to hide them
One API to bridge them all and in the compiler bind them.
-wxWindows
+wxWidgets
How about "and in the linker bind them"? That's where the local libraries
-get bound to the wxWindows code anyway.
+get bound to the wxWidgets code anyway.
============================
-wxWindows 2.5.1
+wxWidgets 2.5.1
---------------
*** Please note that this is an UNSTABLE DEVELOPMENT SNAPSHOT.
*** may change in backwards incompatible way. If this doesn't frighten
*** you, do try this release and please let us know what you think!
-Welcome to wxWindows, a sophisticated cross-platform C++
+Welcome to wxWidgets, a sophisticated cross-platform C++
framework for writing advanced GUI applications using (where
possible) the native controls.
Platforms supported
-------------------
-wxWindows currently supports the following platforms:
+wxWidgets currently supports the following platforms:
- Windows 95/98/ME, Windows NT, Windows 2000, Windows XP
- Most Unix variants with GTK+
Most popular C++ compilers are supported; see the install.txt
file for each platform (available via docs/html/index.htm) for details.
-See also http://www.wxwindows.org/platform.htm.
+See also http://www.wxwidgets.org/platform.htm.
Files
-----
target system. Documentation is available mainly in zip format.
In the following, x.y.z represents the current version number.
-wxWindows for GTK+ distribution
+wxWidgets for GTK+ distribution
-------------------------------
wxGTK-x.y.z.tar.gz wxGTK source distribution. You will
wxGTK-devel-x.y.z-0.i386.rpm wxGTK Linux minimum development system as an RPM
wxGTK-gl-x.y.z-0.i386.rpm Add-on OpenGL binary as an RPM
-wxWindows for X11 and Motif distribution
+wxWidgets for X11 and Motif distribution
----------------------------------------
wxX11-x.y.z.tar.gz wxX11 and wxMotif source distribution, without
documentation.
-wxWindows for MS Windows distribution
+wxWidgets for MS Windows distribution
-------------------------------------
setup.exe, setup-*.bin Setup files in floppy-disk-sized chunks
- a Tex2RTF binary;
- Life! sample binary.
-wxWindows for MacOS distribution
+wxWidgets for MacOS distribution
--------------------------------
wxMac-x.y.z.zip Zip archive containing all
You might prefer this format if building on
MacOS X, since it preserves file permissions.
-wxWindows for OS/2 distribution
+wxWidgets for OS/2 distribution
-------------------------------
wxOS2-x.y.z.zip Zip archive containing all source files
Documentation files
-------------------
-wxWindows-x.y.z-WinHelp.zip WinHelp documentation
-wxWindows-x.y.z-PDF.zip Acrobat PDF documentation
-wxWindows-x.y.z-HTML.zip HTML documentation
-wxWindows-x.y.z-HTMLHelp.zip Windows HTML Help documentation
-wxWindows-x.y.z-HTB.zip wxHTML documentation (for
+wxWidgets-x.y.z-WinHelp.zip WinHelp documentation
+wxWidgets-x.y.z-PDF.zip Acrobat PDF documentation
+wxWidgets-x.y.z-HTML.zip HTML documentation
+wxWidgets-x.y.z-HTMLHelp.zip Windows HTML Help documentation
+wxWidgets-x.y.z-HTB.zip wxHTML documentation (for
use with the helpview utility)
Installation
------------
-wxWindows 2 needs to be compiled before you can test out
+wxWidgets 2 needs to be compiled before you can test out
the samples or write your own applications.
For installation information, please see the install.txt file
in the individual directories:
docs/lgpl.txt
Although this may seem complex, it is there to allow authors of
-proprietary/commercial applications to use wxWindows in
+proprietary/commercial applications to use wxWidgets in
addition to those writing GPL'ed applications. In summary,
the licence is LGPL plus a clause allowing unrestricted
distribution of application binaries. To answer a FAQ, you
don't have to distribute any source if you wish to write
-commercial applications using wxWindows.
+commercial applications using wxWidgets.
However, if you distribute wxGTK or wxMotif (with Lesstif) version
of your application, don't forget that it is linked against
linked against LGPL library. Basically you should link dynamically and
include source code of LGPL libraries with your product (unless it is
already present in user's system - like glibc usually is).
-If compiled with --enable-odbc (Unix only), wxWindows library will
+If compiled with --enable-odbc (Unix only), wxWidgets library will
contain iODBC library which is covered by LGPL.
If you use TIFF image handler, please see src/tiff/COPYRIGHT
See docs/html/index.htm for an HTML index of the major documents.
-See docs/changes.txt for a summary of changes to wxWindows 2.
+See docs/changes.txt for a summary of changes to wxWidgets 2.
See docs/tech for an archive of technical notes.
-The wxWindows bug database can be browsed at:
+The wxWidgets bug database can be browsed at:
http://sourceforge.net/bugs/?group_id=9863
Further information
-------------------
-The wxWindows Web site is located at:
+The wxWidgets Web site is located at:
- http://www.wxwindows.org
+ http://www.wxwidgets.org
-The main wxWindows ftp site is at:
+The main wxWidgets ftp site is at:
ftp://biolpc22.york.ac.uk/pub
-A wxWindows CD-ROM with the latest distribution plus an HTML
+A wxWidgets CD-ROM with the latest distribution plus an HTML
front-end and hundreds of MB of compilers, utilities and other
-material may be ordered from the CD-ROM page: see the wxWindows
+material may be ordered from the CD-ROM page: see the wxWidgets
web site.
Have fun!
-The wxWindows Team, February 2004
+The wxWidgets Team, February 2004
-GTK1.2.8 (for wxGTK)
To get everything compiled you'll need to have installed prior to compiling
-wxWindows:
+wxWidgets:
-Bison
get it from http://www.openvms.digital.com/freeware/
You' have to fix the following bug:
versions of VMS. If you get lib$get_current_invo_context undefined
while linking you'll have to add
"lib$get_current_invo_context"="LIB$GET_CURR_INVO_CONTEXT"
- in [.src.unix]descrip.mms to CXX_DEFINE. and recompile wxWindows.
+ in [.src.unix]descrip.mms to CXX_DEFINE. and recompile wxWidgets.
-Some versions of the CC compiler give warnings like
%CC-W-CXXKEYWORD, "bool" is a keyword in C++ .... when compiling
-I think in general wxGTK is better maintained, so that version is my
first choice.
- -Note that only a few people have used wxWindows on VMS so many problems are
+ -Note that only a few people have used wxWidgets on VMS so many problems are
to be expected.
- All wxWindows techincal notes at a glance
+ All wxWidgets techincal notes at a glance
=========================================
tn0001.txt How to add a new sample
-tn0002.txt wxWindows translator guide
-tn0003.txt Adding wxWindows class documentation
+tn0002.txt wxWidgets translator guide
+tn0003.txt Adding wxWidgets class documentation
tn0004.htm *** Not currently applicable Compiling a sample in the C++Builder IDE
-tn0005.txt Adding a wxWindows contribution
+tn0005.txt Adding a wxWidgets contribution
tn0006.txt *** REMOVED *** (obsoleted by tn0013.txt)
tn0007.txt *** Not currently applicable Using and modifying the BC++ IDE files
-tn0008.htm How to learn wxWindows programming
+tn0008.htm How to learn wxWidgets programming
tn0009.htm Creating and converting icons
-tn0010.htm Compiling wxWindows applications in the VC++ IDE
+tn0010.htm Compiling wxWidgets applications in the VC++ IDE
tn0011.txt All about version numbers
-tn0012.txt wxWindows platform, toolkit and library names
+tn0012.txt wxWidgets platform, toolkit and library names
tn0013.txt How to make a wxGTK distribution
tn0014.txt XRC resources format specification
-tn0015.txt How to add new bitmaps to wxWindows UI elements
-tn0016.txt How to add new files and libraries to wxWindows build system (Bakefile)
-tn0017.txt How to write unit tests for wxWindows classes
-tn0018.txt How to add a new font encoding/charset to wxWindows?
+tn0015.txt How to add new bitmaps to wxWidgets UI elements
+tn0016.txt How to add new files and libraries to wxWidgets build system (Bakefile)
+tn0017.txt How to write unit tests for wxWidgets classes
+tn0018.txt How to add a new font encoding/charset to wxWidgets?
Version: $Id$
- How to add a new sample to wxWindows.
+ How to add a new sample to wxWidgets.
=====================================
To add a new sample "foo" under directory "samples/foo" you need to do
by running "autoconf" on a Unix system in the corresponding directory.
5. Add a short description of what the sample does and how does it work
- to the "samples overview" section in the wxWindows manual. That section
+ to the "samples overview" section in the wxWidgets manual. That section
lives in docs/latex/wx/tsamples.tex; look at the descriptions for other
samples, if you are not familiar with LaTeX.
- wxWindows translator guide
+ wxWidgets translator guide
==========================
-This note is addressed to wxWindows translators.
+This note is addressed to wxWidgets translators.
First of all, here is what you will need:
mirror (RPMs and DEBs are also available from the usual places)
b) for Windows you can download the precompiled binaries from
- www.wxwindows.org or install PoEdit (poedit.sourceforge.org) and
+ www.wxwidgets.org or install PoEdit (poedit.sourceforge.org) and
add <installdir>/poEdit/bin to your path (so it can find xgettext).
2. A way to run a program recursively on an entire directory from the command
program into a wxstd.po file which is a "text message catalog"
2. this new wxstd.po file (recreated each time some new text messages are added
- to wxWindows) is merged with existing translations in another .po file (for
+ to wxWidgets) is merged with existing translations in another .po file (for
example, de.po) and replaces this file (this is done using the program
msgmerge)
Version: $Id$
$Log$
+Revision 1.4 2004/05/04 08:26:58 JS
+Name change replacements
+
Revision 1.3 2003/11/18 16:37:11 DS
Updated translation technote to mention Makefile usage under Windows.
- Adding wxWindows class documentation
+ Adding wxWidgets class documentation
====================================
This note is aimed at people wishing to add documentation for a
-class to either the main wxWindows manual, or to their own
+class to either the main wxWidgets manual, or to their own
manual.
-wxWindows uses Tex2RTF to process Latex-like input files (.tex)
+wxWidgets uses Tex2RTF to process Latex-like input files (.tex)
and output in HTML, WinHelp RTF and Word RTF. Tex2RTF is provided
-in the wxWindows distribution and in the CVS archive, under
+in the wxWidgets distribution and in the CVS archive, under
utils/tex2rtf. Please start by perusing the Tex2RTF manual.
-See http://www.wxwindows.org/tex2rtf/index.htm for a browseable
+See http://www.wxwidgets.org/tex2rtf/index.htm for a browseable
manual and binaries for specific platforms.
If adding to the existing manual in docs/latex/wx, you need to
to category.tex.
If compiling a separate manual, copy an existing set of files from the
-wxWindows manual or a contribution. Contribution documentation
+wxWidgets manual or a contribution. Contribution documentation
normally goes in the contrib/docs hierarchy, with the source
going in a latex/mycontrib subdirectory.
tex2rtf manual.tex manual.rtf -rtf -twice -interactive
NOTE: You must be using the latest tex2rtf which was released with
-v2.2.0 of wxWindows to use the -interactive switch
+v2.2.0 of wxWidgets to use the -interactive switch
If you wish to generate documentation for wxHTML Help Viewer
(or Windows HTML Help), set htmlWorkshopFiles to true in your
tex2rtf.ini file. See also the wxHTML Notes section in the
-wxWindows manual. To further speed-up HTML help books loading
+wxWidgets manual. To further speed-up HTML help books loading
in your application, you may use hhp2cached (utils/hhp2cached).
src/msw/makefile.vc contains targets for generating various
</head>
<body>
<h2>
-Compiling wxWindows samples with the Borland CBuilder</h2>
-Please use wxWindows 2.4.x this will not work with the new makefiles in
-wxWindows 2.5.0<br>
+Compiling wxWidgets samples with the Borland CBuilder</h2>
+Please use wxWidgets 2.4.x this will not work with the new makefiles in
+wxWidgets 2.5.0<br>
<br>
<br>
</body>
- Adding a wxWindows contribution
+ Adding a wxWidgets contribution
===============================
Here are some different kinds of contribution:
1. Bug fixes. You can send these to the wx-devel list.
2. New classes. New classes normally go in the contrib hierarchy:
please see below for more details. They may be promoted to
- the main wxWindows hierarchy if they are deemed to be 'core'.
+ the main wxWidgets hierarchy if they are deemed to be 'core'.
3. A utility application, such as a new dialog editor or
file format conversion utility. If adding to the CVS
archive, you may put it under the utils hierarchy,
preferably with further src and docs directories.
-You may or may not wish to add your code to the main wxWindows CVS
+You may or may not wish to add your code to the main wxWidgets CVS
archive. Whether your code is appropriate for this archive
should first be ascertained by discussing it on wx-devel@wxwindows.org.
organise your files in the following hierarchy, so that
when a user unarchives your contribution, it
slots neatly into the existing source hierarchy.
-It also simplifies compilation for users, since wxWindows
+It also simplifies compilation for users, since wxWidgets
makefiles and project files are set up to search in
contrib/include/wx and contrib/lib. For example, to
include yourclass.h, the following directive is used:
(see Technote #16 for details).
Your archive can be in .tgz or .zip format. For inclusion on
-the wxWindows ftp site and CD-ROM, please send your submission to
+the wxWidgets ftp site and CD-ROM, please send your submission to
Julian Smart <julian@wxwindows.org> as a binary attachment.
An entry will be added to the Contributions web page.
======================================
-Please use wxWindows 2.4.x - this is not currently supported in wxWindows 2.5.1
+Please use wxWidgets 2.4.x - this is not currently supported in wxWidgets 2.5.1
<HTML>
<HEAD>
-<TITLE>How to learn wxWindows programming</TITLE>
+<TITLE>How to learn wxWidgets programming</TITLE>
</HEAD>
<BODY BGCOLOR=#FFFFFF TEXT=#000000 LINK=#FF0000 VLINK=#000000>
<tr>
<td bgcolor="#660000" align=left colspan=2>
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
-How to learn wxWindows programming
+How to learn wxWidgets programming
</font>
</td>
</tr>
<P>
The following is a response by Edward Ream to a common question,
-"What's the best way to learn wxWindows [and C++]?".<P>
+"What's the best way to learn wxWidgets [and C++]?".<P>
Date: Sun, 04 Jun 2000 14:37:06 -0500<BR>
From: "Edward K. Ream" <edream@tds.net> <BR>
> tran). I'd like to refresh my experience and start in C++. Will<BR>
> wx-windows be a very high step to take?<P>
-I'm new to wxWindows myself, but I'd like to answer this question
+I'm new to wxWidgets myself, but I'd like to answer this question
anyway. In the past two years I've learned two similar frameworks
(Apple's Yellow Box, aka NextStep/OpenStep and Borland's C++
Builder/Delphi) and last year I became a C++ enthusiast after 20 years
The major Aha for me was that the complexity of C++ doesn't matter in
practice. What _does_ matter is that C++ allows you to do simple things
-simply, more simply than C. With a system like wxWindows you will be
+simply, more simply than C. With a system like wxWidgets you will be
creating objects and then using those objects to call methods. So don't
be afraid of C++: you'll only be using the easy tip of the
iceberg.<P>
<B>About applications frameworks.</B><P>
-Application frameworks such as wxWindows are organized around a set of
+Application frameworks such as wxWidgets are organized around a set of
cooperating classes. Take a look at the main application class, wxApp,
some frame and panel classes, graphics classes, menu classes, control
classes, etc. In general, to do anything in a framework involves
Learn as much as you can about the String class; after using a good
String class you'll never want to use C's string functions again.
-wxWindows contains other nifty utility classes as well.<P>
+wxWidgets contains other nifty utility classes as well.<P>
The application class, wxApp, contains the main event loop. Learn about
event handling and event tables (reading sample code will help). Almost
benefit.<P>
I hope this helps. Perhaps we can work together in learning about
-wxWindows. Please feel free to ask me any questions you might have. If
-I've made any blunders in this posting I hope the wxWindows experts will
+wxWidgets. Please feel free to ask me any questions you might have. If
+I've made any blunders in this posting I hope the wxWidgets experts will
correct me gently.<P>
Edward<BR>
To convert from XPM to BMP (which can be loaded or pasted into an icon editor to save as an ICO file),
you can use Vadim Zeitlin's <a href="ftp://biolpc22.york.ac.uk/pub/support/xpm2bmp.exe">xpm2bmp.exe</a> utility.
To convert from BMP to XPM, you can use <a href="ftp://biolpc22.york.ac.uk/pub/support/bmp2xpm.exe">bmp2xpm.exe</a>
-which is actually the old wxWindows 1.68 utility, xpmshow. You will have to edit the resulting
+which is actually the old wxWidgets 1.68 utility, xpmshow. You will have to edit the resulting
file since the full path is used as the variable name, plus you may wish to specify a transparent colour e.g.:<P>
<pre>
<HTML>
<HEAD>
-<TITLE>Compiling wxWindows applications in the VC++ IDE</TITLE>
+<TITLE>Compiling wxWidgets applications in the VC++ IDE</TITLE>
</HEAD>
<tr>
<td bgcolor="#C4ECF9">
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#000000">
-Compiling wxWindows applications in the VC++ IDE
+Compiling wxWidgets applications in the VC++ IDE
</font>
</td>
</tr>
<P>
<CENTER>
-<a href="#wxwin2">Settings for wxWindows 2.2</a> / <a href="#wxwin1">Settings for wxWindows 1.68</a>
+<a href="#wxwin2">Settings for wxWidgets 2.2</a> / <a href="#wxwin1">Settings for wxWidgets 1.68</a>
</CENTER>
<P>
-To compile wxWindows samples and applications using the VC++ 5.0 or 6.0 IDE (having compiled wxWindows
+To compile wxWidgets samples and applications using the VC++ 5.0 or 6.0 IDE (having compiled wxWidgets
using the makefile or project file provided), the following
steps and settings should be used.<P>
<ol>
<li>Create a new WIN32 Application project.
<li>Add the .cpp and .rc files for your project.
-<li>Apply the settings listed below to the project, replacing c:\wx2 with your wxWindows
+<li>Apply the settings listed below to the project, replacing c:\wx2 with your wxWidgets
installation path.
</ol>
<P>
-<H2><a name="wxwin2">Settings for wxWindows 2.2</a></H2>
+<H2><a name="wxwin2">Settings for wxWidgets 2.2</a></H2>
-These settings apply to wxWindows 2.1.14 and above but most of them are not
-necessary any longer for wxWindows 2.3+.<P>
+These settings apply to wxWidgets 2.1.14 and above but most of them are not
+necessary any longer for wxWidgets 2.3+.<P>
<DL>
<DT><B>General</B><DD>
<PRE>
kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib
ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib comctl32.lib rpcrt4.lib wsock32.lib
-winmm.lib wxd.lib xpmd.lib pngd.lib zlibd.lib jpegd.lib tiffd.lib
+winmm.lib wxmsw25d.lib wxbase25d.lib wxpngd.lib wxzlibd.lib wxjpegd.lib wxtiffd.lib
</PRE>
for the Debug configuration and
<PRE>
kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib
ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib comctl32.lib rpcrt4.lib wsock32.lib
-winmm.lib wx.lib xpm.lib png.lib zlib.lib jpeg.lib tiff.lib
+winmm.lib wxmsw25.lib wxbase25.lib wxpng.lib wxzlib.lib wxjpeg.lib wxtiff.lib
</PRE>
for the Release configuration.<P>
<HR>
-<H2><a name="wxwin1">Settings for wxWindows 1.68</a></H2>
+<H2><a name="wxwin1">Settings for wxWidgets 1.68</a></H2>
Note: these have not yet been checked.<P>
<DT><B>C/C++: Precompiled Headers</B><DD>
The <B>Not using precompiled headers</B> or <B>Automatic use of precompiled headers</B>
-button should be selected (I can't find a way of using the wxWindows PCH file).<P>
+button should be selected (I can't find a way of using the wxWidgets PCH file).<P>
<DT><B>C/C++: Code Generation</B><DD>
The <B>Use run-time library</B> control should be set to <B>Multithreaded DLL</B>. This
-sets the compiler switch to /MD to match the wxWindows makefile.<P>
+sets the compiler switch to /MD to match the wxWidgets makefile.<P>
<DT><B>Link: Input</B><DD>
- All about wxWindows Version Numbers
+ All about wxWidgets Version Numbers
===================================
1. Where to update the version numbers:
- There are several places in the wxWindows source tree that
+ There are several places in the wxWidgets source tree that
define the version number for the library. When updating the
version number all of these places need edited:
Version: $Id$
$Log$
+Revision 1.3 2004/05/04 08:26:58 JS
+Name change replacements
+
Revision 1.2 2003/11/18 16:38:48 DS
Horizontally aligned header (Like other technotes).
- wxWindows naming conventions
+ wxWidgets naming conventions
============================
Being a cross platform development library, it is naturally desirable
-(at least to me ;) for wxWindows to be exploited in a fully cross
+(at least to me ;) for wxWidgets to be exploited in a fully cross
platform development environment -- a single invocation of make should
be sufficient to build target executables for a variety of host platforms
when desired.
Since this is now in fact possible for at least the most commonly used
-platforms, wxWindows has been structured to allow multiple, simultaneous
+platforms, wxWidgets has been structured to allow multiple, simultaneous
installations of the library. Common files are shared, platform and port
specific files and libraries are arranged so as to be unambiguous when
installed together.
least at its time of writing) describes the system we have adopted.
It is not fine grained enough to include every possible build configuration
-for wxWindows, but is encompassing enough to maintain a relatively complete
+for wxWidgets, but is encompassing enough to maintain a relatively complete
set of cross platform build tools on a single machine and to provide an
obvious slot for new ports to slip into.
$version is a string encoding the full version (major, minor, release)
for MSW, or just the major and minor number for UNIX.
-eg. for wxWindows 2.3.2, $version = 232 for MSW or 2.3 for UNIX.
+eg. for wxWidgets 2.3.2, $version = 232 for MSW or 2.3 for UNIX.
The rationale for this is that under UNIX-like systems it is desirable
that differently 'minor numbered' releases can be installed together,
files so that it works for the next release!
You also need the samples, demos and contrib directories, so change to
- wxWindows directory created by the first cvs command and do "cvs up -d"
+ wxWidgets directory created by the first cvs command and do "cvs up -d"
for each of them.
-b) Create a build directory under wxWindows, e.g. I use "gtk-release",
+b) Create a build directory under wxWidgets, e.g. I use "gtk-release",
"cd" to it and run configure: the options don't really matter, you can use
something like
[where is the announcement text? TODO]
-c) update www.wxwindows.org
+c) update www.wxwidgets.org
d) GNOME (very effective, stays on front page for days):
- http://www.gnome.org/applist
- - Search for wxWindows
+ - Search for wxWidgets
- Update the version number
- Ignore the error message
<resource> nor either of <object>s is:
<?xml version="1.0" encoding="utf-8">
- <resource xmlns="http://www.wxwindows.org/wxxrc" version="2.3.0.1">
+ <resource xmlns="http://www.wxwidgets.org/wxxrc" version="2.3.0.1">
<object class="wxPanel">
<style>wxSUNKEN_BORDER</style> <!-- attr -->
<object class="wxStaticText">
=========================
XRC resource file is a well-formed XML 1.0 document. All elements of XRC file
-are from the http://www.wxwindows.org/wxxrc namespace.
+are from the http://www.wxwidgets.org/wxxrc namespace.
The root node of XRC document must be <resource>. The <resource> node has
optional "version" property. Default version (in absence of the version
periods. Version of XRC format changes only if there was an incompatible
change introduced (i.e. either the library cannot understand old resource
files or older versions of the library wouldn't understand the new format).
-The first three integers are major, minor and release number of the wxWindows
+The first three integers are major, minor and release number of the wxWidgets
release when the change was introduced, the last one is revision number and
-is 0 for the first incompatible change in given wxWindows release, 1 for
+is 0 for the first incompatible change in given wxWidgets release, 1 for
the second etc.
Differences between versions are described within this document in paragraphs
The <resource> node contains namespace declaration, too:
- <resource xmlns="http://www.wxwindows.org/wxxrc" version="2.3.0.1">
+ <resource xmlns="http://www.wxwidgets.org/wxxrc" version="2.3.0.1">
The <resource> node is only allowed to have <object> and <object_ref>
subnodes, all of which must have the "name" property.
The <object> node represents a single object (GUI element) and it usually maps
-directly to a wxWindows class instance. It three properties: "name", "class"
-and "subclass". "class" must always be present, it tells XRC what wxWindows
+directly to a wxWidgets class instance. It three properties: "name", "class"
+and "subclass". "class" must always be present, it tells XRC what wxWidgets
object should be created in this place. The other two are optional. "name" is
ID used to identify the object. It is the value passed to the XRCID() macro and
is also used to construct wxWindow's id and name attributes and must be unique
optional name of class whose constructor will be called instead of the
constructor for "class". Subclass must be available in the program that loads
the resource, must be derived from "class" and must be registered within
-wxWindows' RTTI system.
+wxWidgets' RTTI system.
Example:
------
Any text. Some characters have special interpretation and are translated
by XRC parser according to this table:
- "_" -> "&" ('&' is used to underline e.g. menu items in wxWindows)
+ "_" -> "&" ('&' is used to underline e.g. menu items in wxWidgets)
"__" -> "_"
"\n" -> line break (C character '\n')
"\r" -> carriage return (C character '\r')
written in same way as in C++ code (e.g. "wxSUNKEN_BORDER",
"wxHW_SCROLLBAR_NEVER") and are delimined with any combination of whitespaces
and '|'. Possible flags are class-dependent and are not described in this
-technote. Please refer to wxWindows manual for all styles that given class can
-accept; if XRC does not accept a flag listed in wxWindows documentation, it is
+technote. Please refer to wxWidgets manual for all styles that given class can
+accept; if XRC does not accept a flag listed in wxWidgets documentation, it is
a bug.
separation Integer -1
wxToolBar node may have children <object> and <object_ref> nodes. Their class
-may be either "tool", "separator" or any wxWindows class derived from
+may be either "tool", "separator" or any wxWidgets class derived from
wxControl. "tool" and "separator" are special pseudo-classes that may only
appear within wxToolBar node. Their attributes are as follows:
- How to add new bitmaps to wxWindows UI elements
+ How to add new bitmaps to wxWidgets UI elements
===============================================
0. Introduction
resource file (include/wx/msw/wx.rc) or by including XPM files in the code.
wxArtProvider should be used instead, to allow users to customize the look of
-their wxWindows app. This technote is a detailed description of steps needed
+their wxWidgets app. This technote is a detailed description of steps needed
when adding new bitmap/icon.
1. Adding new resource
-------------------
It is highly desirable to let the users know what stock bitmaps are available
-in wxWindows. The "artprov" sample serves this purpose: it contains a browser
+in wxWidgets. The "artprov" sample serves this purpose: it contains a browser
dialog that displays all available art resources.
It has to be updated to accomodate for new bitmaps. Fortunately, this is
- How to add new files and libraries to wxWindows build system
+ How to add new files and libraries to wxWidgets build system
============================================================
1. Regenerating makefiles
-------------------------
-wxWindows now uses Bakefile (http://bakefile.sourceforge.net) to generate
+wxWidgets now uses Bakefile (http://bakefile.sourceforge.net) to generate
native makefiles. You must have bakefile installed if you want to regenerate
the makefiles. Bakefile currently runs on Unix and Windows systems. You will
need Python >= 2.2 installed on Unix and either use Bakefile installer or have
Note that it generates makefiles for samples and contrib libraries, too.
-IMPORTANT NOTE: Don't forget to run autoconf in wxWindows root directory
+IMPORTANT NOTE: Don't forget to run autoconf in wxWidgets root directory
(after running Bakefile) if you changed any conditional
variable or target condition in .bkl files! You will know that
this happened if $(wx)/autoconf_inc.m4 content changed.
- How to write unit tests for wxWindows
+ How to write unit tests for wxWidgets
=====================================
- Unit tests for wxWindows are written using small cppunit framework. To compile
+ Unit tests for wxWidgets are written using small cppunit framework. To compile
(but not to run) them you need to have it installed. Hence the first part of
this note explains how to do it while the second one explains how to write the
test.
- How to add a new font encoding to wxWindows
+ How to add a new font encoding to wxWidgets
===========================================
I. Introduction
---------------
- wxWindows has built in support for a certain number of font encodings (which
+ wxWidgets has built in support for a certain number of font encodings (which
is synonymous with code sets and character sets for us here even though it is
not exactly the same thing), look at include/wx/fontenc.h for the full list.
This list is far from being exhaustive though and if you have enough knowledge
-about an encoding to add support for it to wxWindows, this tech note is for
+about an encoding to add support for it to wxWidgets, this tech note is for
you!
A word of warning though: this is written out of my head and is surely
II. The receipt
---------------
-Suppose you want to add support for Klingon to wxWindows. This is what you'd
+Suppose you want to add support for Klingon to wxWidgets. This is what you'd
have to do:
1. include/wx/fontenc.h: add a new wxFONTENCODING_KLINGON enum element, if
2. "Remove" wxFont::GetInternalFont from wxGTK w/ GTK2
-CVS: [RR] wxWindows/src/gtk dcclient.cpp,1.162,1.163 font.cpp,1.69,1.70 window.cpp,1.411,1.412
-CVS: [RR] wxWindows/src/gtk choice.cpp,1.55,1.56 combobox.cpp,1.87,1.88
-CVS: [RR] wxWindows/src/gtk minifram.cpp,1.29,1.30
+CVS: [RR] wxWidgets/src/gtk dcclient.cpp,1.162,1.163 font.cpp,1.69,1.70 window.cpp,1.411,1.412
+CVS: [RR] wxWidgets/src/gtk choice.cpp,1.55,1.56 combobox.cpp,1.87,1.88
+CVS: [RR] wxWidgets/src/gtk minifram.cpp,1.29,1.30
(not sure about minifram.cpp: must be checked for binary compatibility - VS)
When applying, be careful to not pick later revision of font.cpp -- 2.5 doesn't
3. Add Windows XP manifests to wx.rc
-RCS file: /pack/cvsroots/wxwindows/wxWindows/include/wx/msw/wx.manifest,v
+RCS file: /pack/cvsroots/wxwindows/wxWidgets/include/wx/msw/wx.manifest,v
done
Checking in wx.manifest;
-/pack/cvsroots/wxwindows/wxWindows/include/wx/msw/wx.manifest,v <-- wx.manifest
+/pack/cvsroots/wxwindows/wxWidgets/include/wx/msw/wx.manifest,v <-- wx.manifest
initial revision: 1.1
done
Checking in wx.rc;
-/pack/cvsroots/wxwindows/wxWindows/include/wx/msw/wx.rc,v <-- wx.rc
+/pack/cvsroots/wxwindows/wxWidgets/include/wx/msw/wx.rc,v <-- wx.rc
new revision: 1.29; previous revision: 1.28
done
http://sf.net/tracker/index.php?func=detail&aid=718913&group_id=9863&atid=309863
Checking in include/wx/containr.h;
-/pack/cvsroots/wxwindows/wxWindows/include/wx/containr.h,v <-- containr.h
+/pack/cvsroots/wxwindows/wxWidgets/include/wx/containr.h,v <-- containr.h
new revision: 1.10; previous revision: 1.9
Checking in src/common/containr.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/common/containr.cpp,v <-- containr.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/common/containr.cpp,v <-- containr.cpp
new revision: 1.17; previous revision: 1.16
6. fixes for user dash wxPens handling
http://sf.net/tracker/index.php?func=detail&aid=717736&group_id=9863&atid=309863
Checking in include/wx/msw/pen.h;
-/pack/cvsroots/wxwindows/wxWindows/include/wx/msw/pen.h,v <-- pen.h
+/pack/cvsroots/wxwindows/wxWidgets/include/wx/msw/pen.h,v <-- pen.h
new revision: 1.16; previous revision: 1.15
Checking in src/msw/pen.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/msw/pen.cpp,v <-- pen.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/msw/pen.cpp,v <-- pen.cpp
new revision: 1.20; previous revision: 1.19
Checking in src/gtk/pen.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/gtk/pen.cpp,v <-- pen.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/gtk/pen.cpp,v <-- pen.cpp
new revision: 1.23; previous revision: 1.22
Checking in samples/drawing/drawing.cpp;
-/pack/cvsroots/wxwindows/wxWindows/samples/drawing/drawing.cpp,v <-- drawing.cpp
+/pack/cvsroots/wxwindows/wxWidgets/samples/drawing/drawing.cpp,v <-- drawing.cpp
new revision: 1.67; previous revision: 1.66
Checking in docs/changes.txt;
-/pack/cvsroots/wxwindows/wxWindows/docs/changes.txt,v <-- changes.txt
+/pack/cvsroots/wxwindows/wxWidgets/docs/changes.txt,v <-- changes.txt
new revision: 1.266; previous revision: 1.265
8. UnixWare compilation fixes:
Don't forget to rerun autoconf to regenerate configure!
Checking in configure.in;
-/pack/cvsroots/wxwindows/wxWindows/configure.in,v <-- configure.in
+/pack/cvsroots/wxwindows/wxWidgets/configure.in,v <-- configure.in
new revision: 1.664; previous revision: 1.663
Checking in setup.h.in;
-/pack/cvsroots/wxwindows/wxWindows/setup.h.in,v <-- setup.h.in
+/pack/cvsroots/wxwindows/wxWidgets/setup.h.in,v <-- setup.h.in
new revision: 1.111; previous revision: 1.110
Checking in src/unix/gsocket.c;
-/pack/cvsroots/wxwindows/wxWindows/src/unix/gsocket.c,v <-- gsocket.c
+/pack/cvsroots/wxwindows/wxWidgets/src/unix/gsocket.c,v <-- gsocket.c
new revision: 1.72; previous revision: 1.71
9. wxSemaphore methods returned incorrect values:
Checking in src/msw/thread.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/msw/thread.cpp,v <-- thread.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/msw/thread.cpp,v <-- thread.cpp
new revision: 1.62; previous revision: 1.61
Checking in src/unix/threadpsx.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/unix/threadpsx.cpp,v <-- threadpsx.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/unix/threadpsx.cpp,v <-- threadpsx.cpp
new revision: 1.62; previous revision: 1.61
10. Unix/OpenGL build fix:
Don't forget to rerun autoconf to regenerate configure!
Checking in configure.in;
-/pack/cvsroots/wxwindows/wxWindows/configure.in,v <-- configure.in
+/pack/cvsroots/wxwindows/wxWidgets/configure.in,v <-- configure.in
new revision: 1.666; previous revision: 1.665
11. Ukrainian translation (locale/uk.po)
http://sf.net/tracker/index.php?func=detail&aid=720542&group_id=9863&atid=309863
Checking in src/msw/fdrepdlg.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/msw/fdrepdlg.cpp,v <-- fdrepdlg.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/msw/fdrepdlg.cpp,v <-- fdrepdlg.cpp
new revision: 1.10; previous revision: 1.9
http://sf.net/tracker/index.php?func=detail&aid=728768&group_id=9863&atid=309863
Checking in include/wx/gtk/dcmemory.h;
-/pack/cvsroots/wxwindows/wxWindows/include/wx/gtk/dcmemory.h,v <-- dcmemory.h
+/pack/cvsroots/wxwindows/wxWidgets/include/wx/gtk/dcmemory.h,v <-- dcmemory.h
new revision: 1.13; previous revision: 1.12
done
Checking in src/gtk/dcmemory.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/gtk/dcmemory.cpp,v <-- dcmemory.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/gtk/dcmemory.cpp,v <-- dcmemory.cpp
new revision: 1.21; previous revision: 1.20
done
http://sf.net/tracker/index.php?func=detail&aid=626048&group_id=9863&atid=309863
Checking in src/gtk/menu.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/gtk/menu.cpp,v <-- menu.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/gtk/menu.cpp,v <-- menu.cpp
new revision: 1.136; previous revision: 1.135
http://sf.net/tracker/index.php?func=detail&aid=736208&group_id=9863&atid=109863
Checking in include/wx/textbuf.h;
-/pack/cvsroots/wxwindows/wxWindows/include/wx/textbuf.h,v <-- textbuf.h
+/pack/cvsroots/wxwindows/wxWidgets/include/wx/textbuf.h,v <-- textbuf.h
new revision: 1.8; previous revision: 1.7
http://sf.net/tracker/?func=detail&aid=215436&group_id=9863&atid=109863
Checking in src/common/containr.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/common/containr.cpp,v <-- containr.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/common/containr.cpp,v <-- containr.cpp
new revision: 1.18; previous revision: 1.17
21. Fix wxGTK w/ GTK+2 to respect wxDC::SetBackgroundMode and SetTextBackground
Checking in dcclient.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/gtk/dcclient.cpp,v <-- dcclient.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/gtk/dcclient.cpp,v <-- dcclient.cpp
new revision: 1.170; previous revision: 1.169
done
22. patch [ 619705 ] Fixes wxApp::GetComCtl32Version
-Checking in wxWindows/src/msw/app.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/msw/app.cpp,v <-- app.cpp
+Checking in wxWidgets/src/msw/app.cpp;
+/pack/cvsroots/wxwindows/wxWidgets/src/msw/app.cpp,v <-- app.cpp
new revision: 1.186; previous revision: 1.185
done
See: Bug [ 744199 ] wxBringWindowToTop, child window z-order
Checking in include/wx/msw/dialog.h;
-/pack/cvsroots/wxwindows/wxWindows/include/wx/msw/dialog.h,v <-- dialog.h
+/pack/cvsroots/wxwindows/wxWidgets/include/wx/msw/dialog.h,v <-- dialog.h
new revision: 1.34; previous revision: 1.33
done
Checking in src/msw/dialog.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/msw/dialog.cpp,v <-- dialog.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/msw/dialog.cpp,v <-- dialog.cpp
new revision: 1.84; previous revision: 1.83
done
Checking in src/msw/window.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/msw/window.cpp,v <-- window.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/msw/window.cpp,v <-- window.cpp
new revision: 1.381; previous revision: 1.380
done
25. wxGenericListCtrl::Refresh() (didn't work at all before)
Checking in include//wx/generic/listctrl.h;
-/pack/cvsroots/wxwindows/wxWindows/include/wx/generic/listctrl.h,v <-- listctrl.h
+/pack/cvsroots/wxwindows/wxWidgets/include/wx/generic/listctrl.h,v <-- listctrl.h
new revision: 1.77; previous revision: 1.76
Checking in src/generic/listctrl.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/generic/listctrl.cpp,v <-- listctrl.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/generic/listctrl.cpp,v <-- listctrl.cpp
new revision: 1.284; previous revision: 1.283
-cvs diff: [13:19:09] waiting for cvs's lock in /pack/cvsroots/wxwindows/wxWindows/include/wx/generic
+cvs diff: [13:19:09] waiting for cvs's lock in /pack/cvsroots/wxwindows/wxWidgets/include/wx/generic
Checking in docs/changes.txt;
-/pack/cvsroots/wxwindows/wxWindows/docs/changes.txt,v <-- changes.txt
+/pack/cvsroots/wxwindows/wxWidgets/docs/changes.txt,v <-- changes.txt
new revision: 1.299; previous revision: 1.298
evenly among all of them.
Checking in sizer.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/common/sizer.cpp,v <-- sizer.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/common/sizer.cpp,v <-- sizer.cpp
new revision: 1.71; previous revision: 1.70
28. patch [ 771772 ] Crashes when setting icon tooltip longer than 63 characters
Checking in window.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/msw/window.cpp,v <-- window.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/msw/window.cpp,v <-- window.cpp
new revision: 1.431; previous revision: 1.430
29. Fix infinite loop in IsDialoMessage when a panel is reparented after
creation (as happens with XRC)
Checking in src/msw/window.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/msw/window.cpp,v <-- window.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/msw/window.cpp,v <-- window.cpp
new revision: 1.432; previous revision: 1.431
30. Fix enumerating groups/entries in wxRegConfig under '/':
Checking in src/msw/regconf.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/msw/regconf.cpp,v <-- regconf.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/msw/regconf.cpp,v <-- regconf.cpp
new revision: 1.48; previous revision: 1.47
31. Cleanup of ZIP charset conversion in Unicode build
Checking in fs_zip.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/common/fs_zip.cpp,v <-- fs_zip.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/common/fs_zip.cpp,v <-- fs_zip.cpp
new revision: 1.27; previous revision: 1.26
done
Checking in zipstrm.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/common/zipstrm.cpp,v <-- zipstrm.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/common/zipstrm.cpp,v <-- zipstrm.cpp
new revision: 1.10; previous revision: 1.9
done
32. Apply patch [ 866387 ] wxGenericDirCtrl does not accept multiple wildcards
Checking in src/generic/dirctrlg.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/generic/dirctrlg.cpp,v <-- dirctrlg.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/generic/dirctrlg.cpp,v <-- dirctrlg.cpp
new revision: 1.81; previous revision: 1.80
33. Apply patch [ 873021 ] Bug fix for MSW wxComboBox
wxEVT_COMMAND_COMBOBOX_SELECTED changed the selection.
Checking in src/msw/combobox.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/msw/combobox.cpp,v <-- combobox.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/msw/combobox.cpp,v <-- combobox.cpp
new revision: 1.72; previous revision: 1.71
done
34. Apply patch [ 851052 ] [msw] Clipboard: Allow automatic format conversionsChecking in clipbrd.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/msw/clipbrd.cpp,v <-- clipbrd.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/msw/clipbrd.cpp,v <-- clipbrd.cpp
new revision: 1.54; previous revision: 1.53
done
35. [ 882201 ] wxXPMDecoder doesn't always patch magenta
Checking in xpmdecod.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/common/xpmdecod.cpp,v <-- xpmdecod.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/common/xpmdecod.cpp,v <-- xpmdecod.cpp
new revision: 1.32; previous revision: 1.31
done
36. [ 892580, 892582 ] Fix of variable declaration in wxApp::Yield().
Checking in src/motif/app.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/motif/app.cpp,v <-- app.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/motif/app.cpp,v <-- app.cpp
new revision: 1.82; previous revision: 1.81
done
Checking in src/x11/app.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/x11/app.cpp,v <-- app.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/x11/app.cpp,v <-- app.cpp
new revision: 1.94; previous revision: 1.93
done
37. no-remap system option, and tool centring
Checking in src/msw/tbar95.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/msw/tbar95.cpp,v <-- tbar95.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/msw/tbar95.cpp,v <-- tbar95.cpp
new revision: 1.121; previous revision: 1.120
done
39. Fix for files opened by another app in wxFileName::GetModificationTime():
Checking in src/common/filename.cpp;
-/pack/cvsroots/wxwindows/wxWindows/src/common/filename.cpp,v <-- filename.cpp
+/pack/cvsroots/wxwindows/wxWidgets/src/common/filename.cpp,v <-- filename.cpp
new revision: 1.131; previous revision: 1.130
=======
-Enhancements for wxWindows 3.0
+Enhancements for wxWidgets 3.0
==============================
This table contains the brief summary of the issues below. Priority and
============
- Namespaces:
- We want to have all wxWindows identifiers in "wx" namespace but provide
+ We want to have all wxWidgets identifiers in "wx" namespace but provide
typedefs/#defines for backwards compatibility. This can be done easily
for the classes and the only real problem are the enums as they would
all have to be duplicated at both the global scope (with "wx" prefix) and
without templates, even if not all of its features would be available then)
- Exceptions
- We are not going to use exceptions in wxWindows itself but our code should
+ We are not going to use exceptions in wxWidgets itself but our code should
become exception safe. This is a very difficult task as it means that no
resource allocations (including memory, files, whatever) should be done
without using a smart pointer-like object to store the result as it is the
- wxLocale Extension (eg Currency)
- wxStreams review
- wxURL?
-- a way to tell wxWindows to check for any non-portable usage,
+- a way to tell wxWidgets to check for any non-portable usage,
for a given set of platforms. Sometimes you want to be able
to get away with non-portable usage, and sometimes not.
This is probably way too time-consuming to implement.
0. Introduction
---------------
-wxUniversal is a port of wxWindows which implements the various GUI controls
-by drawing them itself (using low level wxWindows classes). Please see
+wxUniversal is a port of wxWidgets which implements the various GUI controls
+by drawing them itself (using low level wxWidgets classes). Please see
- http://www.wxwindows.org/wxuniv.htm
+ http://www.wxwidgets.org/wxuniv.htm
for more details about it.
look completely differently without changing a single line of its code but
just changing the theme.
-Another advantage is that it makes writing ports of wxWindows for other
+Another advantage is that it makes writing ports of wxWidgets for other
platforms (such as OS/2, BeOS or QNX) much simpler, so it is of special
-interest to people interested in porting wxWindows to another platform.
+interest to people interested in porting wxWidgets to another platform.
However, wxUniversal doesn't have a 100% native look and feel unlike the
-other wxWindows ports - this is the price to pay for the extra flexibility.
+other wxWidgets ports - this is the price to pay for the extra flexibility.
1. Requirements and supported platforms
---------------------------------------
-wxUniversal is used together with another wxWindows port which provides the
+wxUniversal is used together with another wxWidgets port which provides the
"low level classes" mentioned above. Currently it can be built with wxMSW,
wxGTK or wxX11. In any case, you should download the sources for the
appropriate toolkit in addition to wxUniversal - in fact, you should download
Please refer to the Unix section below
-** the instructions may be out of date as for wxWindows 2.5.1+ **
+** the instructions may be out of date as for wxWidgets 2.5.1+ **
c) Other compilers
Borland:
5. Documentation and support
----------------------------
-Please note that wxUniversal is not as mature as the other wxWindows ports
+Please note that wxUniversal is not as mature as the other wxWidgets ports
and is currently officially in alpha stage. In particular, it is not really
intended for the end users but rather for developers at the current stage and
this is why we don't provide any binaries for it.
-There is no separate documentation for wxUniversal, please refer to wxWindows
+There is no separate documentation for wxUniversal, please refer to wxWidgets
documentation instead.
-Support for wxUniversal is available from the same places as for wxWindows
+Support for wxUniversal is available from the same places as for wxWidgets
itself, namely:
* Usenet newsgroup comp.soft-sys.wxwindows
* Mailing lists: see http://lists.wxwindows.org/ for more information
-* WWW page: http://www.wxwindows.org/
+* WWW page: http://www.wxwidgets.org/
Hope you find wxUniversal useful!
* The most simple case
-----------------------
-If you compile wxWindows on Linux for the first time and don't like to read
+If you compile wxWidgets on Linux for the first time and don't like to read
install instructions just do (in the base dir):
> ./configure --with-wine
> ldconfig
> exit
-If you want to remove wxWindows on Unix you can do this:
+If you want to remove wxWidgets on Unix you can do this:
> su <type root password>
> make uninstall
* The expert case
-----------------
-If you want to do some more serious cross-platform programming with wxWindows,
+If you want to do some more serious cross-platform programming with wxWidgets,
such as for GTK and Motif, you can now build two complete libraries and use
them concurrently. For this end, you have to create a directory for each build
-of wxWindows - you may also want to create different versions of wxWindows
+of wxWidgets - you may also want to create different versions of wxWidgets
and test them concurrently. Most typically, this would be a version configured
with --enable-debug_flag and one without. Note, that only one build can currently
be installed, so you'd have to use local version of the library for that purpose.
* General
-----------------------
-The Unix variants of wxWindows use GNU configure. If you have problems with your
+The Unix variants of wxWidgets use GNU configure. If you have problems with your
make use GNU make instead.
If you have general problems with installation, read my homepage at
* GUI libraries
-----------------------
-wxWindows/WINE requires the WINE library to be installed on your system.
+wxWidgets/WINE requires the WINE library to be installed on your system.
You can get the newest version of the WINE from the WINE homepage at:
are enabled by default.
Many of the configure options have been thoroughly tested
-in wxWindows snapshot 6, but not yet all (ODBC not).
+in wxWidgets snapshot 6, but not yet all (ODBC not).
You must do this by running configure with either of:
such as gdb (or its many frontends).
--enable-debug_flag Define __DEBUG__ and __WXDEBUG__ when
- compiling. This enable wxWindows' very
+ compiling. This enable wxWidgets' very
useful internal debugging tricks (such
as automatically reporting illegal calls)
to work. Note that program and library
-------------------
Many of the configure options have been thoroughly tested
-in wxWindows snapshot 6, but not yet all (ODBC not).
+in wxWidgets snapshot 6, but not yet all (ODBC not).
When producing an executable that is linked statically with wxGTK
you'll be surprised at its immense size. This can sometimes be
-drastically reduced by removing features from wxWindows that
+drastically reduced by removing features from wxWidgets that
are not used in your program. The most relevant such features
are
make install
-You can remove any traces of wxWindows by typing
+You can remove any traces of wxWidgets by typing
make uninstall
to stick to tmake.
2) The other way creates a project within the source code
-directories of wxWindows. For this endeavour, you'll need
+directories of wxWidgets. For this endeavour, you'll need
the usual number of GNU tools, at least
GNU automake version 1.4
-wxWindows Library License, Version 3
+wxWidgets Library License, Version 3
====================================
Copyright (C) 1998 Julian Smart, Robert Roebling et al.
1. As a special exception, the copyright holders of this library give
permission for additional uses of the text contained in this release of
- the library as licensed under the wxWindows Library License, applying
+ the library as licensed under the wxWidgets Library License, applying
either version 3 of the License, or (at your option) any later version of
the License as published by the copyright holders of version 3 of the
License document.
- Welcome to wxWindows/Wine 2.1 snapshot 7,
+ Welcome to wxWidgets/Wine 2.1 snapshot 7,
you have downloaded version 2.1 of the WINE port of
-the wxWindows GUI library. This is a developers release
+the wxWidgets GUI library. This is a developers release
and is it not suited for production development. Beware
that major changes can happen before a final release.
http://wesley.informatik.uni-freiburg.de/~wxxt
-and about the wxWindows project as a whole (and the
+and about the wxWidgets project as a whole (and the
Windows and Motif ports in particular) can be found
at Julian Smart's homepage at:
The library produced by the install process will be called
libwx_mse.a (static) and libwx_msw-2.1.so.0.0.0 (shared) so that
-once a binary incompatible version of wxWindows/Gtk comes out
+once a binary incompatible version of wxWidgets/Gtk comes out
we'll augment the library version number to avoid linking problems.
Please send problems concerning installation, feature requests,
-bug reports or comments to the wxWindows users list. Information
+bug reports or comments to the wxWidgets users list. Information
on how to subscribe is available from my homepage.
-wxWindows/Wine doesn't come with any guarantee whatsoever. It might
+wxWidgets/Wine doesn't come with any guarantee whatsoever. It might
crash your harddisk or destroy your monitor. It doesn't claim to be
suitable for any special or general purpose.
-wxWindows 2.5 for X11 installation
+wxWidgets 2.5 for X11 installation
----------------------------------
IMPORTANT NOTE:
mailing wxwin-users or the author. Preferably, try to fix the
problem first and then send a patch to the author.
- When sending bug reports tell us what version of wxWindows you are
+ When sending bug reports tell us what version of wxWidgets you are
using (including the beta) and what compiler on what system. One
example: wxX11 2.5.1, gcc 2.95.4, Redhat 6.2
- Download wxX11-x.y.z.tgz, where x.y.z is the version number.
Download documentation in a preferred format, such as
- wxWindows-HTML.zip or wxWindows-PDF.zip.
+ wxWidgets-HTML.zip or wxWidgets-PDF.zip.
- Make a directory such as ~/wx and unarchive the files into this
directory.
- It is recommended that you install bison and flex; using yacc
and lex may require tweaking of the makefiles. You also need
- libXpm if you want to have XPM support in wxWindows (recommended).
+ libXpm if you want to have XPM support in wxWidgets (recommended).
-- You can now use configure to build wxWindows and the samples.
+- You can now use configure to build wxWidgets and the samples.
Using configure is the recommended way to build the library. If it doesn't
work for you for whatever reason, please report it (together with detailed
* The simplest case
-------------------
-If you compile wxWindows on Linux for the first time and don't like to read
+If you compile wxWidgets on Linux for the first time and don't like to read
install instructions just do (in the base dir):
> ./configure --with-x11
> ldconfig
> exit
-If you want to remove wxWindows on Unix you can do this:
+If you want to remove wxWidgets on Unix you can do this:
> su <type root password>
> make uninstall
* The expert case
-----------------
-If you want to do some more serious cross-platform programming with wxWindows,
+If you want to do some more serious cross-platform programming with wxWidgets,
such as for GTK and X11, you can now build two complete libraries and use
them concurrently. For this end, you have to create a directory for each build
-of wxWindows - you may also want to create different versions of wxWindows
+of wxWidgets - you may also want to create different versions of wxWidgets
and test them concurrently. Most typically, this would be a version configured
with --enable-debug_flag and one without. Note, that only one build can
currently be installed, so you'd have to use local version of the library for
* General
---------
-The Unix variants of wxWindows use GNU configure. If you have problems with
+The Unix variants of wxWidgets use GNU configure. If you have problems with
your make use GNU make instead.
-If you have general problems with installation, see the wxWindows website at
+If you have general problems with installation, see the wxWidgets website at
- http://www.wxwindows.org/
+ http://www.wxwidgets.org/
for newest information. If you still don't have any success, please send a bug
report to one of our mailing lists (see my homepage) INCLUDING A DESCRIPTION OF
* GUI libraries
---------------
-wxWindows/X11 requires the X11 library to be installed on your system.
+wxWidgets/X11 requires the X11 library to be installed on your system.
* Additional libraries
----------------------
-wxWindows/X11 requires a thread library and X libraries known to work with
+wxWidgets/X11 requires a thread library and X libraries known to work with
threads. This is the case on all commercial Unix-Variants and all
Linux-Versions that are based on glibc 2 except RedHat 5.0 which is broken in
many aspects. As of writing this, virtually all Linux distributions have
Please send comments and question about the OS/2 installation
to Stefan Neis <Stefan.Neis@t-online.de> and patches to
-the wxWindows mailing list.
+the wxWidgets mailing list.
In the following list, the version numbers indicate the configuration that
was actually used by myself, newer version should cause no problems and
--disable-shared Do not create shared libraries.
- --enable-monolithic Build wxWindows as single library instead
+ --enable-monolithic Build wxWidgets as single library instead
of as several smaller libraries (which is
- the default since wxWindows 2.5.0).
+ the default since wxWidgets 2.5.0).
--disable-optimise Do not optimise the code. Can
sometimes be useful for debugging
such as gdb (or its many frontends).
--enable-debug_flag Define __DEBUG__ and __WXDEBUG__ when
- compiling. This enable wxWindows' very
+ compiling. This enable wxWidgets' very
useful internal debugging tricks (such
as automatically reporting illegal calls)
to work. Note that program and library
-----------------
Many of the configure options have been thoroughly tested
-in wxWindows snapshot 6, but not yet all (ODBC not).
+in wxWidgets snapshot 6, but not yet all (ODBC not).
When producing an executable that is linked statically with wxX11
you'll be surprised at its immense size. This can sometimes be
-drastically reduced by removing features from wxWindows that
+drastically reduced by removing features from wxWidgets that
are not used in your program. The most relevant such features
are
make install
-You can remove any traces of wxWindows by typing
+You can remove any traces of wxWidgets by typing
make uninstall
This is certain to become the standard way unless we decide
to stick to tmake.
-If your application uses only some of wxWindows libraries, you can
+If your application uses only some of wxWidgets libraries, you can
specify required libraries when running wx-config. For example,
`wx-config --libs=html,core` will only output link command to link
with libraries required by core GUI classes and wxHTML classes. See
the manual for more information on the libraries.
2) The other way creates a project within the source code
-directories of wxWindows. For this endeavour, you'll need
+directories of wxWidgets. For this endeavour, you'll need
GNU autoconf version 2.14 and add an entry to your Makefile.in
to the bottom of the configure.in script and run autoconf
and configure before you can type make.
# makewxx11
# Sets permissions (in case we extracted wxX11 from zip files)
# and makes wxX11.
- # Call from top-level wxWindows directory.
+ # Call from top-level wxWidgets directory.
# Note that this uses standard (but commonly-used) configure options;
# if you're feeling brave, you may wish to compile with threads:
# if they're not supported by the target platform, they will be disabled
-------:x-----Cut here-----:x-----
This script will build wxX11 using shared libraries. If you want to build
- a static wxWindows library, use --disable-shared.
+ a static wxWidgets library, use --disable-shared.
Troubleshooting
---------------
http://microwindows.org/
Nano-X is intended to work on devices with very small amounts
-of memory. wxWindows is quite a large library, so if your
+of memory. wxWidgets is quite a large library, so if your
memory is measured in KB instead of MB you will need to use
an alternative library, such as FLTK. However, with memory
-capacity increasing all the time, wxWindows could become
+capacity increasing all the time, wxWidgets could become
an appropriate embedded GUI solution for many projects.
-Also, it's possible to think of ways to cut wxWindows
+Also, it's possible to think of ways to cut wxWidgets
further down to size, such as disabling advanced controls
or rewriting utility functions. See the section on code size
below.
may find it convenient to put it in your .bash_profile or similar
file.
-Typically, various features in wxWindows will be switched off to
+Typically, various features in wxWidgets will be switched off to
conserve space. The sample script below calls configure with typical
options for Nano-X.
==========
Nano-X has a different API from Xlib, although there
-are many similarities. Instead of changing the wxWindows
+are many similarities. Instead of changing the wxWidgets
code to reflect Nano-X conventions, a compatibility
layer has been added, in the form of these files:
Code Size
=========
-Allow about 2.5 MB for a shared wxWindows library, with the
+Allow about 2.5 MB for a shared wxWidgets library, with the
dynamically linked minimal sample taking about 24KB. If statically
linked, minimal takes up just over 1MB when stripped. This 1MB
-includes all of wxWindows used in the minimal sample including some of
+includes all of wxWidgets used in the minimal sample including some of
the wxUniversal widgets. As application complexity increases,
-the amount of wxWindows code pulled into statically linked
+the amount of wxWidgets code pulled into statically linked
executables increases, but for large applications, the overhead
-of wxWindows becomes less significant.
+of wxWidgets becomes less significant.
Sample sizes:
-------------
- Rewrite functions or classes for alternative stripped-down
functionality.
- Remove unnecessary functionality or obsolete code from
- wxWindows.
-- Factor out wxWindows code to reduce repetition.
+ wxWidgets.
+- Factor out wxWidgets code to reduce repetition.
- Add inlining, remove unnecessary empty functions.
- Separate code out into individual files so that all of
a .o file doesn't get pulled in, just because an app
===================================
This script assumes that you will invoke it
-from a build directory under the wxWindows
+from a build directory under the wxWidgets
top level. So you might type:
% cd wx2
- Welcome to wxWindows/X11 2.5.1
+ Welcome to wxWidgets/X11 2.5.1
You have downloaded version 2.5.1 of the X11 port of
-the wxWindows GUI library. This runs on X11 with no
+the wxWidgets GUI library. This runs on X11 with no
Motif, Xt, GTK+ or any other standard widget set --
instead it uses the wxUniversal widgets. The intention
is to have it run on NanoX as well as desktop X11.
-More information about the wxWindows project as a whole
+More information about the wxWidgets project as a whole
can be found at:
- http://www.wxwindows.org
+ http://www.wxwidgets.org
Information on how to install can be found in the file
install.txt, but if you cannot wait, this should work on
When you run into problems, please read the install.txt and
follow those instructions. If you still don't have any success,
please send a bug report to one of our mailing lists (see
-the wxWindows homepage) INCLUDING A DESCRIPTION OF YOUR SYSTEM AND
+the wxWidgets homepage) INCLUDING A DESCRIPTION OF YOUR SYSTEM AND
YOUR PROBLEM, SUCH AS YOUR VERSION OF X, WHAT DISTRIBUTION YOU USE
AND WHAT ERROR WAS REPORTED. Alternatively, you may also use the bug
-reporting system linked from the wxWindows web page.
+reporting system linked from the wxWidgets web page.
The library produced by the install process will be called
libwx_x11univ[d].a (static) and libwx_x11univ[d]-2.3.so.0.0.0
(shared) so that once a binary incompatible version of
-wxWindows/X11 comes out we'll augment the library version number
+wxWidgets/X11 comes out we'll augment the library version number
to avoid linking problems.
Please send problems concerning installation, feature requests,
-bug reports or comments to the wxWindows users list. Information
-on how to subscribe is available from www.wxwindows.org.
+bug reports or comments to the wxWidgets users list. Information
+on how to subscribe is available from www.wxwidgets.org.
-wxWindows/X11 doesn't come with any guarantee whatsoever. It might
+wxWidgets/X11 doesn't come with any guarantee whatsoever. It might
crash your hard disk or destroy your monitor. It doesn't claim to be
suitable for any special or general purpose.
Regards,
- The wxWindows team
+ The wxWidgets team