+
<html>
<head>
-<title>wxWindows 2 FAQ</title>
+<title>wxWidgets 2 FAQ</title>
</head>
<body bgcolor=#ffffff text=#000000 vlink="#00376a" link="#00529c" alink="#313063">
<tr>
<td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif">
<font size=+1 face="arial, lucida sans, helvetica" color="#ffffff">
-<b>wxWindows 2 FAQ</b>
+<b>wxWidgets 2 FAQ</b>
</font>
</td>
</tr>
<p>
-Welcome to the wxWi
ndows FAQ. Please select a category:<p>
+Welcome to the wxWi
dgets FAQ. Please select a category:<p>
<ul>
<li><a href="faqgen.htm">General questions</a>
<p>
For further information, please see the
-<a href="http://www.wxwindows.org" target=_top>wxWindows Web site</a>,
-<a href="http://wiki.wxwindows.org" target=_top>wxWiki</a>
+<a href="http://www.wxwidgets.org" target=_top>wxWidgets Web site</a>,
+<a href="http://wiki.wxwidgets.org" target=_top>wxWiki</a>
and install.txt (per port), todo.txt (per port), and bugs.txt (all ports) files
-in your wxWindows installation.
+in your wxWidgets installation.
<p>
</font>
<HTML>
<HEAD>
-<TITLE>wxWindows 2 FAQ: General</TITLE>
+<TITLE>wxWidgets 2 FAQ: General</TITLE>
</HEAD>
<BODY BGCOLOR=#FFFFFF TEXT=#000000 VLINK="#00376A" LINK="#00529C" ALINK="#313063">
<tr>
<td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif">
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
-<b>wxWindows 2 FAQ: General</b>
+<b>wxWidgets 2 FAQ: General</b>
</font>
</td>
</tr>
<hr>
<h3>List of questions in this category</h3>
<ul>
-<li><a href="#whatis">What is wxWindows?</a></li>
-<li><a href="#licence">Can I use wxWindows 2 for both proprietary projects, and GPL'ed projects?</a></li>
+<li><a href="#whatis">What is wxWidgets?</a></li>
+<li><a href="#licence">Can I use wxWidgets 2 for both proprietary projects, and GPL'ed projects?</a></li>
<li><a href="#support">Is there support?</a></li>
-<li><a href="#users">Who uses wxWindows?</a></li>
-<li><a href="#platforms">What platforms are supported by wxWindows?</a></li>
-<li><a href="#specific">How does wxWindows support platform-specific features?</a></li>
-<li><a href="#stl">Does wxWindows use STL? or the standard string class?</a></li>
-<li><a href="#richedit">Is there a rich edit/markup widget for wxWindows?</a></ li>
-<li><a href="#exceptions">How to use C++ exceptions with wxWindows?</a></ li>
-<li><a href="#dev">How is wxWindows being developed?</a></li>
-<li><a href="#distrib">How is wxWindows distributed?</a></li>
+<li><a href="#users">Who uses wxWidgets?</a></li>
+<li><a href="#platforms">What platforms are supported by wxWidgets?</a></li>
+<li><a href="#specific">How does wxWidgets support platform-specific features?</a></li>
+<li><a href="#stl">Does wxWidgets use STL? or the standard string class?</a></li>
+<li><a href="#richedit">Is there a rich edit/markup widget for wxWidgets?</a></ li>
+<li><a href="#exceptions">How to use C++ exceptions with wxWidgets?</a></ li>
+<li><a href="#dev">How is wxWidgets being developed?</a></li>
+<li><a href="#distrib">How is wxWidgets distributed?</a></li>
<li><a href="#future">What are the plans for the future?</a></li>
<li><a href="#base">What is wxBase?</a></li>
<li><a href="#univ">What is wxUniversal?</a></li>
</ul>
<hr>
-<H3><a name="whatis">What is wxWindows?</a></H3>
+<H3><a name="whatis">What is wxWidgets?</a></H3>
-wxWindows is a class library that allows you to compile graphical C++ programs on a range of
-different platforms. wxWindows defines a common API across platforms, but uses the native graphical user interface (GUI) on each platform,
+wxWidgets is a class library that allows you to compile graphical C++ programs on a range of
+different platforms. wxWidgets defines a common API across platforms, but uses the native graphical user interface (GUI) on each platform,
so your program will take on the native 'look and feel' that users are familiar with.<P>
Although GUI applications are mostly built programmatically, there are several dialog editors to help
and Anthemion Software's <a href="http://www.anthemion.co.uk/dialogblocks/" target=_new>DialogBlocks</a>
are two commercial examples, but there are others: see the <a href="lnk_tools.htm">Useful Tools</a> page.<P>
-You don't have to use C++ to use wxWindows: there is a <a href="http://wxpython.org">Python interface</a> for wxWindows 2,
+You don't have to use C++ to use wxWidgets: there is a <a href="http://wxpython.org">Python interface</a> for wxWidgets 2,
and also a <a href="http://wxperl.sourceforge.net" target=_top>Perl interface</a>.
<P>
-<h3><a name="licence">Can I use wxWindows 2 for both proprietary (commercial) projects, and GPL'ed projects?</a></h3>
+<h3><a name="licence">Can I use wxWidgets 2 for both proprietary (commercial) projects, and GPL'ed projects?</a></h3>
Yes. Please see the <a href="newlicen.htm">licence</a> for details, but basically
-you can distribute proprietary binaries without distributing any source code, and neither will wxWindows
+you can distribute proprietary binaries without distributing any source code, and neither will wxWidgets
conflict with GPL code you may be using or developing with it.
<P>
-The conditions for using wxWindows 2 are the same whether you are a personal, academic
+The conditions for using wxWidgets 2 are the same whether you are a personal, academic
or commercial developer.
<P>
<h3><a name="support">Is there support?</a></h3>
No official support, but the mailing list is very helpful and some people say that
-wxWindows support is better than for much commercial software. The developers are
+wxWidgets support is better than for much commercial software. The developers are
keen to fix bugs as soon as possible, though obviously there are no guarantees.
<P>
-<H3><a name="users">Who uses wxWindows?</a></H3>
+<H3><a name="users">Who uses wxWidgets?</a></H3>
Many organisations - commercial, government, and academic - across the
world. It's impossible to estimate the true number of users, since
-wxWindows is obtained by many different means, and we cannot monitor
+wxWidgets is obtained by many different means, and we cannot monitor
distribution. The mailing list contains around 300-400 entries which is
quite large for a list of this type.<P>
and his <a href="http://www.osafoundation.org" target=_new>Open Source Applications Foundation</a>.
<P>
-<H3><a name="platforms">What platforms are supported by wxWindows 2?</a></H3>
+<H3><a name="platforms">What platforms are supported by wxWidgets 2?</a></H3>
<ul>
<li>Windows 3.1, Windows 95/98, Windows NT, Windows 2000, Windows ME.
<li>Unix with Motif or the free Motif clone Lesstif.
<li>Mac OS.
<li>Embedded platforms are being investigated. See the <a href="wxuniv.htm">wxUniversal</a> project.
-<li>An OS/2 port is in progress, and you can also compile wxWindows for GTK+ or Motif
+<li>An OS/2 port is in progress, and you can also compile wxWidgets for GTK+ or Motif
on OS/2.
</ul>
<P>
-<H3><a name="specific">How does wxWindows 2 support platform-specific
+<H3><a name="specific">How does wxWidgets 2 support platform-specific
features?</a></H3>
This is a hotly-debated topic amongst the developers. My own philosophy
-is to make wxWindows as platform-independent as possible, but allow in a
+is to make wxWidgets as platform-independent as possible, but allow in a
few classes (functions, window styles) that are platform-specific.
For example, Windows metafiles and Windows 95 taskbar icons have
their own classes on Windows, but nowhere else. Because these classes
-are provided and are wxWindows-compatible, it doesn't take much
+are provided and are wxWidgets-compatible, it doesn't take much
coding effort for an application programmer to add support for
some functionality that the user on a particular platform might otherwise
miss. Also, some classes that started off as platform-specific, such
that even wxTaskBarIcon may be implemented for Unix desktops one day.
<P>
-In other words, wxWindows is not a 'lowest common denominator' approach,
+In other words, wxWidgets is not a 'lowest common denominator' approach,
but it will still be possible to write portable programs using the
core API. Forbidding some platform-specific classes would be a stupid
approach that would alienate many potential users, and encourage
-the perception that toolkits such as wxWindows are not up to the demands
+the perception that toolkits such as wxWidgets are not up to the demands
of today's sophisticated applications.<P>
Currently resources such as bitmaps and icons are handled in a platform-specific
way, but it is hoped to reduce this dependence in due course.<P>
-Another reason why wxWindows 2 is not a 'lowest common denominator' toolkit is that
+Another reason why wxWidgets 2 is not a 'lowest common denominator' toolkit is that
some functionality missing on some platform has been provided using generic,
platform-independent code, such as the wxTreeCtrl and wxListCtrl classes.<P>
-<H3><a name="stl">Does wxWindows use STL? or the standard string class?</a></H3>
+<H3><a name="stl">Does wxWidgets use STL? or the standard string class?</a></H3>
No. This is a much-discussed topic that has (many times) ended with the conclusion that it is in
-wxWindows' best interests to avoid use of templates. Not all compilers can handle
+wxWidgets' best interests to avoid use of templates. Not all compilers can handle
templates adequately so it would dramatically reduce the number of compilers
and platforms that could be supported. It would also be undersirable to make
-wxWindows dependent on another large library that may have to be downloaded and installed.
+wxWidgets dependent on another large library that may have to be downloaded and installed.
In addition, use of templates can lead to executable bloat, which is something
-wxWi
ndows 2 is strenously trying to avoid.<P>
+wxWi
dgets 2 is strenously trying to avoid.<P>
The standard C++ string class is not used, again because it is not available to all compilers,
and it is not necessarily a very efficient implementation. Also, we retain more flexibility
has been built into wxString.<P>
There is nothing to stop an application using templates or the string class for its own
-purposes. With wxWindows debugging options on, you may find you get errors when including
+purposes. With wxWidgets debugging options on, you may find you get errors when including
STL headers. You can work around it either by switching off memory checking,
or by adding this to a header before you include any STL files:<P>
<P>
-<H3><a name="richedit">Is there a rich edit/markup widget for wxWindows 2?</a></H3>
+<H3><a name="richedit">Is there a rich edit/markup widget for wxWidgets 2?</a></H3>
These are the possibilities so far:<P>
<ul>
<li>See <a href="http://www.scintilla.org" target=_top>www.scintilla.org</a> for
-a very nice syntax-highlighting editor widget. Robin Dunn has written a wxWindows wrapper
-for this widget, available in the wxWindows distribution under contrib/src/stc.
+a very nice syntax-highlighting editor widget. Robin Dunn has written a wxWidgets wrapper
+for this widget, available in the wxWidgets distribution under contrib/src/stc.
<li>If you only need to display marked-up information, rather than edit it,
-then wxHTML will suit your needs. wxHTML is built into wxWindows - please see the reference
+then wxHTML will suit your needs. wxHTML is built into wxWidgets - please see the reference
manual for details, and samples/html.
<li>There are rich edit widgets in both WIN32 and GTK+, but there is currently
-no wxWindows wrapper for these (but text attribute functions are being added in the wxWindows 2.3.x series).
+no wxWidgets wrapper for these (but text attribute functions are being added in the wxWidgets 2.3.x series).
</ul>
<P>
-<h3><a name="exceptions">How to use C++ exceptions with wxWindows?</a></h3>
+<h3><a name="exceptions">How to use C++ exceptions with wxWidgets?</a></h3>
-wxWindows library itself is unfortunately <i>not</i> exception-safe (as its
+wxWidgets library itself is unfortunately <i>not</i> exception-safe (as its
initial version predates, by far, the addition of the exceptions to the C++
language). However you can still use the exceptions in your own code and use
the other libraries using the exceptions for the error reporting together with
-wxWindows.
+wxWidgets.
<p>
There are a few issues to keep in mind, though:
<ul>
- <li>You shouldn't let the exceptions propagate through wxWindows code,
+ <li>You shouldn't let the exceptions propagate through wxWidgets code,
in particular you should always catch the exceptions thrown by the
functions called from an event handler in the handler itself and not
- let them propagate upwards to wxWindows.
+ let them propagate upwards to wxWidgets.
<li>You may need to ensure that the compiler support for the exceptions is
- enabled as, considering that wxWindows itself doesn't use the
+ enabled as, considering that wxWidgets itself doesn't use the
exceptions and turning their support on results in the library size
augmentation of 10% to 20%, it is turned off by default for a few
compilers. Moreover, for gcc (or at least its mingw version) you must
<p>
-<H3><a name="dev">How is wxWindows being developed?</a></H3>
+<H3><a name="dev">How is wxWidgets being developed?</a></H3>
-We are using the <a href="cvs.htm">CVS</a> system to develop and maintain wxWindows. This allows
+We are using the <a href="cvs.htm">CVS</a> system to develop and maintain wxWidgets. This allows
us to make alterations and upload them instantly to the server, from
which others can update their source.<P>
-To build source from CVS, see the file BuildCVS.txt in the top-level wxWindows distribution
+To build source from CVS, see the file BuildCVS.txt in the top-level wxWidgets distribution
directory.<P>
-<H3><a name="distrib">How is wxWindows distributed?</a></H3>
+<H3><a name="distrib">How is wxWidgets distributed?</a></H3>
-By ftp, and via the <a href="cdrom2.htm">wxWindows CD-ROM</a>.
+By ftp, and via the <a href="cdrom2.htm">wxWidgets CD-ROM</a>.
<P>
If you are feeling adventurous, you may also check out the sources directly
from <a href="cvs.htm">cvs</a>.
<H3><a name="future">What are the plans for the future?</a></H3>
-Currently we're working too hard on getting wxWindows finished (are GUI toolkits ever
-finished?) to think very far ahead. However, we know we want to make wxWindows as robust
+Currently we're working too hard on getting wxWidgets finished (are GUI toolkits ever
+finished?) to think very far ahead. However, we know we want to make wxWidgets as robust
and well-publicised as possible. We also want to aim for better platform-independence of
resources such as icons and bitmaps, standardising on PNG and XPM for all platforms.<P>
-Other possibilities include: DCOM/CORBA compatibility; a wxWindows book;
+Other possibilities include: DCOM/CORBA compatibility; a wxWidgets book;
<a href="http://wxworkshop.sourceforge.net/">wxWorkshop</a>, an IDE;
other platforms, especially embedded systems; other interface abilities such as speech output.<P>
-We will investigate the possibility of compiler or operating system vendors bundling wxWindows with
+We will investigate the possibility of compiler or operating system vendors bundling wxWidgets with
their product.<P>
-The high-level goal of wxWindows is to be thought of as the number one C++ framework,
+The high-level goal of wxWidgets is to be thought of as the number one C++ framework,
for virtually any platform. Move over, MFC!<P>
<h3><a name="base">What is wxBase?</a></h3>
-wxBase is a subset of wxWindows comprised by the non-GUI classes. It includes
-wxWindows container and primitive data type classes (including wxString,
+wxBase is a subset of wxWidgets comprised by the non-GUI classes. It includes
+wxWidgets container and primitive data type classes (including wxString,
wxDateTime and so on) and also useful wrappers for the operating system objects
such as files, processes, threads, sockets and so on. With very minor
-exceptions wxBase may be used in exactly the same way as wxWindows but it
+exceptions wxBase may be used in exactly the same way as wxWidgets but it
doesn't require a GUI to run and so is ideal for creating console mode
utilities or server programs. It is also possible to create a program which can
be compiled either as a console application (using wxBase) or a GUI one (using
-a full featured wxWindows port).
+a full featured wxWidgets port).
<H3><a name="univ">What is wxUniversal?</a></H3>
The main difference between wxUniversal-based ports (such as wxX11, wxMGL) and other ports (such as wxMSW, wxGTK+, wxMac)
is that wxUniversal implements all controls (or widgets) in
-wxWindows itself thus allowing to have much more flexibility (for example, support for
+wxWidgets itself thus allowing to have much more flexibility (for example, support for
themes even under MS Windows). It also means that it is now much easier to
-port wxWindows to a new platform as only the low-level classes must be ported
+port wxWidgets to a new platform as only the low-level classes must be ported
which make for a small part of the library.
<p>
You may find more about wxUniversal <a href=wxuniv.htm>here</a>.
The Java honeymoon period is over :-) and people are realising that it cannot
meet all their cross-platform development needs. We don't anticipate a major threat
-from Java, and the level of interest in wxWi
ndows is as high as ever.<P>
+from Java, and the level of interest in wxWi
dgets is as high as ever.<P>
<H3><a name="dotnet">What about .NET/Mono?</a></H3>
Although this may be attractive to some developers, there
is a variety of reasons why the .NET/Mono combination is unlikely
-to make wxWindows redundant. Please note that the following comments
+to make wxWidgets redundant. Please note that the following comments
are Julian Smart's opinions.<P>
<ol>
<li>Not everyone wants or needs net services.
<li>C++ will be used for a long time to come; compared with C++, C# is a recent development and its future is not certain.
<li>Mono Forms may only target Winelib (at least to begin with), so the end result is not as native as
-wxWindows (I'm aware there is GTK# for use with the C# language).
+wxWidgets (I'm aware there is GTK# for use with the C# language).
<li>C# is usually byte-compiled and therefore slower. Plus, .NET adds a layer of overhead to the client computer
-that wxWindows does not require.
-<li>Mono hasn't proven its long-term viability yet (it's a complex system of components); wxWindows is ready now.
+that wxWidgets does not require.
+<li>Mono hasn't proven its long-term viability yet (it's a complex system of components); wxWidgets is ready now.
<li>You may not wish to buy into Microsoft marketing spin and APIs.
<li>Microsoft may at some point sue developers of non-Microsoft .NET implementations. After all,
platform-independence is not in Microsoft's interest.
<li>.NET might never be implemented on some platforms, especially Mac and embedded variants of Linux.
-<li>wxPython and other language variants provide further reasons for wxWindows to continue.
+<li>wxPython and other language variants provide further reasons for wxWidgets to continue.
<li>The same issue exists for Qt: if Qt sales remain strong, it's a good indication that
-the market for a C++-based approach is still there. (Either that, or everyone's turning to wxWindows!)
+the market for a C++-based approach is still there. (Either that, or everyone's turning to wxWidgets!)
</ol>
-There is nothing to stop folk from developing a C# version of the wxWindows API;
+There is nothing to stop folk from developing a C# version of the wxWidgets API;
we already have bindings to Python, Perl, JavaScript, Lua, Basic, and Eiffel.
Update: a <a href="http://wxnet.sourceforge.net/" target=_new>wx.NET</a> project is now in progress.
+
<HTML>
<HEAD>
-<TITLE>wxWindows 2 for GTK FAQ</TITLE>
+<TITLE>wxWidgets 2 for GTK FAQ</TITLE>
</HEAD>
<BODY BGCOLOR=#FFFFFF TEXT=#000000 VLINK="#00376A" LINK="#00529C" ALINK="#313063">
<tr>
<td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif">
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
-<b>wxWindows 2 for GTK FAQ</b>
+<b>wxWidgets 2 for GTK FAQ</b>
</font>
</td>
</tr>
<P>
-See also <a href="faq.htm">top-level FAQ page</a>
+See also <a href="faq.htm">top-level FAQ page</a>
and <a href="faqunx.htm">Unix FAQ page</a>.
<hr>
<h3>List of questions in this category</h3>
<ul>
-<li><a href="#wxgtk">What is wxWindows 2 for GTK+?</a></li>
-<li><a href="#locale">Why doesn't reading floating point numbers work when using wxWindows?</a></li>
+<li><a href="#wxgtk">What is wxWidgets 2 for GTK+?</a></li>
+<li><a href="#locale">Why doesn't reading floating point numbers work when using wxWidgets?</a></li>
<li><a href="#gnome">Does wxGTK have GNOME support?</a></li>
<li><a href="#redhat">Warning about GTK libraries supplied with RedHat</a></li>
<li><a href="#bincompat">What range of Intel Linux platforms will a given application binary be usable on?</a></li>
<hr>
-<h3><a name="wxgtk">What is wxWindows 2 for GTK?</a></h3>
+<h3><a name="wxgtk">What is wxWidgets 2 for GTK?</a></h3>
-wxWi
ndows 2 for GTK is a port of wxWindows to the <a href="http://www.gimp.org/gtk" target=_top>GTK+ toolkit</a>,
-which is freely available for most flavours of Unix with X. wxWindows 2 for GTK is
+wxWi
dgets 2 for GTK is a port of wxWidgets to the <a href="http://www.gimp.org/gtk" target=_top>GTK+ toolkit</a>,
+which is freely available for most flavours of Unix with X. wxWidgets 2 for GTK is
often abbreviated to wxGTK. wxGTK has a separate home page <a href="http://www.freiburg.linux.de/~wxxt" target=_top>here</a>.
<P>
-<h3><a name="locale">Why doesn't reading floating point numbers work when using wxWindows?</a></h3>
+<h3><a name="locale">Why doesn't reading floating point numbers work when using wxWidgets?</a></h3>
If your program reads the floating point numbers in the format <tt>123.45</tt>
from a file, it may suddently start returning just <tt>123</tt> instead of the
<h3><a name="redhat">Warning about GTK+ libraries supplied with RedHat</a></h3>
It seems that some versions of RedHat include a badly patched version of GTK+ (not wxGTK)
-which causes some trouble with wxWindows' socket code. Common symptoms are that when
+which causes some trouble with wxWidgets' socket code. Common symptoms are that when
a client tries to establish a connection to an existing server which refuses the request,
the client will get notified twice, first getting a LOST event and then a CONNECT event.
This problem can be solved by updating GTK with an official distribution of the library.
<HTML>
<HEAD>
-<TITLE>wxWindows 2 for Mac FAQ</TITLE>
+<TITLE>wxWidgets 2 for Mac FAQ</TITLE>
</HEAD>
<BODY BGCOLOR=#FFFFFF TEXT=#000000 VLINK="#00376A" LINK="#00529C" ALINK="#313063">
<tr>
<td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif">
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
-<b>wxWindows 2 for Mac FAQ</b>
+<b>wxWidgets 2 for Mac FAQ</b>
</font>
</td>
</tr>
<li><a href="#smarterrors">What are the smart preprocessing errors with the Apple Developer Tools?</a></li>
<li><a href="#aboutmenu">How does wxMac support the standard Apple About menu item and Help menu?</a></li>
<li><a href="#findericon">How do I add an icon to my application?</a></li>
-<li><a href="#switching">How can I easily switch between different versions of wxWindows in CodeWarrior?</a></li>
+<li><a href="#switching">How can I easily switch between different versions of wxWidgets in CodeWarrior?</a></li>
</ul>
<hr>
<h3><a name="macplat">Which Mac platforms are supported?</a></h3>
-wxWindows 2 can be used to develop and deliver applications on Classic Mac OS (e.g. Mac OS 8.x/9.x) both as Carbon and non-Carbon applications.
+wxWidgets 2 can be used to develop and deliver applications on Classic Mac OS (e.g. Mac OS 8.x/9.x) both as Carbon and non-Carbon applications.
<P>
-A Mac OS X port is in progress in order to be able to build wxWindows applications using the Apple Developer Tools that are delivered with every copy of Mac OS X.
+A Mac OS X port is in progress in order to be able to build wxWidgets applications using the Apple Developer Tools that are delivered with every copy of Mac OS X.
The Mac OS X port is based on and, for the most part, merged with the Carbon code for Classic Mac OS.
<P>
<h3><a name="macosx">How is the Mac OS X port different from the Classic Mac OS port?</a></h3>
-wxMac for Mac OS X shares code both with wxMac for Mac OS and common Unix code in wxWindows. The aim is to use the same Mac OS Carbon code both for Classic Mac OS and for Mac OS X while leveraging the fact that Mac OS X is a BSD Unix.
+wxMac for Mac OS X shares code both with wxMac for Mac OS and common Unix code in wxWidgets. The aim is to use the same Mac OS Carbon code both for Classic Mac OS and for Mac OS X while leveraging the fact that Mac OS X is a BSD Unix.
<P>
This hybrid approach was suggested by Apple to the <a href="http://www.mozilla.org/ports/fizzilla/">Fizzilla</a> team working on <a href="http://www.mozilla.org/">Mozilla</a> for Mac OS X.
<P>
<h3><a name="filetypes">How does CVS handle file types/creators under Mac OS 8.x/9.x?</a></h3>
-Before checking out the wxWindows code using a CVS client under Mac OS 8.x/9.x, be sure your computer is set up to treat <code>xpm</code> and <code>xbm</code> images correctly:
+Before checking out the wxWidgets code using a CVS client under Mac OS 8.x/9.x, be sure your computer is set up to treat <code>xpm</code> and <code>xbm</code> images correctly:
<ul>
<li>bring up the Internet control panel, select the <i>Advanced Options</i> tab, click on the <i>File Mapping</i> icon from the list at the left and see if there are is an entry for ".xpm" files and another for ".xbm".
<li>if an entry exists, click <i>Change...</i> and make sure <i>File Type</i> is <code>TEXT</code> (just those four capital letters); correct it if necessary. If there is no entry, make one with type set to <code>TEXT</code> and creator set to anything you like; reasonable choices include <code>GKON</code> (Graphic Converter) or <code>CWIE</code> (CodeWarrior).
<P>
All files checked out under Mac OS X will be untyped and CodeWarrior will not recognize them correctly. To correct this, use the autotyper provided in the CVS sources:
<ul>
-<li>decode and decompress the file <code>wxWindows/docs/mac/TypeAsMetrowerksText.sea.hqx</code>
-<li>drag the wxWindows CVS sandbox directory onto the autotyper and most of the files will be typed according to the file extension
+<li>decode and decompress the file <code>wxWidgets/docs/mac/TypeAsMetrowerksText.sea.hqx</code>
+<li>drag the wxWidgets CVS sandbox directory onto the autotyper and most of the files will be typed according to the file extension
</ul>
<P>
<P>
Build the projects (<code>makemac6.mcp</code> for CodeWarrior Pro 6; <code>makemac.mpc</code> for CodeWarrior Pro 5) in the following five directories:
<ul>
-<li>wxWindows:src:
-<li>wxWindows:src:jpeg:
-<li>wxWindows:src:png:
-<li>wxWindows:src:tiff:
-<li>wxWindows:src:zlib:
+<li>wxWidgets:src:
+<li>wxWidgets:src:jpeg:
+<li>wxWidgets:src:png:
+<li>wxWidgets:src:tiff:
+<li>wxWidgets:src:zlib:
</ul>
<P>
<P>
Building wxMac completely without configure is not supported.
<P>
-Building wxWindows directly in the CVS sandbox is not recommended. Instead, wxWindows should be built in a directory configured relatively to the CVS sandbox.
-For instance, to build wxMac with configure, start in the base wxWindows directory and type:
+Building wxWidgets directly in the CVS sandbox is not recommended. Instead, wxWidgets should be built in a directory configured relatively to the CVS sandbox.
+For instance, to build wxMac with configure, start in the base wxWidgets directory and type:
<ul>
<li><code>mkdir macbuild</code>
<li><code>cd macbuild</code>
<h3><a name="aboutmenu">How does wxMac support the standard Apple About menu item and Help menu?</a></h3>
-Because wxWindows does not have a specific API for the <i>About</i> menu item or the <i>Help</i> menu, the Mac OS port uses some static variables to help the engine make the right decisions:
+Because wxWidgets does not have a specific API for the <i>About</i> menu item or the <i>Help</i> menu, the Mac OS port uses some static variables to help the engine make the right decisions:
<ul>
<li>It assumes that the <i>About</i> menu item is part of a <i>Help</i> menu.
<li>The title of the <i>Help</i> menu is stored in <code>wxApp::s_macHelpMenuTitleName</code>, it defaults to "&Help", but you can change it in your constructor to your specific menu title.
<li>The item Id of the <i>About</i> menu is stored in <code>wxApp::s_macAboutMenuItemID</code>, it defaults to <code>wxID_ABOUT</code>, but can be changed as well to suit your needs.
-<li>The other items of the wxWindows help menu are appended to the Mac OS <i>Help</i> menu and the translation of Ids is handled transparently for your application.
+<li>The other items of the wxWidgets help menu are appended to the Mac OS <i>Help</i> menu and the translation of Ids is handled transparently for your application.
</ul>
<P>
Flags/Finder Flags/Has Custom Icon.
<P>
-<h3><a name="switching">How can I easily switch between different versions of wxWindows in CodeWarrior?</a></h3>
+<h3><a name="switching">How can I easily switch between different versions of wxWidgets in CodeWarrior?</a></h3>
Sometimes you want to test your application against different versions
-of wxWindows, for example a stable version of wxWindows versus a development version.
+of wxWidgets, for example a stable version of wxWidgets versus a development version.
The easiest way to do this is to create a symbolic path.<P>
Under Edit-Preferences in General:Source Trees, type a name (for example WXWIN)
+
<HTML>
<HEAD>
-<TITLE>wxWindows 2 for Motif FAQ</TITLE>
+<TITLE>wxWidgets 2 for Motif FAQ</TITLE>
</HEAD>
<BODY BGCOLOR=#FFFFFF TEXT=#000000 VLINK="#00376A" LINK="#00529C" ALINK="#313063">
<tr>
<td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif">
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
-<b>wxWindows 2 for Motif FAQ</b>
+<b>wxWidgets 2 for Motif FAQ</b>
</font>
</td>
</tr>
<ul>
<li><a href="#versiob">What version of Motif do I need?</a></li>
<li><a href="#missing">What features are missing or partially implemented?</a></li>
-<li><a href="#dialoged">Does Dialog Editor work with wxWindows for Motif?</a></li>
+<li><a href="#dialoged">Does Dialog Editor work with wxWidgets for Motif?</a></li>
<li><a href="#refresh">Why are windows are not refreshed properly until I resize them?</a></li>
</ul>
<hr>
<p>
-<h3><a name="dialoged">Does Dialog Editor work with wxWindows for Motif?</a></h3>
+<h3><a name="dialoged">Does Dialog Editor work with wxWidgets for Motif?</a></h3>
Suport for Dialog Editor is almost there, but there are some wrinkles to iron
out. You may find it's useful though: compile it and see.
+
<HTML>
<HEAD>
-<TITLE>wxWindows 2 for Windows FAQ</TITLE>
+<TITLE>wxWidgets 2 for Windows FAQ</TITLE>
</HEAD>
<BODY BGCOLOR=#FFFFFF TEXT=#000000 VLINK="#00376A" LINK="#00529C" ALINK="#313063">
<tr>
<td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif">
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
-<b>wxWindows 2 for Windows FAQ</b>
+<b>wxWidgets 2 for Windows FAQ</b>
</font>
</td>
</tr>
<li><a href="#wince">What about Windows CE?</a></li>
<li><a href="#winxp">What do I need to do for Windows XP?</a></li>
<li><a href="#compilers">What compilers are supported?</a></li>
-<li><a href="#bestcompiler">Which is the best compiler to use with wxWindows 2?</a></li>
+<li><a href="#bestcompiler">Which is the best compiler to use with wxWidgets 2?</a></li>
<li><a href="#unicode">Is Unicode supported?</a></li>
-<li><a href="#doublebyte">Does wxWindows support double byte fonts (Chinese/Japanese/Korean etc.)?</a></li>
-<li><a href="#dll">Can you compile wxWindows 2 as a DLL?</a></li>
+<li><a href="#doublebyte">Does wxWidgets support double byte fonts (Chinese/Japanese/Korean etc.)?</a></li>
+<li><a href="#dll">Can you compile wxWidgets 2 as a DLL?</a></li>
<li><a href="#exesize">How can I reduce executable size?</a></li>
-<li><a href="#mfc">Is wxWindows compatible with MFC?</a></li>
+<li><a href="#mfc">Is wxWidgets compatible with MFC?</a></li>
<li><a href="#setuph">Why do I get errors about setup.h not being found?</a></li>
<li><a href="#asuffix">Why do I get errors about FooBarA when I only use FooBar in my program?</a></li>
<li><a href="#newerrors">Why my code fails to compile with strange errors about new operator?</a></li>
-<li><a href="#mfcport">How do I port MFC applications to wxWindows?</a></li>
+<li><a href="#mfcport">How do I port MFC applications to wxWidgets?</a></li>
<li><a href="#crash">Why do I sometimes get bizarre crash problems using VC++ 5/6?</a></li>
-<li><a href="#makefiles">How are the wxWindows makefiles edited under Windows?</a></li>
-<li><a href="#vcdebug">How do you use VC++'s memory leak checking instead of that in wxWindows?</a></li>
+<li><a href="#makefiles">How are the wxWidgets makefiles edited under Windows?</a></li>
+<li><a href="#vcdebug">How do you use VC++'s memory leak checking instead of that in wxWidgets?</a></li>
<li><a href="#shortcutproblem">Why are menu hotkeys or shortcuts not working in my application?</a></li>
<li><a href="#regconfig">Why can I not write to the HKLM part of the registry with wxRegConfig?</a></li>
<li><a href="#access">Is MS Active Accessibility supported?</a></li>
-<li><a href="#dspfmt">Why does Visual C++ complain about corrupted project files??</a></li>
+<li><a href="#dspfmt">Why does Visual C++ complain about corrupted project files{/a></li>
</ul>
<hr>
<h3><a name="platforms">Which Windows platforms are supported?</a></h3>
-wxWindows 2 can be used to develop and deliver applications on Windows 3.1, Win32s,
+wxWidgets 2 can be used to develop and deliver applications on Windows 3.1, Win32s,
Windows 95, Windows 98, Windows NT, Windows 2000, and Windows XP. A Windows CE
version is being looked into (see below).<P>
-wxWindows 2 is designed to make use of WIN32 features and controls. However, unlike Microsoft,
+wxWidgets 2 is designed to make use of WIN32 features and controls. However, unlike Microsoft,
we have not forgotten users of 16-bit Windows. Most features
work under Windows 3.1, including wxTreeCtrl and wxListCtrl using the generic implementation.
However, don't expect very Windows-95-specific classes to work, such as wxTaskBarIcon. The wxRegConfig
16-bit compilation is supported under Visual C++ 1.5, and Borland BC++ 4 to 5.
<P>
-wxWi
ndows 2 for Windows will also compile on Unix with gcc using Wine from <a href="http://www.winehq.org" target=_top>WineHQ</a>.
+wxWi
dgets 2 for Windows will also compile on Unix with gcc using Wine from <a href="http://www.winehq.org" target=_top>WineHQ</a>.
The resulting executables are Unix binaries that work with the Wine Windows API emulator.<P>
-You can also compile wxWindows 2 for Windows on Unix with Cygwin or Mingw32, resulting
+You can also compile wxWidgets 2 for Windows on Unix with Cygwin or Mingw32, resulting
in executables that will run on Windows. So in theory you could write your applications
-using wxGTK or wxMotif, then check/debug your wxWindows for Windows
+using wxGTK or wxMotif, then check/debug your wxWidgets for Windows
programs with Wine, and finally produce an ix86 Windows executable using Cygwin/Mingw32,
without ever needing a copy of Microsoft Windows. See the Technical Note on the Web site detailing cross-compilation.<P>
1 24 "winxp.manifest"
</PRE>
-In wxWindows 2.5, this will be in the wx/msw/wx.rc and
+In wxWidgets 2.5, this will be in the wx/msw/wx.rc and
so will happen automatically so long as you include wx.rc
in your own .rc file.<P>
<h3><a name="compilers">What compilers are supported?</a></h3>
-Please see the wxWindows 2 for Windows install.txt file for up-to-date information, but
+Please see the wxWidgets 2 for Windows install.txt file for up-to-date information, but
currently the following are known to work:<P>
<ul>
<P>
-<h3><a name="bestcompiler">Which is the best compiler to use with wxWindows 2?</a></h3>
+<h3><a name="bestcompiler">Which is the best compiler to use with wxWidgets 2?</a></h3>
It's partly a matter of taste, but I (JACS) prefer Visual C++ since the debugger is very
good, it's very stable, the documentation is extensive, and it generates small executables.
Since project files are plain text, it's easy for me to generate appropriate project files
-for wxWi
ndows samples.<P>
+for wxWi
dgets samples.<P>
Borland C++ is fine - and very fast - but it's hard (impossible?) to use the debugger without using project files, and
the debugger is nowhere near up to VC++'s quality. The IDE isn't great.<P>
-C++Builder's power isn't really used with wxWindows since it needs integration with its
-own class library (VCL). For wxWindows, I've only used it with makefiles, in which case
+C++Builder's power isn't really used with wxWidgets since it needs integration with its
+own class library (VCL). For wxWidgets, I've only used it with makefiles, in which case
it's almost identical to BC++ 5.0 (the same makefiles can be used).<P>
You can't beat Cygwin's price (free), and you can debug adequately using gdb. However, it's
Among the free compilers the best choice seem to be Borland C++ command line
tools and mingw32 (port of gcc to Win32). Both of them are supported by
-wxWindows.
+wxWidgets.
<h3><a name="unicode">Is Unicode supported?</a></h3>
href="http://www.microsoft.com/globaldev/handson/dev/mslu_announce.mspx">MSLU</a>.
<p>
-<h3><a name="doublebyte">Does wxWindows support double byte fonts (Chinese/Japanese/Korean etc.)?</a></h3>
+<h3><a name="doublebyte">Does wxWidgets support double byte fonts (Chinese/Japanese/Korean etc.)?</a></h3>
-For Japanese under Win2000, it seems that wxWindows has no problems to work
+For Japanese under Win2000, it seems that wxWidgets has no problems to work
with double byte char sets (meaning DBCS, not Unicode). First you have to
install Japanese support on your Win2K system and choose for ANSI translation
<tt>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage=932</tt>
(default is 1252 for Western). Then you can see all the Japanese letters in
-wxWindows applications.
+wxWidgets applications.
<p>
-<h3><a name="dll">Can you compile wxWindows 2 as a DLL?</a></h3>
+<h3><a name="dll">Can you compile wxWidgets 2 as a DLL?</a></h3>
Yes (using the Visual C++ or Borland C++ makefile), but be aware that distributing DLLs is a thorny issue
and you may be better off compiling statically-linked applications, unless you're
-delivering a suite of separate programs, or you're compiling a lot of wxWindows applications
+delivering a suite of separate programs, or you're compiling a lot of wxWidgets applications
and have limited hard disk space.<P>
-With a DLL approach, and with different versions and configurations of wxWindows
+With a DLL approach, and with different versions and configurations of wxWidgets
needing to be catered for, the end user may end up with a host of large DLLs in his or her Windows system directory,
negating the point of using DLLs. Of course, this is not a problem just associated with
-wxWindows!
+wxWidgets!
<P>
<h3><a name="exesize">How can I reduce executable size?</a></h3>
-You can compile wxWindows as a DLL (see above, VC++/BC++ only at present). You should also
+You can compile wxWidgets as a DLL (see above, VC++/BC++ only at present). You should also
compile your programs for release using non-debugging and space-optimisation options, but
take with VC++ 5/6 space optimisation: it can sometimes cause problems.<P>
Please do not be surprised if MinGW produces a statically-linked minimal executable of 1 MB. Firstly, gcc
produces larger executables than some compilers. Secondly, this figure will
-include most of the overhead of wxWindows, so as your application becomes more
+include most of the overhead of wxWidgets, so as your application becomes more
complex, the overhead becomes proportionally less significant. And thirdly, trading executable compactness
-for the enormous increase in productivity you get with wxWi
ndows is almost always well worth it.<P>
+for the enormous increase in productivity you get with wxWi
dgets is almost always well worth it.<P>
If you have a really large executable compiled with MinGW (for example 20MB) then
-you need to configure wxWindows to compile without debugging information: see
+you need to configure wxWidgets to compile without debugging information: see
docs/msw/install.txt for details. You may find that using configure instead
of makefile.g95 is easier, particularly since you can maintain debug and
release versions of the library simultaneously, in different directories.
Also, run 'strip' after linking to remove all traces of debug info.
<P>
-<H3><a name="mfc">Is wxWindows compatible with MFC?</a></H3>
+<H3><a name="mfc">Is wxWidgets compatible with MFC?</a></H3>
-There is a sample which demonstrates MFC and wxWindows code co-existing in the same
-application. However, don't expect to be able to enable wxWindows windows with OLE-2
+There is a sample which demonstrates MFC and wxWidgets code co-existing in the same
+application. However, don't expect to be able to enable wxWidgets windows with OLE-2
functionality using MFC.<P>
<H3><a name="setuph">Why do I get errors about setup.h not being found?</a></H3>
-When you build the wxWindows library, setup.h is copied
+When you build the wxWidgets library, setup.h is copied
from include/wx/msw/setup.h to e.g. lib/mswd/wx/setup.h (the path
depends on the configuration you're building). So you need to add
this include path if building using the static Debug library:<P>
setting <tt>wxUSE_GLOBAL_MEMORY_OPERATORS</tt> and
<tt>wxUSE_DEBUG_NEW_ALWAYS</tt> to 0 in this file
<li> Or leave them on but do <tt>#undef new</tt> after including any
- wxWindows headers, like this the memory debugging will be still on
- for wxWindows sources but off for your own code
+ wxWidgets headers, like this the memory debugging will be still on
+ for wxWidgets sources but off for your own code
</ul>
Notice that IMHO the first solution is preferable for VC++ users who can use
the <a href="#vcdebug">VC++ CRT memory debugging features</a> instead.
-<H3><a name="mfcport">How do I port MFC applications to wxWindows?</a></H3>
+<H3><a name="mfcport">How do I port MFC applications to wxWidgets?</a></H3>
-Set up your interface from scratch using wxWi
ndows (especially <a href="http://www.robeling.de" target=_top>wxDesigner</a>
+Set up your interface from scratch using wxWi
dgets (especially <a href="http://www.robeling.de" target=_top>wxDesigner</a>
or <a href="http://www.anthemion.co.uk/dialogblocks/" target=_new>DialogBlocks</a> --
it'll save you a <i>lot</i> of time) and when you have a shell prepared, you can start
'pouring in' code from the MFC app, with appropriate
it very satisfactory. A two-step process then - reproduce the bare
interface first, then wire it up afterwards. That way you deal
with each area of complexity separately. Don't try to think MFC
-and wxWindows simultaneously from the beginning - it is easier to
+and wxWidgets simultaneously from the beginning - it is easier to
reproduce the initial UI by looking at the behaviour of the MFC
app, not its code.
<H3><a name="crash">Why do I sometimes get bizarre crash problems using VC++ 5/6?</a></H3>
Some crash problems can be due to inconsistent compiler
-options (and of course this isn't limited to wxWindows).
+options (and of course this isn't limited to wxWidgets).
If strange/weird/impossible things start to happen please
check (dumping IDE project file as makefile and doing text comparison
if necessary) that the project settings, especially the list of defined
switch off optimisations, although this will result in much
larger executables. It seems possible that the library can be created with
strong optimization, so long as the application is not strongly
-optimized. For example, in wxWindows project, set to 'Minimum
+optimized. For example, in wxWidgets project, set to 'Minimum
Size'. In Dialog Editor project, set to 'Customize: Favor Small
Code' (and no others). This will then work.<P>
-<H3><a name="makefiles">How are the wxWindows makefiles edited under Windows?</a></H3>
+<H3><a name="makefiles">How are the wxWidgets makefiles edited under Windows?</a></H3>
-As of wxWindows 2.1, there is a new system written by Vadim Zeitlin, that
+As of wxWidgets 2.1, there is a new system written by Vadim Zeitlin, that
generates the makefiles from templates using tmake.<P>
Here are Vadim's notes:<P>
tmake can be found at
<a href="http://www.troll.no/freebies/tmake.html" target=_new>www.troll.no/freebies/tmake.html</a>.
-It's a Perl5 program and so it needs Perl (doh). There is a binary for
+It's a Perl5 program and so it needs Perl (doh). There is a binary for
Windows (available from the same page), but I haven't used it, so
I don't know if it works as flawlessly as "perl tmake" does (note
for people knowing Perl: don't try to run tmake with -w, it won't
<pre>tmake -t b32 wxwin.pro -o ../../src/msw/makefile.b32</pre><P>
-The makefiles are untested - I don't have any of Borland, Watcom or
+The makefiles are untested - I don't have any of Borland, Watcom or
Symantec and I don't have enough diskspace to recompile even with
VC6 using makefiles. The new makefiles are as close as possible to the
old ones, but not closer: in fact, there has been many strange things
Some other are only compiled with some compilers (others can't compile
them) - all this info is contained in this file.<P>
-So now adding a new file to wxWindows is as easy as modifying filelist.txt
+So now adding a new file to wxWidgets is as easy as modifying filelist.txt
(and Makefile.ams for Unix ports) and regenerating the makefiles - no
need to modify all files manually any more.<P>
one from vc6.t - probably the only things to change would be the
version number in the very beginning and the /Z option - VC5 doesn't
support edit-and=continue). This is not an officially supported way
-of building wxWindows (that is, nobody guarantees that it will work),
+of building wxWidgets (that is, nobody guarantees that it will work),
but it has been very useful to me and I hope it will be also for
-others. To generate wxWi
ndows.dsp run<P>
+others. To generate wxWi
dgets.dsp run<P>
-<pre>tmake -t vc6 wxwin.pro -o ../../wxWi
ndows.dsp</pre><P>
+<pre>tmake -t vc6 wxwin.pro -o ../../wxWi
dgets.dsp</pre><P>
Then just include this project in any workspace or open it from VC IDE
and it will create a new workspace for you.<P>
<P>
-<H3><a name="vcdebug">How do you use VC++'s memory leak checking instead of that in wxWindows?</a></H3>
+<H3><a name="vcdebug">How do you use VC++'s memory leak checking instead of that in wxWidgets?</a></H3>
Vadim Zeitlin:
<pre>
On the VC++ level, it's just the matter of calling _CrtSetDbgFlag() in the very
-beginning of the program. In wxWindows, this is done automatically when
+beginning of the program. In wxWidgets, this is done automatically when
compiling with VC++ in debug mode unless wxUSE_GLOBAL_MEMORY_OPERATORS or
__NO_VC_CRTDBG__ are defined - this check is done in wx/msw/msvcrt.h which
is included from app.cpp which then calls wxCrtSetDbgFlag() without any
supposed to deal with per-user application configuration data, and HKLM is
only supposed to be writeable by a user with Administrator privileges. In theory,
only installers should write to HKLM. This is still a point debated by the
-wxWindows developers. There are at least two ways to work around it if you really
+wxWidgets developers. There are at least two ways to work around it if you really
need to write to HKLM.<P>
First, you can use wxRegKey directly, for example:
regKey.SetName(idName);
{
- wxLogNull dummy;
+ wxLogNull dummy;
if (!regKey.Create())
{
idName = wxT("HKEY_CURRENT_USER\\SOFTWARE\\My Company\\My Product\\Stuff\\");
<P>
-<h3><a name="#dspfmt">Why does Visual C++ complain about corrupted project files??</a></h3>
+<h3><a name="#dspfmt">Why does Visual C++ complain about corrupted project files{/a></h3>
-If you have downloaded the wxWindows sources from the cvs using a Unix cvs
+If you have downloaded the wxWidgets sources from the cvs using a Unix cvs
client or downloaded a daily snapshot in <tt>.tar.gz</tt> format, it is likely
that the project files have Unix line endings (LF) instead of the DOS ones (CR
LF). However all versions of Visual C++ up to and including 7.1 can only open
+
<HTML>
<HEAD>
-<TITLE>wxWindows 2 for X11 FAQ</TITLE>
+<TITLE>wxWidgets 2 for X11 FAQ</TITLE>
</HEAD>
<BODY BGCOLOR=#FFFFFF TEXT=#000000 VLINK="#00376A" LINK="#00529C" ALINK="#313063">
<tr>
<td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif">
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
-<b>wxWindows 2 for X11 FAQ</b>
+<b>wxWidgets 2 for X11 FAQ</b>
</font>
</td>
</tr>
+
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf8">
<meta name="Author" content="Vadim Zeitlin">
- <title>List of translators for wxWindows</title>
+ <title>List of translators for wxWidgets</title>
</head>
<body>
<tr>
<td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif">
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
-<b>wxWindows internationalization</b>
+<b>wxWidgets internationalization</b>
</font>
</td>
</tr>
</center>
<p>
-wxWindows uses a certain number of user-readable strings such as
+wxWidgets uses a certain number of user-readable strings such as
<tt>"help"</tt> or <tt>"Load file"</tt> which should be translated to the
-users language if it is different from English. wxWindows has built in support
+users language if it is different from English. wxWidgets has built in support
for internationalization (i18n from now on) which allows for this to happen
automatically if the translations to the current language are available.
You may find here the list of all existing translations with the addresses of
the official translators whom you should contact if you would like to submit
any corrections to the translations for your language. Also, please
-<a href="#howtohelp">see below</a> if you would like to translate wxWindows to
+<a href="#howtohelp">see below</a> if you would like to translate wxWidgets to
your language if it is not mentioned here (or to help with one which already
is -- it is quite helpful to have several translators for one language at
least for proof reading).
-<hr>
+<hr>
<center>
<font size=+2><i><b><a name="available">Available translations</a></b></i></font>
</center>
<hr>
<p>
-Below is the table containing the list of languages supported by wxWindows.
+Below is the table containing the list of languages supported by wxWidgets.
The columns of this table have the obvious meaning: in each row you will see
the language, the official translator (if any) for it and the status of the
-translations as of wxWindows 2.3.
+translations as of wxWidgets 2.3.
<p>
Please note that email addresses in the table below are intentionally invalid
<table width=100% border=4 cellpadding=5 cellspacing=0>
<tr>
-<td bgcolor="#004080" colspan=3> <font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF"> Languages supported in wxWindows 2.x </font> </td>
+<td bgcolor="#004080" colspan=3> <font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF"> Languages supported in wxWidgets 2.x </font> </td>
</tr>
<tr>
<A HREF="mailto:sparhawk@@aon.at">Gerhard Gruber</A>,
<A HREF="mailto:stefan@@hedemann.de">Stefan Hedemann</A>,
<A HREF="mailto:D.Reymann@@geisenheim.mnd.fh-wiesbaden.de">Dr. Detlev Reymann</A>,
- <A HREF="mailto:">Mark Johnson</A>
+ <A HREF="mailto:">Mark Johnson</A>,
+ <a href="mailto:martinnost@@users.sf.net">Martin Jost</a>
</td>
</tr>
<td valign=center>Russian</td>
<td align=center valign=center><IMG SRC="images/yes.gif" ALT="Done"></td>
<td align=center valign=center><A HREF="mailto:rolinsky@@mema.ucl.ac.be">Roman Rolinsky</A>,
- <A HREF="mailto:vadim@@wxwindows.org">Vadim Zeitlin</A>
+ <A HREF="mailto:vadim@@wxwidgets.org">Vadim Zeitlin</A>
<A HREF="mailto:kai@@cmail.ru">Andrew V. Samoilov</A>
</td>
</tr>
<td valign=center>Spanish</td>
<td align=center valign=center><IMG SRC="images/yes.gif" ALT="Done"></td>
<td align=center valign=center><A HREF="mailto:guille@@iies.es">Guillermo Rodriguez Garcia</A>,
-
<a href="mailto:jsj666@@hotmail.com">JSJ</a></td>
+ <a href="mailto:jsj666@@hotmail.com">JSJ</a></td>
</tr>
<tr>
<br>
-<hr>
+<hr>
<center>
<font size=+2><i><b><a name="howtohelp">How to help</a></b></i></font>
</center>
<hr>
<p>
-wxWindows uses the standard GNU gettext tools for i18n so if you are already
-familiar with them you shouldn't have any problems with working on wxWindows
+wxWidgets uses the standard GNU gettext tools for i18n so if you are already
+familiar with them you shouldn't have any problems with working on wxWidgets
translations. Here are the the steps you should follow:
<ol>
<li>Get the latest version of the file <tt>locale/wxstd.po</tt> from the
- wxWi
ndows source tree: if you're using <a href="cvs.htm">cvs</a>
+ wxWi
dgets source tree: if you're using <a href="cvs.htm">cvs</a>
or the <a href="http://wxwindows.sf.net/snapshots/">daily snapshots</a>,
you should already have it. Otherwise you can always
retrieve it directly from the cvs repository via the Web interface
- <a href="http://cvs.wxwindows.org/viewcvs.cgi/wxWindows/locale/wxstd.po">here</a>.
+ <a href="http://cvs.wxwindows.org/viewcvs.cgi/wxWidgets/locale/wxstd.po">here</a>.
<li>Rename it to <tt>XY.po</tt> where <tt>"XY"</tt> is the 2 letter
<a href="http://lcweb.loc.gov/standards/iso639-2/englangn.html">ISO 639-1 language code</a>
accept the default values for them.
<li>Send the finished translation to
- <a href="mailto:vadim@wxwindows.org">Vadim Zeitlin</a> and it will be
- added to the next wxWindows release or snapshot.
+ <a href="mailto:vadim@wxwidgets.org">Vadim Zeitlin</a> and it will be
+ added to the next wxWidgets release or snapshot.
</ol>
<p>
In addition, please consider subscribing to the very low volume
<a href="http://lists.wxwindows.org/mailman/listinfo/wx-translators">
-wxWindows translators</a> mailing list on which the news especially important
+wxWidgets translators</a> mailing list on which the news especially important
for the translators are announced.
<p>
Thank you in advance for your help!
<hr>
-Please contact <A HREF="mailto:vadim@wxwindows.org">me</A> with
+Please contact <A HREF="mailto:vadim@wxwidgets.org">me</A> with
any comments/suggestions.
</body>
</html>
+
+
You will find below the list of all supported platforms for different ports of
wxWindows 2.x (wxMSW/wxGTK/wxMotif ports only). The cross icon in the third
-column doesn't mean that the platform is not supported, but just that
+column doesn't always mean that the platform is not supported, but may just
wxWindows hasn't been tested on it recently (the table is being updated for
-wxWindows 2.4.0 currently).
+wxWindows 2.5.1 currently).
<p>
See also:
<td bgcolor="#004080" colspan=5> <font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF"> wxWindows 2 Platforms </font> </td>
</tr>
-<tr>
-<td bgcolor="#DEDEDE" align=center valign=top> <font face="Arial, Lucida Sans, Helvetica" color="#000000"> Platform </font> </td>
-<td bgcolor="#DEDEDE" align=center valign=top> <font face="Arial, Lucida Sans, Helvetica" color="#000000"> Compiler </font> </td>
-<td bgcolor="#DEDEDE" align=center valign=top> <font face="Arial, Lucida Sans, Helvetica" color="#000000"> Status </font> </td>
-<td bgcolor="#DEDEDE" align=center valign=top> <font face="Arial, Lucida Sans, Helvetica" color="#000000"> Tested by </font> </td>
-<td bgcolor="#DEDEDE" align=center valign=top> <font face="Arial, Lucida Sans, Helvetica" color="#000000"> Remarks </font> </td>
+<tr bgcolor="#dedede">
+<td align=center valign=top> <font face="Arial, Lucida Sans, Helvetica" color="#000000"> Platform </font> </td>
+<td align=center valign=top> <font face="Arial, Lucida Sans, Helvetica" color="#000000"> Compiler </font> </td>
+<td align=center valign=top> <font face="Arial, Lucida Sans, Helvetica" color="#000000"> Status </font> </td>
+<td align=center valign=top> <font face="Arial, Lucida Sans, Helvetica" color="#000000"> Tested by </font> </td>
+<td align=center valign=top> <font face="Arial, Lucida Sans, Helvetica" color="#000000"> Remarks </font> </td>
</tr>
<tr>
-<td bgcolor="#FFFFFF" align=center valign=center rowspan=8>Win32<br>(Win 9x/NT/2K)</td>
+<td align=center valign=center rowspan=8>Win32<br>(Win 9x/NT/2K)</td>
<td>Visual C++ 4.2/5.x/6.0</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>VZ, JS</td><td>Project files are provided for all versions except 4.2</td>
<tr> <td>Borland C++ 5.0</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td><br></td><td>Also works with free command line Borland C++ 5.5</td>
<tr> <td>Mingw32</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>GRG, VZ</td><td>Cross compilation from Linux works as well<br>
<tr> <td>Digital Mars (was Symantec C++)</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>Chris Elliott</td><td>Tested with 8.34beta</td>
</tr>
+<tr bgcolor="#f0f0f0">
+<td align=center valign=center>Win64<br>(Windows XP/2003)</td>
+ <td>Visual C++ 7.1</td><td align=center><img src="images/no.gif" alt=No></td><td> </td><td>Some minor corrections not done yet but will be in time for 2.6.0...</td>
+</tr>
+
<tr>
-<td bgcolor="#F0F0F0" align=center valign=center rowspan=2>Win16<br>(Windows 3.1)</td>
+<td align=center valign=center rowspan=2>Win16<br>(Windows 3.1)</td>
<td>Visual C++ 1.52</td><td align=center><IMG SRC="images/somewhat.gif" ALT=Ok></td><td><br></td>
<td rowspan=2 valign=center>Some features are missing (OLE related classes, threads, ...)<br>
- Borland C++ can't cope with ODBC, resources and new wxGrid class. <B>Last tested in wxWindows 2.2.7.</B></td>
+ Borland C++ can't cope with ODBC, resources and new wxGrid class.<br>
+ <b>Last working version is wxWindows 2.2.7, support for Win16 has been removed in 2.4.x.</b></td>
<tr> <td>Borland C++ 4.0/5.0</td><td align=center><IMG SRC="images/somewhat.gif" ALT=Ok></td><td>JS</td>
</tr>
-<tr>
-<td bgcolor="#FFFFFF" align=center valign=center rowspan=5>Linux x86</td>
- <td>wxGTK with gcc 2.7.2</td><td align=center><IMG SRC="images/no.gif" ALT=Unknown></td><td><br></td><td>Should work, but nobody uses it any more</td>
-<tr> <td>wxGTK with egcs 1.1.1</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>VZ, RR</td><td><br></td>
-<tr> <td>wxGTK with gcc 2.95</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td><br></td><td><br></td>
-<tr> <td>wxMotif with egcs 1.1.1</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td><br></td><td>with <a href="http://www.lesstif.org">LessTif</a> 0.87</td>
-<tr> <td>wxMotif with gcc 2.95</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td><br></td><td>with <a href="http://www.openmotif.org">OpenMotif</a></td>
+<tr bgcolor="#f0f0f0">
+<td align=center valign=center rowspan=4>Linux x86</td>
+ <td>wxGTK with gcc 2.7.2</td><td align=center><IMG SRC="images/no.gif" ALT=Unknown></td><td><br></td><td>Might work, but nobody uses it any more</td>
+<tr bgcolor="#f0f0f0"> <td>wxGTK with gcc 2.95--3.3</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>VZ, RR</td><td><br></td>
+<tr bgcolor="#f0f0f0"> <td>wxMotif</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td><br></td><td>with <a href="http://www.lesstif.org">LessTif</a> 0.87</td>
+<tr bgcolor="#f0f0f0"> <td>wxMotif</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td><br></td><td>with <a href="http://www.openmotif.org">OpenMotif</a></td>
</tr>
-<tr> <td bgcolor="#fafafa"><br></td><td bgcolor="#fafafa" colspan=5> All BSD systems tests are for wxGTK using gcc. </td>
+<tr> <td bgcolor="#fafafa"><br></td><td bgcolor="#fafafa" align=center colspan=5> All BSD systems tests are for wxGTK using gcc. </td>
<tr>
-<td bgcolor="#F0F0F0" align=center valign=center rowspan=1>FreeBSD</td>
+<td align=center valign=center rowspan=1>FreeBSD</td>
<td>all versions between 3.2 and 5.1 x86</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>VZ</td><td><br></td>
</tr>
<tr>
-<td bgcolor="#FFFFFF" align=center valign=center rowspan=1>NetBSD</td>
+<td align=center valign=center rowspan=1>NetBSD</td>
<td>1.6, Alpha</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>VZ</td><td><br></td>
</tr>
<tr>
-<td bgcolor="#F0F0F0" align=center valign=center rowspan=1>OpenBSD</td>
+<td align=center valign=center rowspan=1>OpenBSD</td>
<td>3.1, Alpha</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>VZ</td><td>Some problems with shared libraries, ok with static ones</td>
</tr>
-<tr>
-<td bgcolor="#FFFFFF" align=center valign=center rowspan=5>Solaris</td>
+<tr bgcolor="#f0f0f0">
+<td align=center valign=center rowspan=6>Solaris</td>
<td>wxMotif with Sun CC 4.2</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>VZ</td><td>Thread support must be disabled on system with not MT-safe X11</td>
-<tr> <td>wxMotif with gcc</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td><br></td><td><br></td>
-<tr> <td>wxGTK with Sun CC 4.2</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td> </td><td><br></td>
-<tr> <td>wxGTK with gcc</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td><br></td><td><br></td>
-<tr> <td>wxGTK with Sun CC 5.0 and 6.1 (Solaris 7 and 8)</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>Jiri Mracek</td><td>You have to edit line 2079 in glib.h to fix GTK+ error</td>
+<tr bgcolor="#f0f0f0"> <td>wxMotif with gcc</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td><br></td><td><br></td>
+<tr bgcolor="#f0f0f0"> <td>wxGTK with Sun CC 4.2</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td> </td><td><br></td>
+<tr bgcolor="#f0f0f0"> <td>wxGTK with gcc</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td><br></td><td><br></td>
+<tr bgcolor="#f0f0f0"> <td>wxGTK with Sun CC 5.0 and 6.1 (Solaris 7 and 8)</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>Jiri Mracek</td><td>You have to edit line 2079 in glib.h to fix GTK+ error</td>
+<tr bgcolor="#f0f0f0"> <td>wxGTK 2.5.1 with Sun CC 6.2 (Solaris 6 and 8)</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>Carl Godkin</td><td>Using GNU make</td>
</tr>
<tr>
-<td bgcolor="#F0F0F0" align=center valign=center rowspan=3>AIX</td>
+<td align=center valign=center rowspan=4>AIX</td>
<td>wxGTK 2.2.9 with gcc 3.0.4</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>Ian Brown</td><td>Shared library building doesn't work, use <tt>--disable-shared</tt></td>
<tr> <td>wxGTK 2.3.3 with xlC (AIX 4.3.2)</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>Irvin Probst</td><td>Both static and shared wxGTK libraries work, but only with static GTK+ and GLib</td>
<tr> <td>wxMotif with xlC 3.1.4.0 (AIX 4.2)</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td>
<td>Bernhard Eck</td>
<td>Some problems with OpenGL and native X server</td>
+<tr> <td>wxX11 2.4.2 with xlC 6 (AIX 5.1)</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>Swengtoo</td><td>In 2.4.2 you need to remove parentheses from the configure line containing AIX_CXX_LD; you should also use GNU make</td>
</tr>
-<tr>
-<td bgcolor="#FFFFFF" align=center valign=center rowspan=2>HP-UX 10.20</td>
+<tr bgcolor="#f0f0f0">
+<td align=center valign=center rowspan=2>HP-UX 10.20</td>
<td>wxGTK with HP CC A.10.22<br>or HP aCC B3910B A.01.18</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>Staf Verhaegen</td>
<td>you need to add <tt>-Aa -D_HPUX_SOURCE</tt> to <tt>CFLAGS</tt></td>
-<tr> <td>wxGTK with gcc</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>Julian Albo Garcia</td><td><br></td>
+<tr
bgcolor="#f0f0f0"> <td>wxGTK with gcc</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>Julian Albo Garcia</td><td><br></td>
</tr>
<tr>
-<td bgcolor="#F0F0F0" align=center valign=center rowspan=6>IRIX</td>
+<td align=center valign=center rowspan=6>IRIX</td>
<tr> <td bgcolor="#fafafa" colspan=5>
Note that all entries use MIPSPro 7.3 compiler on IRIX 6.5.9 with <tt>-mips3 -n32</tt> flags if not mentioned otherwise.
Also note that you need to set <tt>LD_LIBRARYN32_PATH</tt> under IRIX to run wxWindows programs.
<tr> <td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>Ian</td><td><br></td>
</tr>
-<tr>
-<td bgcolor="#FFFFFF" align=center valign=center rowspan=1>SCO UnixWare</td>
+<tr bgcolor="#f0f0f0">
+<td align=center valign=center rowspan=1>SCO UnixWare</td>
<td>wxGTK with gcc</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>William Suetholz</td><td>UnixWare 2.1.3 with UnixWare 7 compatibility PTF</td>
</tr>
<tr>
-<td bgcolor="#F0F0F0" align=center valign=center rowspan=1>DEC OSF/1</td>
+<td align=center valign=center rowspan=1>DEC OSF/1</td>
<td>wxGTK with gcc</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>Fabrice Didierjean</td><td>OSF1 4.0 on Dec Alpha<br>
you may need to run configure with <tt>--host=alpha-dec-osf switch</tt></td>
</tr>
-<tr>
-<td bgcolor="#FFFFFF" align=center valign=center rowspan=4>OS/2</td>
+<tr bgcolor="#f0f0f0">
+<td align=center valign=center rowspan=4>OS/2</td>
<td>VisualAge 3.0/4.0</td><td align=center><IMG SRC="images/no.gif" ALT="Not yet"></td><td>DW</td>
<td rowspan=2 valign=center>OS/2 port is work in progress...</td>
-<tr> <td>EMX</td><td align=center><IMG SRC="images/no.gif" ALT="Not yet"></td><td>SN</td>
-<tr> <td>wxGTK with EMX</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>SN</td><td>configure scripts need to be regenerated with OS/2 port of autoconf</td>
-<tr> <td>wxMotif with EMX</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>SN</td><td>with <a href="http://www.lesstif.org">LessTif</a> 0.89; configure scripts need to be regenerated with OS/2 port of autoconf</td>
+<tr
bgcolor="#f0f0f0"> <td>EMX</td><td align=center><IMG SRC="images/no.gif" ALT="Not yet"></td><td>SN</td>
+<tr
bgcolor="#f0f0f0"> <td>wxGTK with EMX</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>SN</td><td>configure scripts need to be regenerated with OS/2 port of autoconf</td>
+<tr
bgcolor="#f0f0f0"> <td>wxMotif with EMX</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>SN</td><td>with <a href="http://www.lesstif.org">LessTif</a> 0.89; configure scripts need to be regenerated with OS/2 port of autoconf</td>
</tr>
<tr>
-<td bgcolor="#F0F0F0" align=center valign=center rowspan=1>OpenVMS</td>
+<td align=center valign=center rowspan=1>OpenVMS</td>
<td>wxGTK with Compaq-C++ V6.2 (OpenVMS Alpha 7.3)</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>Jouk Jansen</td><td><br></td>
</tr>
-<tr>
-<td bgcolor="#FFFFFF" align=center valign=center rowspan=1>Linux S/390</td>
+<tr bgcolor="#f0f0f0">
+<td align=center valign=center rowspan=1>Linux S/390</td>
<td>wxGTK with gcc 2.95.2</td><td align=center><IMG SRC="images/yes.gif" ALT=Ok></td><td>VZ</td><td>2.3.1+ only</td>
</tr>
+<tr>
+<td align=center valign=center rowspan=4>Mac OS</td>
+ <tr><td>wxMac CFM (OS 8.6+)</td><td align=center><img src="images/yes.gif" alt=Ok></td><td>SC</td><td>with Metrowerks CodeWarrior 8.3</td></tr>
+ <tr><td>wxMac Mach-O (OS X)</td><td align=center><img src="images/yes.gif" alt=Ok></td><td>SC</td><td>CodeWarrior or Apple DevTools (gcc)</td></tr>
+ <tr><td>wxCocoa (OS X)</td><td align=center><img src="images/somewhat.gif" alt="Somewhat"></td><td>DE</td><td>Apple DevTools (gcc)</td></tr>
+</tr>
+
</table>
<br>
\wxheading{Parameters}
-\docparam{henv}{Environment handle used for this connection. See
+\docparam{henv}{Environment handle used for this connection. See\rtfsp
\helpref{wxDConnectInf::AllocHenv}{wxdbconnectinfallochenv} for how to create
an SQL environment handle. NOTE: Passing in a NULL for this parameter will
inform the constructor that it should create its own SQL environment handle.
-If NULL is passed for this parameter, the constructor will call
+If NULL is passed for this parameter, the constructor will call\rtfsp
\helpref{wxDConnectInf::AllocHenv}{wxdbconnectinfallochenv} internally. A
flag is set internally also to indicate that the HENV was created by the
constructor so that when the default class destructor is called, the
-destructor will call \helpref{wxDConnectInf::FreeHenv}{wxdbconnectinffreehenv}
+destructor will call \helpref{wxDConnectInf::FreeHenv}{wxdbconnectinffreehenv}\rtfsp
to free the environment handle automatically.}
\docparam{dsn}{Name of the datasource to be used in creating wxDb instances
for creating connection(s) to a datasource.}
Handles the default destruction of the instance of the class. If the long form
of the \helpref{wxDConnectInf}{wxdbconnectinf} was used, then this destructor
-also takes care of calling
+also takes care of calling\rtfsp
\helpref{wxDConnectInf::FreeHenv}{wxdbconnectinffreehenv} to free the
SQL environment handle.
\wxheading{Remarks}
-If the SQL environment handle was created using the long form of the
+If the SQL environment handle was created using the long form of the\rtfsp
\helpref{wxDbConnectInf}{wxdbconnectinf} constructor, then the flag indicating
that the HENV should be destroyed when the classes destructor is called
-is reset to be false, so that any future handles created using the
+is reset to be false, so that any future handles created using the\rtfsp
\helpref{wxDbConnectInf::AllocHenv}{wxdbconnectinfallochenv} function
must be manually released with a call to this function.
-Announcing wxWindows 2.3.4: a cross-platform GUI toolkit
+Announcing wxWidgets 2.5.1: a cross-platform GUI toolkit
----------------------------------------------------------------
-September 16th, 2002 -- the wxWindows team is pleased to
-announce the release of a development snapshot of the mature
-cross-platform C++ application framework.
+February 24th, 2004 -- the wxWidgets team is pleased to announce
+a development snapshot release of the mature cross-platform C++
+application framework.
The following platforms are supported:
- Windows 95/98/ME, Windows NT, Windows 2000, Windows XP
-- Unix with GTK+ 1.x and 2.0
-- Unix with X11
-- Unix with Motif/Lesstif
-- VMS with GTK+ 1.x
-- MacOS 8.6, 9.x and 10.x
-- OS/2 (alpha)
+- Windows CE (partial port)
+- Linux/Unix/VMS with GTK+ 1.x and 2.0
+- Linux/Unix with X11
+- Linux/Unix with Motif/Lesstif
+- MacOS 9.x and 10.x
+- OS/2
+- MGL (Linux and DOS)
-To get wxWindows, go to the Download page at:
+A non-GUI subset of wxWidgets called wxBase is also supported
+on most of these platforms.
- http://www.wxwindows.org
-
-This is likely to be the last development snapshot in the
-2.3.x series, before the release of the stable 2.4.x series.
+To get wxWidgets, go to the Download page at:
-*** About wxWindows
-
-wxWindows is a comprehensive open-source, multi-platform C++
-GUI framework, that can be used to build commercial and free
-software. It's used by many organisations all over the world,
-including the company that invented the GUI.
+ http://www.wxwindows.org
-For most ports, wxWindows adopts the native look and feel of
+This is a development snapshot, sometimes known as
+an 'unstable' release. Improvements include:
+numerous bug fixes, STL-like container classes,
+improved GTK+ 2 compatibility, new build system,
+improved Unicode compatibility, wxRenderer class,
+shaped frame and dialog windows on Windows and GTK+,
+more efficient UI update processing, print preview
+improvements, wxCrashReport class, OpenWatcom and
+Digital Mars compiler support, and more.
+
+*** About wxWidgets
+
+wxWidgets is a comprehensive open-source, multi-platform C++ GUI
+framework, that can be used to build commercial and free
+software. First released in 1992 under the name wxWindows, it's
+increasingly used by organisations and individuals all over the
+world due to its winning combination of sophistication, wide
+platform coverage, ease of use, unrestrictive licence and
+vibrant user community.
+
+For most ports, wxWidgets adopts the native look and feel of
each platform since it uses the native widget sets. There is also
-a generic widget set, used for the wxX11 port - no other widget set
-is required, giving the potential for embedded use.
+a generic widget set, used for example by the wxX11 port - no
+other widget set is required, giving the potential for embedded
+use.
An extraordinary range of classes is provided - but don't be put
-off by this because most people find wxWindows easier to learn
+off by this because most people find wxWidgets easier to learn
and use than MFC and other frameworks.
As well as comprehensive support for the usual widgets, advanced
and dialogs on all platforms, document/view, OpenGL support,
HTML-based and context-sensitive help, wizards, drag and drop,
a grid class, ODBC support, threads, sockets, container classes,
-and much more. An 1800-page reference manual is provided in HTML,
-MS HTML Help, WinHelp, wxWindows Help and PDF, and there are over
-70 samples and demos.
+a styled text control, and much more. An 1800-page reference manual
+is provided in HTML, MS HTML Help, WinHelp, wxWidgets Help and PDF
+formats, and there are over 80 samples and demos.
-If you're an MFC user, you'll find many wxWindows concepts
+If you're an MFC user, you'll find many wxWidgets concepts
reassuringly familiar, while often clearer and more consistent.
If you're not, you should still find it intuitive from the start.
-wxWindows bindings for several other languages are available,
+wxWidgets bindings for several other languages are available,
including Python, Perl, Basic, Lua, JavaScript and Eiffel.
-If you're considering wxWindows, do check out some of these links:
+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
Have fun!
-Julian Smart and the wxWindows team
-
-=====
-
-A small selection of the comments from the Feedback page:
-
-"wxWindows 2.xx has been an absolute dream; putting together a
-nice interface has been quite easy, and I'm especially pleased
-that I can do most of our development on *nix with confidence
-that only minor issues will have to get cleaned up when we build
-on Windows."
-
-"I use wxWindows as a GUI Toolkit for Python. Its stability,
-flexibility and speed are the base of industrial strength
-cross-platform GUI application design with interpreted languages
-like Python. Porting is child's play. Thanks for this great
-piece of software!"
-
-"Excellent, stable and intuitive API. Very straightforward to
-learn and easy to port Java, X11 and Win32 code to."
-
-"Thanks heaps for the best piece of software I've ever come
-across (wxWindows)."
-
-"I chose wxWindows for a very much Windows-only application
-because of the simplicity of the API compared to MFC and Win32
-GDI programming. Aside from some minor mistakes in the manual
-which confused me for a while, wxWin has been really easy to use
-and increased my productivity immensely compared to using
-another framework."
-
-"wxWindows is a great product. One of its best features, IMHO,
-are all the language bindings. It's very easy to prototype your
-app in wxPython, then convert to a C/C++ app later."
-
-"Porting to wxWindows is easy - I recently ported an MFC project
-at work to wxGTK on Solaris, and changing all the MFC calls to
-wxWindows calls only took a couple of hours for a 2 man-month
-project... I've never had an easier porting experience.
-wxWindows was intentially built to work like MFC to make it easy
-to port, and they most certainly succeeded, with the notable
-exception of OLE support. I ported a several man month project
-in a day or two, and none of it was hard or confusing, it just
-amounted to looking up the equivalent functions in the help. I
-could do the conversion much faster now because I wouldn't have
-to keep glancing at the web page."
-
-"I'd like to take the opportunity and say a big thank you to all
-the wxWin developers and contributors. wxWindows is the best
-piece of software I have been using so far, and I can't believe
-that I haven't discovered it earlier. I never thought that
-cross-platform development could be so easy and simply cool.
-Great stuff :)"
-
-"Just wanted to commend you on wxWindows. As I'm reading the
-code samples (the checklistbox right now), I'm realizing that
-this is so intuitive and so Java-like in some parts of it,
-especially with the way the layout works... Very good work and
-thank you."
-
-"I have used wxWindows in the past very successfully on multiple
-projects, and think it's the bee's knees. Thanks for everything!"
-
-"Well, I'm using wxWindows since 2 days and I'm already in love
-with it :) The sizers saved me from writing a complete layout
-solution myself. Great work! You guys rock!"
-
-"wxWindows is jaw dropping amazing. Community support from the
-mailing list is extraordinary. Are you sure this is free?"
-
-"I love wxWindows. I can program 10 times faster than with MFC,
-and almost everything works the first time. And unlike MFC,
-there are (useful) examples and documentation. Thanks to you
-guys who did all the work to develop this framework. Big kudos."
-
-"ImageLinks now uses the Open Source version of wxWindows for
-all its current GUI development. Doing this ensures that
-everything interfaces cleanly and also makes it easier in the
-long run to add other GUIs along the way because ImageLinks has
-access to all the source code."
+The wxWidgets team
- Welcome to wxWindows/X11 2.3.4
+ Welcome to wxWindows/X11 2.5.1
-You have downloaded version 2.3.4 of the X11 port of
+You have downloaded version 2.5.1 of the X11 port of
the wxWindows 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
#endif /* Win16/32 */
/* Stand-ins for Windows types or OS/2, to avoid #including all of windows.h or os2.h */
-typedef unsigned long WXHWND;
-typedef unsigned long WXHANDLE;
-typedef unsigned long WXHICON;
-typedef unsigned long WXHFONT;
-typedef unsigned long WXHMENU;
-typedef unsigned long WXHPEN;
-typedef unsigned long WXHBRUSH;
-typedef unsigned long WXHPALETTE;
-typedef unsigned long WXHCURSOR;
-typedef unsigned long WXHRGN;
-typedef unsigned long WXHACCEL;
+typedef void * WXHWND;
+typedef void * WXHANDLE;
+typedef void * WXHICON;
+typedef void * WXHFONT;
+typedef void * WXHMENU;
+typedef void * WXHPEN;
+typedef void * WXHBRUSH;
+typedef void * WXHPALETTE;
+typedef void * WXHCURSOR;
+typedef void * WXHRGN;
+typedef void * WXHACCEL;
typedef void WXFAR * WXHINSTANCE;
-typedef unsigned long WXHBITMAP;
-typedef unsigned long WXHIMAGELIST;
-typedef unsigned long WXHGLOBAL;
-typedef unsigned long WXHDC;
+typedef void * WXHBITMAP;
+typedef void * WXHIMAGELIST;
+typedef void * WXHGLOBAL;
+typedef void * WXHDC;
typedef unsigned int WXUINT;
typedef unsigned long WXDWORD;
typedef unsigned short WXWORD;
typedef unsigned long WXCOLORREF;
typedef void * WXRGNDATA;
typedef void * WXMSG;
-typedef unsigned long WXHCONV;
-typedef unsigned long WXHKEY;
-typedef unsigned long WXHTREEITEM;
+typedef void * WXHCONV;
+typedef void * WXHKEY;
+typedef void * WXHTREEITEM;
typedef void * WXDRAWITEMSTRUCT;
typedef void * WXMEASUREITEMSTRUCT;
#ifdef __WXMSW__
+
+#ifdef __WIN64__
+typedef unsigned __int64 WXWPARAM;
+typedef __int64 WXLPARAM;
+typedef __int64 WXLRESULT;
+#else
typedef unsigned int WXWPARAM;
typedef long WXLPARAM;
+typedef long WXLRESULT;
+#endif
#if !defined(__WIN32__) || defined(__GNUWIN32__) || defined(__WXMICROWIN__)
typedef int (*WXFARPROC)();
// we need to return a special WM_GETDLGCODE value to process just the
// arrows but let the other navigation characters through
#ifdef __WXMSW__
- virtual long MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
+ virtual WXLRESULT MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
#endif // __WXMSW__
private:
// implementation from now on
virtual void Command(wxCommandEvent& event);
- virtual long MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
+ virtual WXLRESULT MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
virtual bool MSWCommand(WXUINT param, WXWORD id);
#ifdef __WIN32__
// MSW only
virtual bool MSWCommand(WXUINT param, WXWORD id);
- long MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
+ WXLRESULT MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
virtual WXHBRUSH OnCtlColor(WXHDC pDC, WXHWND pWnd, WXUINT nCtlColor,
WXUINT message, WXWPARAM wParam, WXLPARAM lParam);
// implementation only from now on
virtual bool MSWCommand(WXUINT param, WXWORD id);
bool MSWProcessEditMsg(WXUINT msg, WXWPARAM wParam, WXLPARAM lParam);
- virtual long MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
+ virtual WXLRESULT MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
virtual WXHBRUSH OnCtlColor(WXHDC pDC, WXHWND pWnd, WXUINT nCtlColor,
WXUINT message, WXWPARAM wParam, WXLPARAM lParam);
void OnSysColourChanged(wxSysColourChangedEvent& event);
// Windows callbacks
- long MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam);
+ WXLRESULT MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam);
#if wxUSE_CTL3D
virtual WXHBRUSH OnCtlColor(WXHDC pDC, WXHWND pWnd, WXUINT nCtlColor,
bool MSWTranslateMessage(WXMSG* pMsg);
// window proc for the frames
- long MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam);
+ WXLRESULT MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam);
// handle WM_INITMENUPOPUP message
bool HandleInitMenuPopup(WXHMENU hMenu);
bool HandleCommand(WXWORD id, WXWORD cmd, WXHWND control);
// override window proc for MDI-specific message processing
- virtual long MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
+ virtual WXLRESULT MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
- virtual long MSWDefWindowProc(WXUINT, WXWPARAM, WXLPARAM);
+ virtual WXLRESULT MSWDefWindowProc(WXUINT, WXWPARAM, WXLPARAM);
virtual bool MSWTranslateMessage(WXMSG* msg);
protected:
bool HandleCommand(WXWORD id, WXWORD cmd, WXHWND control);
bool HandleGetMinMaxInfo(void *mmInfo);
- virtual long MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam);
- virtual long MSWDefWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam);
+ virtual WXLRESULT MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam);
+ virtual WXLRESULT MSWDefWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam);
virtual bool MSWTranslateMessage(WXMSG *msg);
virtual void MSWDestroyWindow();
// override WndProc.
#if wxUSE_UXTHEME
- virtual long MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
+ virtual WXLRESULT MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
#endif
// the current selection (-1 if none)
virtual bool SetFont(const wxFont& font);
- long MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
+ WXLRESULT MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
virtual WXHBRUSH OnCtlColor(WXHDC pDC, WXHWND pWnd, WXUINT nCtlColor,
WXUINT message,
WXWPARAM wParam, WXLPARAM lParam);
#ifdef __WIN16__
virtual bool MSWOnDraw(WXDRAWITEMSTRUCT *item);
#endif // __WIN16__
- virtual long MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
+ virtual WXLRESULT MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
protected:
virtual wxBorder GetDefaultBorder() const;
// implementation from now on
// --------------------------
- virtual long MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
+ virtual WXLRESULT MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
// overriden base class virtuals
virtual bool AcceptsFocus() const { return FALSE; }
virtual wxToolBarToolBase *CreateTool(wxControl *control);
// override WndProc mainly to process WM_SIZE
- virtual long MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
+ virtual WXLRESULT MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
// return the appropriate size and flags for the toolbar control
virtual wxSize DoGetBestSize() const;
void Init();
// intercept WM_GETDLGCODE
- virtual long MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
+ virtual WXLRESULT MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
// call this to increase the size limit (will do nothing if the current
// limit is big enough)
// implementation
// --------------
- virtual long MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
+ virtual WXLRESULT MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
virtual bool MSWCommand(WXUINT param, WXWORD id);
virtual bool MSWOnNotify(int idCtrl, WXLPARAM lParam, WXLPARAM *result);
virtual wxToolBarToolBase *CreateTool(wxControl *control);
// override WndProc mainly to process WM_SIZE
- virtual long MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
+ virtual WXLRESULT MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
// return the appropriate size and flags for the toolbar control
virtual wxSize DoGetBestSize() const;
bool HandleSetCursor(WXHWND hWnd, short nHitTest, int mouseMsg);
// Window procedure
- virtual long MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
+ virtual WXLRESULT MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
// Calls an appropriate default window procedure
- virtual long MSWDefWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
+ virtual WXLRESULT MSWDefWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
// message processing helpers
// Manifest file for Windows XP
//
+#if !defined(__WIN64__)
#if !defined(wxUSE_NO_MANIFEST) || (wxUSE_NO_MANIFEST == 0)
1 24 "wx/msw/wx.manifest"
#endif
+#endif
#ifdef __WXMSW__
// override MSWWindowProc() to process WM_NCHITTEST
- long MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam);
+ WXLRESULT MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam);
#endif // __WXMSW__
private:
}
#ifdef __WXMSW__
-long
+WXLRESULT
wxGenericScrolledWindow::MSWWindowProc(WXUINT nMsg,
WXWPARAM wParam,
WXLPARAM lParam)
{
- long rc = wxPanel::MSWWindowProc(nMsg, wParam, lParam);
+ WXLRESULT rc = wxPanel::MSWWindowProc(nMsg, wParam, lParam);
#ifndef __WXWINCE__
// we need to process arrows ourselves for scrolling
return processed;
}
-long wxButton::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
+WXLRESULT wxButton::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
{
// when we receive focus, we want to temporary become the default button in
// our parent panel so that pressing "Enter" would activate us -- and when
int wxChoice::DoAppend(const wxString& item)
{
- int n = (int)SendMessage(GetHwnd(), CB_ADDSTRING, 0, (LONG)item.c_str());
+ int n = (int)SendMessage(GetHwnd(), CB_ADDSTRING, 0, (LPARAM)item.c_str());
if ( n == CB_ERR )
{
wxLogLastError(wxT("SendMessage(CB_ADDSTRING)"));
wxCHECK_MSG(!(GetWindowStyle() & wxCB_SORT), -1, wxT("can't insert into sorted list"));
wxCHECK_MSG((pos>=0) && (pos<=GetCount()), -1, wxT("invalid index"));
- int n = (int)SendMessage(GetHwnd(), CB_INSERTSTRING, pos, (LONG)item.c_str());
+ int n = (int)SendMessage(GetHwnd(), CB_INSERTSTRING, pos, (LPARAM)item.c_str());
if ( n == CB_ERR )
{
wxLogLastError(wxT("SendMessage(CB_INSERTSTRING)"));
return wxSize(wChoice, GetCharHeight() + 5);
}
-long wxChoice::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
+WXLRESULT wxChoice::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
{
if ( nMsg == WM_LBUTTONUP )
{
// wxComboBox callbacks
// ----------------------------------------------------------------------------
-long wxComboBox::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
+WXLRESULT wxComboBox::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
{
// handle WM_CTLCOLOR messages from our EDIT control to be able to set its
// colour correctly (to be the same as our own one)
WXHWND hwnd;
UnpackCtlColor(wParam, lParam, &nCtlColor, &hdc, &hwnd);
- return OnCtlColor(hdc, hwnd, nCtlColor, nMsg, wParam, lParam);
+ return (WXLRESULT)OnCtlColor(hdc, hwnd, nCtlColor, nMsg, wParam, lParam);
}
return wxChoice::MSWWindowProc(nMsg, wParam, lParam);
// dialog window proc
// ---------------------------------------------------------------------------
-long wxDialog::MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam)
+WXLRESULT wxDialog::MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam)
{
- long rc = 0;
+ WXLRESULT rc = 0;
bool processed = FALSE;
switch ( message )
// the window proc for wxFrame
// ---------------------------------------------------------------------------
-long wxFrame::MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam)
+WXLRESULT wxFrame::MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam)
{
- long rc = 0;
+ WXLRESULT rc = 0;
bool processed = FALSE;
switch ( message )
// the MDI parent frame window proc
// ---------------------------------------------------------------------------
-long wxMDIParentFrame::MSWWindowProc(WXUINT message,
+WXLRESULT wxMDIParentFrame::MSWWindowProc(WXUINT message,
WXWPARAM wParam,
WXLPARAM lParam)
{
- long rc = 0;
+ WXLRESULT rc = 0;
bool processed = false;
switch ( message )
return false;
}
-long wxMDIParentFrame::MSWDefWindowProc(WXUINT message,
+WXLRESULT wxMDIParentFrame::MSWDefWindowProc(WXUINT message,
WXWPARAM wParam,
WXLPARAM lParam)
{
// MDI window proc and message handlers
// ---------------------------------------------------------------------------
-long wxMDIChildFrame::MSWWindowProc(WXUINT message,
+WXLRESULT wxMDIChildFrame::MSWWindowProc(WXUINT message,
WXWPARAM wParam,
WXLPARAM lParam)
{
- long rc = 0;
+ WXLRESULT rc = 0;
bool processed = false;
switch ( message )
// MDI specific message translation/preprocessing
// ---------------------------------------------------------------------------
-long wxMDIChildFrame::MSWDefWindowProc(WXUINT message, WXUINT wParam, WXLPARAM lParam)
+WXLRESULT wxMDIChildFrame::MSWDefWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam)
{
return DefMDIChildProc(GetHwnd(),
(UINT)message, (WPARAM)wParam, (LPARAM)lParam);
}
#if wxUSE_UXTHEME
-long wxNotebook::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
+WXLRESULT wxNotebook::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
{
static bool g_TestedForTheme = false;
static bool g_supportsThemes = false;
// our window proc
// ----------------------------------------------------------------------------
-long wxRadioBox::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
+WXLRESULT wxRadioBox::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
{
switch ( nMsg )
{
wxBrush *brush = wxTheBrushList->FindOrCreateBrush(colBack, wxSOLID);
- return (WXHBRUSH)brush->GetResourceHandle();
+ return (WXLRESULT)brush->GetResourceHandle();
}
#endif // Win32
case WM_SETFOCUS:
// if the focus comes from the spin control itself, don't set it
// back to it -- we don't want to go into an infinite loop
- if ( wParam == spin->GetHWND() )
+ if ( (WXHWND)wParam == spin->GetHWND() )
break;
//else: fall through
#endif // Win16
// We need this or the control can never be moved e.g. in Dialog Editor.
-long wxStaticBitmap::MSWWindowProc(WXUINT nMsg,
+WXLRESULT wxStaticBitmap::MSWWindowProc(WXUINT nMsg,
WXWPARAM wParam,
WXLPARAM lParam)
{
return wxSize(wBox, hBox);
}
-long wxStaticBox::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
+WXLRESULT wxStaticBox::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
{
switch ( nMsg )
{
}
}
-long wxToolBar::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
+WXLRESULT wxToolBar::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
{
switch ( nMsg )
{
event.Skip();
}
-long wxTextCtrl::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
+WXLRESULT wxTextCtrl::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
{
- long lRc = wxTextCtrlBase::MSWWindowProc(nMsg, wParam, lParam);
+ WXLRESULT lRc = wxTextCtrlBase::MSWWindowProc(nMsg, wParam, lParam);
if ( nMsg == WM_GETDLGCODE )
{
// only do it during dragging, minimize wxWin overhead (this is important for
// WM_MOUSEMOVE as they're a lot of them) by catching Windows messages directly
// instead of passing by wxWin events
-long wxTreeCtrl::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
+WXLRESULT wxTreeCtrl::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
{
bool processed = false;
- long rc = 0;
+ WXLRESULT rc = 0;
bool isMultiple = (GetWindowStyle() & wxTR_MULTIPLE) != 0;
if ( (nMsg >= WM_MOUSEFIRST) && (nMsg <= WM_MOUSELAST) )
}
}
-long wxToolBar::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
+WXLRESULT wxToolBar::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
{
#if 0
switch ( nMsg )
// pre/post message processing
// ===========================================================================
-long wxWindowMSW::MSWDefWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
+WXLRESULT wxWindowMSW::MSWDefWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
{
if ( m_oldWndProc )
return ::CallWindowProc(CASTWNDPROC m_oldWndProc, GetHwnd(), (UINT) nMsg, (WPARAM) wParam, (LPARAM) lParam);
return rc;
}
-long wxWindowMSW::MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam)
+WXLRESULT wxWindowMSW::MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam)
{
// did we process the message?
bool processed = false;
union
{
bool allow;
- long result;
+ WXLRESULT result;
WXHICON hIcon;
WXHBRUSH hBrush;
} rc;
// we could have got an event from our child, reflect it back
// to it if this is the case
wxWindowMSW *win = NULL;
- if ( wParam != m_hWnd )
+ if ( (WXHWND)wParam != m_hWnd )
{
win = FindItemByHWND((WXHWND)wParam);
}
#include "wx/msw/private.h"
-long wxWindow::MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam)
+WXLRESULT wxWindow::MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam)
{
if ( message == WM_NCHITTEST )
{
// wxLogTrace(wxT("msg sent"));
}
-long wxActiveX::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
+WXLRESULT wxActiveX::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
{
if (m_oleObjectHWND == NULL)
return wxWindow::MSWWindowProc(nMsg, wParam, lParam);
FuncXArray m_events;
MemberIdList m_eventsIdx;
- long MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
+ WXLRESULT MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
};
// events
projects / wxWidgets.git / commitdiff
