For further information, please see the -wxWindows Web site, -wxWiki +wxWidgets Web site, +wxWiki and install.txt (per port), todo.txt (per port), and bugs.txt (all ports) files -in your wxWindows installation. +in your wxWidgets installation.
diff --git a/docs/html/faqgen.htm b/docs/html/faqgen.htm index a0de58ca37..43d44423d5 100644 --- a/docs/html/faqgen.htm +++ b/docs/html/faqgen.htm @@ -2,7 +2,7 @@
-List of questions in this category
-
-
- What is wxWindows? -
- Can I use wxWindows 2 for both proprietary projects, and GPL'ed projects? +
- What is wxWidgets? +
- Can I use wxWidgets 2 for both proprietary projects, and GPL'ed projects?
- Is there support? -
- Who uses wxWindows? -
- What platforms are supported by wxWindows? -
- How does wxWindows support platform-specific features? -
- Does wxWindows use STL? or the standard string class? -
- Is there a rich edit/markup widget for wxWindows? -
- How to use C++ exceptions with wxWindows? -
- How is wxWindows being developed? -
- How is wxWindows distributed? +
- Who uses wxWidgets? +
- What platforms are supported by wxWidgets? +
- How does wxWidgets support platform-specific features? +
- Does wxWidgets use STL? or the standard string class? +
- Is there a rich edit/markup widget for wxWidgets? +
- How to use C++ exceptions with wxWidgets? +
- How is wxWidgets being developed? +
- How is wxWidgets distributed?
- What are the plans for the future?
- What is wxBase?
- What is wxUniversal? @@ -45,10 +45,10 @@ See also top-level FAQ page.
-
What is wxWindows?
+What is wxWidgets?
-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.Although GUI applications are mostly built programmatically, there are several dialog editors to help @@ -56,32 +56,32 @@ build attractive dialogs and panels. Robert Roebling's DialogBlocks are two commercial examples, but there are others: see the Useful Tools page.
-You don't have to use C++ to use wxWindows: there is a Python interface for wxWindows 2, +You don't have to use C++ to use wxWidgets: there is a Python interface for wxWidgets 2, and also a Perl interface.
-
Can I use wxWindows 2 for both proprietary (commercial) projects, and GPL'ed projects?
+Can I use wxWidgets 2 for both proprietary (commercial) projects, and GPL'ed projects?
Yes. Please see the licence 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.-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.
Is there support?
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.-
Who uses wxWindows?
+Who uses wxWidgets?
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.@@ -91,7 +91,7 @@ Our highest-profile user yet is industry veteran and Lotus Corp. founder Mitch K and his Open Source Applications Foundation.
-
What platforms are supported by wxWindows 2?
+What platforms are supported by wxWidgets 2?
- Windows 3.1, Windows 95/98, Windows NT, Windows 2000, Windows ME.
@@ -99,20 +99,20 @@ and his Open Source Applicati
- Unix with Motif or the free Motif clone Lesstif.
- Mac OS.
- Embedded platforms are being investigated. See the wxUniversal project. -
- An OS/2 port is in progress, and you can also compile wxWindows for GTK+ or Motif +
- An OS/2 port is in progress, and you can also compile wxWidgets for GTK+ or Motif on OS/2.
-
How does wxWindows 2 support platform-specific
+How does wxWidgets 2 support platform-specific
features?
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
@@ -120,29 +120,29 @@ as the MDI classes, have been emulated on other platforms. I can imagine
that even wxTaskBarIcon may be implemented for Unix desktops one day.
-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.
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.
-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.
-
Does wxWindows use STL? or the standard string class?
+Does wxWidgets use STL? or the standard string class?
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
-wxWindows 2 is strenously trying to avoid.
+wxWidgets 2 is strenously trying to avoid.
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
@@ -150,7 +150,7 @@ by being able to modify our own string class. Some compatibility with the string
has been built into wxString.
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:
@@ -163,41 +163,41 @@ or by adding this to a header before you include any STL files:
-
Is there a rich edit/markup widget for wxWindows 2?
+Is there a rich edit/markup widget for wxWidgets 2?
These are the possibilities so far:
- See www.scintilla.org 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.
- 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.
- 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).
-
How to use C++ exceptions with wxWindows?
+How to use C++ exceptions with wxWidgets?
-wxWindows library itself is unfortunately not exception-safe (as its
+wxWidgets library itself is unfortunately not 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.
There are a few issues to keep in mind, though:
- - You shouldn't let the exceptions propagate through wxWindows code,
+
- 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.
- 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
@@ -208,18 +208,18 @@ There are a few issues to keep in mind, though:
-
How is wxWindows being developed?
+How is wxWidgets being developed?
-We are using the CVS system to develop and maintain wxWindows. This allows
+We are using the CVS 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.
-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.
-
How is wxWindows distributed?
+How is wxWidgets distributed?
-By ftp, and via the wxWindows CD-ROM.
+By ftp, and via the wxWidgets CD-ROM.
If you are feeling adventurous, you may also check out the sources directly
from cvs.
@@ -227,40 +227,40 @@ from cvs.
What are the plans for the future?
-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.
-Other possibilities include: DCOM/CORBA compatibility; a wxWindows book;
+Other possibilities include: DCOM/CORBA compatibility; a wxWidgets book;
wxWorkshop, an IDE;
other platforms, especially embedded systems; other interface abilities such as speech output.
-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.
-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!
What is wxBase?
-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).
What is wxUniversal?
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.
You may find more about wxUniversal here.
@@ -269,7 +269,7 @@ You may find more about wxUniversal here.
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 wxWindows is as high as ever.
+from Java, and the level of interest in wxWidgets is as high as ever.
What about .NET/Mono?
@@ -281,27 +281,27 @@ garbage collection and various other Java-like language features.
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.
- Not everyone wants or needs net services.
- C++ will be used for a long time to come; compared with C++, C# is a recent development and its future is not certain.
- 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).
- C# is usually byte-compiled and therefore slower. Plus, .NET adds a layer of overhead to the client computer
-that wxWindows does not require.
-
- 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.
+
- Mono hasn't proven its long-term viability yet (it's a complex system of components); wxWidgets is ready now.
- You may not wish to buy into Microsoft marketing spin and APIs.
- Microsoft may at some point sue developers of non-Microsoft .NET implementations. After all,
platform-independence is not in Microsoft's interest.
- .NET might never be implemented on some platforms, especially Mac and embedded variants of Linux.
-
- wxPython and other language variants provide further reasons for wxWindows to continue.
+
- wxPython and other language variants provide further reasons for wxWidgets to continue.
- 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!)
-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 wx.NET project is now in progress.
diff --git a/docs/html/faqgtk.htm b/docs/html/faqgtk.htm
index 320dbebde8..cc4b3748e6 100644
--- a/docs/html/faqgtk.htm
+++ b/docs/html/faqgtk.htm
@@ -1,7 +1,8 @@
+
-wxWindows 2 for GTK FAQ
+wxWidgets 2 for GTK FAQ
@@ -12,7 +13,7 @@
-wxWindows 2 for GTK FAQ
+wxWidgets 2 for GTK FAQ
@@ -20,14 +21,14 @@
-See also top-level FAQ page
+See also top-level FAQ page
and Unix FAQ page.
List of questions in this category
-- What is wxWindows 2 for GTK+?
-- Why doesn't reading floating point numbers work when using wxWindows?
+- What is wxWidgets 2 for GTK+?
+- Why doesn't reading floating point numbers work when using wxWidgets?
- Does wxGTK have GNOME support?
- Warning about GTK libraries supplied with RedHat
- What range of Intel Linux platforms will a given application binary be usable on?
@@ -38,14 +39,14 @@ and Unix FAQ page.
-What is wxWindows 2 for GTK?
+What is wxWidgets 2 for GTK?
-wxWindows 2 for GTK is a port of wxWindows to the GTK+ toolkit,
-which is freely available for most flavours of Unix with X. wxWindows 2 for GTK is
+wxWidgets 2 for GTK is a port of wxWidgets to the GTK+ toolkit,
+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 here.
-
Why doesn't reading floating point numbers work when using wxWindows?
+Why doesn't reading floating point numbers work when using wxWidgets?
If your program reads the floating point numbers in the format 123.45
from a file, it may suddently start returning just 123 instead of the
@@ -75,7 +76,7 @@ future, probably as a separate library.
Warning about GTK+ libraries supplied with RedHat
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.
diff --git a/docs/html/faqmac.htm b/docs/html/faqmac.htm
index 4896e7e599..3e7f255569 100644
--- a/docs/html/faqmac.htm
+++ b/docs/html/faqmac.htm
@@ -2,7 +2,7 @@
-wxWindows 2 for Mac FAQ
+wxWidgets 2 for Mac FAQ
@@ -13,7 +13,7 @@
-wxWindows 2 for Mac FAQ
+wxWidgets 2 for Mac FAQ
@@ -38,7 +38,7 @@ See also top-level FAQ page.
- What are the smart preprocessing errors with the Apple Developer Tools?
- How does wxMac support the standard Apple About menu item and Help menu?
- How do I add an icon to my application?
-- How can I easily switch between different versions of wxWindows in CodeWarrior?
+- How can I easily switch between different versions of wxWidgets in CodeWarrior?
@@ -54,15 +54,15 @@ The author of this port is Stefan Cs
Which Mac platforms are supported?
-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.
-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.
How is the Mac OS X port different from the Classic Mac OS port?
-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.
This hybrid approach was suggested by Apple to the Fizzilla team working on Mozilla for Mac OS X.
@@ -87,7 +87,7 @@ Under Mac OS X, the Developer Tools are sufficient to build wxMac. CodeWarrior P
How does CVS handle file types/creators under Mac OS 8.x/9.x?
-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 xpm and xbm 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 xpm and xbm images correctly:
- bring up the Internet control panel, select the Advanced Options tab, click on the File Mapping icon from the list at the left and see if there are is an entry for ".xpm" files and another for ".xbm".
- if an entry exists, click Change... and make sure File Type is
TEXT (just those four capital letters); correct it if necessary. If there is no entry, make one with type set to TEXT and creator set to anything you like; reasonable choices include GKON (Graphic Converter) or CWIE (CodeWarrior).
@@ -101,8 +101,8 @@ The Mac OS X CVS client does not handle file types and creators at all (just lik
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:
-- decode and decompress the file
wxWindows/docs/mac/TypeAsMetrowerksText.sea.hqx
- - drag the wxWindows CVS sandbox directory onto the autotyper and most of the files will be typed according to the file extension
+
- decode and decompress the file
wxWidgets/docs/mac/TypeAsMetrowerksText.sea.hqx
+ - drag the wxWidgets CVS sandbox directory onto the autotyper and most of the files will be typed according to the file extension
@@ -125,11 +125,11 @@ This is also necessary even if you don'want to build the Carbon targets.
Build the projects (makemac6.mcp for CodeWarrior Pro 6; makemac.mpc for CodeWarrior Pro 5) in the following five directories:
-- wxWindows:src:
-
- wxWindows:src:jpeg:
-
- wxWindows:src:png:
-
- wxWindows:src:tiff:
-
- wxWindows:src:zlib:
+
- wxWidgets:src:
+
- wxWidgets:src:jpeg:
+
- wxWidgets:src:png:
+
- wxWidgets:src:tiff:
+
- wxWidgets:src:zlib:
@@ -139,8 +139,8 @@ You need to have the Apple Developer Tools installed. The Developer Tools CD is
Building wxMac completely without configure is not supported.
-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:
mkdir macbuild
cd macbuild
@@ -197,12 +197,12 @@ This error can sometimes be corrected or avoided by modifying the source code. H
How does wxMac support the standard Apple About menu item and Help menu?
-Because wxWindows does not have a specific API for the About menu item or the Help 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 About menu item or the Help menu, the Mac OS port uses some static variables to help the engine make the right decisions:
- It assumes that the About menu item is part of a Help menu.
- The title of the Help menu is stored in
wxApp::s_macHelpMenuTitleName, it defaults to "&Help", but you can change it in your constructor to your specific menu title.
- The item Id of the About menu is stored in
wxApp::s_macAboutMenuItemID, it defaults to wxID_ABOUT, but can be changed as well to suit your needs.
- - The other items of the wxWindows help menu are appended to the Mac OS Help menu and the translation of Ids is handled transparently for your application.
+
- The other items of the wxWidgets help menu are appended to the Mac OS Help menu and the translation of Ids is handled transparently for your application.
@@ -215,10 +215,10 @@ your project and in the CodeWarrior Settings add a check mark under Linker:Outpu
Flags/Finder Flags/Has Custom Icon.
-
How can I easily switch between different versions of wxWindows in CodeWarrior?
+How can I easily switch between different versions of wxWidgets in CodeWarrior?
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.
Under Edit-Preferences in General:Source Trees, type a name (for example WXWIN)
diff --git a/docs/html/faqmot.htm b/docs/html/faqmot.htm
index 609f6b70cc..6a7fdd83eb 100644
--- a/docs/html/faqmot.htm
+++ b/docs/html/faqmot.htm
@@ -1,7 +1,8 @@
+
-wxWindows 2 for Motif FAQ
+wxWidgets 2 for Motif FAQ
@@ -12,7 +13,7 @@
-wxWindows 2 for Motif FAQ
+wxWidgets 2 for Motif FAQ
@@ -27,7 +28,7 @@ and Unix FAQ page.
- What version of Motif do I need?
- What features are missing or partially implemented?
-- Does Dialog Editor work with wxWindows for Motif?
+- Does Dialog Editor work with wxWidgets for Motif?
- Why are windows are not refreshed properly until I resize them?
@@ -62,7 +63,7 @@ system is in preparation.
-
Does Dialog Editor work with wxWindows for Motif?
+Does Dialog Editor work with wxWidgets for Motif?
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.
diff --git a/docs/html/faqmsw.htm b/docs/html/faqmsw.htm
index 79b0ce996f..aa0dcbe3cb 100644
--- a/docs/html/faqmsw.htm
+++ b/docs/html/faqmsw.htm
@@ -1,7 +1,8 @@
+
-wxWindows 2 for Windows FAQ
+wxWidgets 2 for Windows FAQ
@@ -12,7 +13,7 @@
-wxWindows 2 for Windows FAQ
+wxWidgets 2 for Windows FAQ
@@ -28,33 +29,33 @@ See also top-level FAQ page.
- What about Windows CE?
- What do I need to do for Windows XP?
- What compilers are supported?
-- Which is the best compiler to use with wxWindows 2?
+- Which is the best compiler to use with wxWidgets 2?
- Is Unicode supported?
-- Does wxWindows support double byte fonts (Chinese/Japanese/Korean etc.)?
-- Can you compile wxWindows 2 as a DLL?
+- Does wxWidgets support double byte fonts (Chinese/Japanese/Korean etc.)?
+- Can you compile wxWidgets 2 as a DLL?
- How can I reduce executable size?
-- Is wxWindows compatible with MFC?
+- Is wxWidgets compatible with MFC?
- Why do I get errors about setup.h not being found?
- Why do I get errors about FooBarA when I only use FooBar in my program?
- Why my code fails to compile with strange errors about new operator?
-- How do I port MFC applications to wxWindows?
+- How do I port MFC applications to wxWidgets?
- Why do I sometimes get bizarre crash problems using VC++ 5/6?
-- How are the wxWindows makefiles edited under Windows?
-- How do you use VC++'s memory leak checking instead of that in wxWindows?
+- How are the wxWidgets makefiles edited under Windows?
+- How do you use VC++'s memory leak checking instead of that in wxWidgets?
- Why are menu hotkeys or shortcuts not working in my application?
- Why can I not write to the HKLM part of the registry with wxRegConfig?
- Is MS Active Accessibility supported?
-- Why does Visual C++ complain about corrupted project files??
+- Why does Visual C++ complain about corrupted project files{/a>
Which Windows platforms are supported?
-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).
-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
@@ -64,12 +65,12 @@ makefiles to see what other files have been left out.
16-bit compilation is supported under Visual C++ 1.5, and Borland BC++ 4 to 5.
-wxWindows 2 for Windows will also compile on Unix with gcc using Wine from WineHQ.
+wxWidgets 2 for Windows will also compile on Unix with gcc using Wine from WineHQ.
The resulting executables are Unix binaries that work with the Wine Windows API emulator.
-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.
@@ -116,7 +117,7 @@ line:
1 24 "winxp.manifest"
-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.
@@ -127,7 +128,7 @@ article
.
What compilers are supported?
-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:
@@ -143,18 +144,18 @@ currently the following are known to work:
-
Which is the best compiler to use with wxWindows 2?
+Which is the best compiler to use with wxWidgets 2?
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 wxWindows samples.
+for wxWidgets samples.
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.
-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).
You can't beat Cygwin's price (free), and you can debug adequately using gdb. However, it's
@@ -167,7 +168,7 @@ Watcom C++ is a little slow and the debugger is not really up to today's sta
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.
Is Unicode supported?
@@ -176,32 +177,32 @@ support for it under Windows 9x using MSLU.
-
Does wxWindows support double byte fonts (Chinese/Japanese/Korean etc.)?
+Does wxWidgets support double byte fonts (Chinese/Japanese/Korean etc.)?
-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
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage=932
(default is 1252 for Western). Then you can see all the Japanese letters in
-wxWindows applications.
+wxWidgets applications.
-
Can you compile wxWindows 2 as a DLL?
+Can you compile wxWidgets 2 as a DLL?
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.
-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!
How can I reduce executable size?
-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.
@@ -214,27 +215,27 @@ use DLLs. Another good compression tool (probably better than Petite) is
+for the enormous increase in productivity you get with wxWidgets is almost always well worth it.
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.
-
Is wxWindows compatible with MFC?
+Is wxWidgets compatible with MFC?
-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.
Why do I get errors about setup.h not being found?
-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:
@@ -276,16 +277,16 @@ The most common cause of this problem is the memory debugging settings in
setting wxUSE_GLOBAL_MEMORY_OPERATORS and
wxUSE_DEBUG_NEW_ALWAYS to 0 in this file
- Or leave them on but do #undef new 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
Notice that IMHO the first solution is preferable for VC++ users who can use
the VC++ CRT memory debugging features instead.
-How do I port MFC applications to wxWindows?
+How do I port MFC applications to wxWidgets?
-Set up your interface from scratch using wxWindows (especially wxDesigner
+Set up your interface from scratch using wxWidgets (especially wxDesigner
or DialogBlocks --
it'll save you a lot of time) and when you have a shell prepared, you can start
'pouring in' code from the MFC app, with appropriate
@@ -293,14 +294,14 @@ modifications. This is the approach I have used, and I found
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.
Why do I sometimes get bizarre crash problems using VC++ 5/6?
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
@@ -313,13 +314,13 @@ Editor, in Release mode with optimizations on. If in doubt,
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.
-
How are the wxWindows makefiles edited under Windows?
+How are the wxWidgets makefiles edited under Windows?
-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.
Here are Vadim's notes:
@@ -334,7 +335,7 @@ example) and regenerate the makefile using tmake.
tmake can be found at
www.troll.no/freebies/tmake.html.
-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
@@ -343,7 +344,7 @@ just go to distrib/msw/tmake and type
tmake -t b32 wxwin.pro -o ../../src/msw/makefile.b32
-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
@@ -365,7 +366,7 @@ files to be compiled. Some of them are only compiled in 16/32 bit mode.
Some other are only compiled with some compilers (others can't compile
them) - all this info is contained in this file.
-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.
@@ -375,11 +376,11 @@ I don't need it and can't test it, but it should be trivial to create
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 wxWindows.dsp run
+others. To generate wxWidgets.dsp run
-
tmake -t vc6 wxwin.pro -o ../../wxWindows.dsp
+
tmake -t vc6 wxwin.pro -o ../../wxWidgets.dsp
Then just include this project in any workspace or open it from VC IDE
and it will create a new workspace for you.
@@ -393,13 +394,13 @@ directory by 10 (and the number of files to be maintained too).
-
How do you use VC++'s memory leak checking instead of that in wxWindows?
+How do you use VC++'s memory leak checking instead of that in wxWidgets?
Vadim Zeitlin:
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
@@ -436,7 +437,7 @@ Currently this is not possible because the wxConfig family of classes is
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.
First, you can use wxRegKey directly, for example:
@@ -450,7 +451,7 @@ 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\\");
@@ -496,9 +497,9 @@ for the current status.
-
Why does Visual C++ complain about corrupted project files??
+Why does Visual C++ complain about corrupted project files{/a>
-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 .tar.gz 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
diff --git a/docs/html/faqx11.htm b/docs/html/faqx11.htm
index ddcd399d65..7ebaf3f5a0 100644
--- a/docs/html/faqx11.htm
+++ b/docs/html/faqx11.htm
@@ -1,7 +1,8 @@
+
-wxWindows 2 for X11 FAQ
+wxWidgets 2 for X11 FAQ
@@ -12,7 +13,7 @@
-wxWindows 2 for X11 FAQ
+wxWidgets 2 for X11 FAQ
diff --git a/docs/html/i18n.htm b/docs/html/i18n.htm
index c9d065dc67..21531213cb 100644
--- a/docs/html/i18n.htm
+++ b/docs/html/i18n.htm
@@ -1,8 +1,9 @@
+
- List of translators for wxWindows
+ List of translators for wxWidgets
@@ -10,7 +11,7 @@
-wxWindows internationalization
+wxWidgets internationalization
@@ -23,9 +24,9 @@
-wxWindows uses a certain number of user-readable strings such as
+wxWidgets uses a certain number of user-readable strings such as
"help" or "Load file" 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.
@@ -33,22 +34,22 @@ 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
-see below if you would like to translate wxWindows to
+see below 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).
-
+
Available translations
-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.
Please note that email addresses in the table below are intentionally invalid
@@ -58,7 +59,7 @@ to foil spam robots, remove one @ from them.
- Languages supported in wxWindows 2.x
+ Languages supported in wxWidgets 2.x
@@ -145,7 +146,8 @@ to foil spam robots, remove one @ from them.
Gerhard Gruber,
Stefan Hedemann,
Dr. Detlev Reymann,
- Mark Johnson
+ Mark Johnson,
+ Martin Jost
@@ -215,7 +217,7 @@ to foil spam robots, remove one @ from them.
Russian
Roman Rolinsky,
- Vadim Zeitlin
+ Vadim Zeitlin
Andrew V. Samoilov
@@ -230,7 +232,7 @@ to foil spam robots, remove one @ from them.
Spanish
Guillermo Rodriguez Garcia,
- JSJ
+ JSJ
@@ -258,23 +260,23 @@ to foil spam robots, remove one @ from them.
-
+
How to help
-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:
- Get the latest version of the file locale/wxstd.po from the
- wxWindows source tree: if you're using cvs
+ wxWidgets source tree: if you're using cvs
or the daily snapshots,
you should already have it. Otherwise you can always
retrieve it directly from the cvs repository via the Web interface
- here.
+ here.
- Rename it to XY.po where "XY" is the 2 letter
ISO 639-1 language code
@@ -292,22 +294,24 @@ translations. Here are the the steps you should follow:
accept the default values for them.
- Send the finished translation to
- Vadim Zeitlin and it will be
- added to the next wxWindows release or snapshot.
+ Vadim Zeitlin and it will be
+ added to the next wxWidgets release or snapshot.
In addition, please consider subscribing to the very low volume
-wxWindows translators mailing list on which the news especially important
+wxWidgets translators mailing list on which the news especially important
for the translators are announced.
Thank you in advance for your help!
-Please contact me with
+Please contact me with
any comments/suggestions.
+
+
diff --git a/docs/html/platform.htm b/docs/html/platform.htm
index f312ae8078..b439615723 100644
--- a/docs/html/platform.htm
+++ b/docs/html/platform.htm
@@ -22,9 +22,9 @@
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).
See also:
@@ -49,16 +49,16 @@ often don't work.
wxWindows 2 Platforms
-
- Platform
- Compiler
- Status
- Tested by
- Remarks
+
+ Platform
+ Compiler
+ Status
+ Tested by
+ Remarks
-Win32
(Win 9x/NT/2K)
+Win32
(Win 9x/NT/2K)
Visual C++ 4.2/5.x/6.0 VZ, JS Project files are provided for all versions except 4.2
Borland C++ 5.0
Also works with free command line Borland C++ 5.5
Mingw32 GRG, VZ Cross compilation from Linux works as well
@@ -71,66 +71,73 @@ often don't work.
Digital Mars (was Symantec C++) Chris Elliott Tested with 8.34beta
+
+Win64
(Windows XP/2003)
+ Visual C++ 7.1 
Some minor corrections not done yet but will be in time for 2.6.0...
+
+
-Win16
(Windows 3.1)
+Win16
(Windows 3.1)
Visual C++ 1.52 
Some features are missing (OLE related classes, threads, ...)
- Borland C++ can't cope with ODBC, resources and new wxGrid class. Last tested in wxWindows 2.2.7.
+ Borland C++ can't cope with ODBC, resources and new wxGrid class.
+ Last working version is wxWindows 2.2.7, support for Win16 has been removed in 2.4.x.
Borland C++ 4.0/5.0 JS
-
-Linux x86
- wxGTK with gcc 2.7.2
Should work, but nobody uses it any more
- wxGTK with egcs 1.1.1 VZ, RR
wxGTK with gcc 2.95
wxMotif with egcs 1.1.1
with LessTif 0.87
- wxMotif with gcc 2.95
with OpenMotif
+
+Linux x86
+ wxGTK with gcc 2.7.2
Might work, but nobody uses it any more
+ wxGTK with gcc 2.95--3.3 VZ, RR
wxMotif
with LessTif 0.87
+ wxMotif
with OpenMotif
-
All BSD systems tests are for wxGTK using gcc.
+
All BSD systems tests are for wxGTK using gcc.
-FreeBSD
+FreeBSD
all versions between 3.2 and 5.1 x86 VZ
-NetBSD
+NetBSD
1.6, Alpha VZ
-OpenBSD
+OpenBSD
3.1, Alpha VZ Some problems with shared libraries, ok with static ones
-
-Solaris
+
+Solaris
wxMotif with Sun CC 4.2 VZ Thread support must be disabled on system with not MT-safe X11
- wxMotif with gcc
wxGTK with Sun CC 4.2
wxGTK with gcc
wxGTK with Sun CC 5.0 and 6.1 (Solaris 7 and 8) Jiri Mracek You have to edit line 2079 in glib.h to fix GTK+ error
+ wxMotif with gcc
wxGTK with Sun CC 4.2
wxGTK with gcc
wxGTK with Sun CC 5.0 and 6.1 (Solaris 7 and 8) Jiri Mracek You have to edit line 2079 in glib.h to fix GTK+ error
+ wxGTK 2.5.1 with Sun CC 6.2 (Solaris 6 and 8) Carl Godkin Using GNU make
-AIX
+AIX
wxGTK 2.2.9 with gcc 3.0.4 Ian Brown Shared library building doesn't work, use --disable-shared
wxGTK 2.3.3 with xlC (AIX 4.3.2) Irvin Probst Both static and shared wxGTK libraries work, but only with static GTK+ and GLib
wxMotif with xlC 3.1.4.0 (AIX 4.2) Bernhard Eck
Some problems with OpenGL and native X server
+ wxX11 2.4.2 with xlC 6 (AIX 5.1) Swengtoo In 2.4.2 you need to remove parentheses from the configure line containing AIX_CXX_LD; you should also use GNU make
-
-HP-UX 10.20
+
+HP-UX 10.20
wxGTK with HP CC A.10.22
or HP aCC B3910B A.01.18 Staf Verhaegen
you need to add -Aa -D_HPUX_SOURCE to CFLAGS
- wxGTK with gcc Julian Albo Garcia
wxGTK with gcc Julian Albo Garcia
-IRIX
+IRIX
Note that all entries use MIPSPro 7.3 compiler on IRIX 6.5.9 with -mips3 -n32 flags if not mentioned otherwise.
Also note that you need to set LD_LIBRARYN32_PATH under IRIX to run wxWindows programs.
@@ -141,36 +148,43 @@ often don't work.
Ian
-
-SCO UnixWare
+
+SCO UnixWare
wxGTK with gcc William Suetholz UnixWare 2.1.3 with UnixWare 7 compatibility PTF
-DEC OSF/1
+DEC OSF/1
wxGTK with gcc Fabrice Didierjean OSF1 4.0 on Dec Alpha
you may need to run configure with --host=alpha-dec-osf switch
-
-OS/2
+
+OS/2
VisualAge 3.0/4.0 DW
OS/2 port is work in progress...
- EMX SN
- wxGTK with EMX SN configure scripts need to be regenerated with OS/2 port of autoconf
- wxMotif with EMX SN with LessTif 0.89; configure scripts need to be regenerated with OS/2 port of autoconf
+ EMX SN
+ wxGTK with EMX SN configure scripts need to be regenerated with OS/2 port of autoconf
+ wxMotif with EMX SN with LessTif 0.89; configure scripts need to be regenerated with OS/2 port of autoconf
-OpenVMS
+OpenVMS
wxGTK with Compaq-C++ V6.2 (OpenVMS Alpha 7.3) Jouk Jansen
-
-Linux S/390
+
+Linux S/390
wxGTK with gcc 2.95.2 VZ 2.3.1+ only
+
+Mac OS
+ wxMac CFM (OS 8.6+) SC with Metrowerks CodeWarrior 8.3 wxMac Mach-O (OS X) SC CodeWarrior or Apple DevTools (gcc) wxCocoa (OS X) DE Apple DevTools (gcc)
diff --git a/docs/latex/wx/db.tex b/docs/latex/wx/db.tex
index c30477bb89..b735d34814 100644
--- a/docs/latex/wx/db.tex
+++ b/docs/latex/wx/db.tex
@@ -1708,15 +1708,15 @@ one in to the function.
\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.}
@@ -1760,7 +1760,7 @@ automatically, and manage the destruction of the handle.
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.
@@ -1784,10 +1784,10 @@ Frees the SQL environment handle being managed by the instance of this class.
\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.
diff --git a/docs/publicity/announce.txt b/docs/publicity/announce.txt
index 0ef3435e40..0214920d5a 100644
--- a/docs/publicity/announce.txt
+++ b/docs/publicity/announce.txt
@@ -1,41 +1,56 @@
-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.
+
+To get wxWidgets, go to the Download page at:
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.
+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 wxWindows
+*** About wxWidgets
-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.
+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, wxWindows adopts the native look and feel of
+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
@@ -44,18 +59,18 @@ handlers for eading and writing many image types, resizeable panels
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
@@ -64,84 +79,5 @@ If you're considering wxWindows, do check out some of these links:
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
diff --git a/docs/x11/readme.txt b/docs/x11/readme.txt
index a9ece6e956..422839a2e2 100644
--- a/docs/x11/readme.txt
+++ b/docs/x11/readme.txt
@@ -1,7 +1,7 @@
- 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
diff --git a/include/wx/defs.h b/include/wx/defs.h
index e2e134ea9e..a5e656d224 100644
--- a/include/wx/defs.h
+++ b/include/wx/defs.h
@@ -2166,22 +2166,22 @@ typedef WX_NSView WXWidget; /* wxWindows BASE definition */
#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;
@@ -2189,9 +2189,9 @@ 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;
@@ -2203,8 +2203,16 @@ typedef WXHWND WXWidget;
#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)();
diff --git a/include/wx/generic/scrolwin.h b/include/wx/generic/scrolwin.h
index faf66d635a..4d0d0e3307 100644
--- a/include/wx/generic/scrolwin.h
+++ b/include/wx/generic/scrolwin.h
@@ -79,7 +79,7 @@ protected:
// 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:
diff --git a/include/wx/msw/button.h b/include/wx/msw/button.h
index 77df19e446..8e5a62461e 100644
--- a/include/wx/msw/button.h
+++ b/include/wx/msw/button.h
@@ -51,7 +51,7 @@ public:
// 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__
diff --git a/include/wx/msw/choice.h b/include/wx/msw/choice.h
index d02f98dcd8..690b168605 100644
--- a/include/wx/msw/choice.h
+++ b/include/wx/msw/choice.h
@@ -83,7 +83,7 @@ public:
// 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);
diff --git a/include/wx/msw/combobox.h b/include/wx/msw/combobox.h
index e7b3dc1f42..cd0880a81f 100644
--- a/include/wx/msw/combobox.h
+++ b/include/wx/msw/combobox.h
@@ -95,7 +95,7 @@ public:
// 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);
diff --git a/include/wx/msw/dialog.h b/include/wx/msw/dialog.h
index 7073936cc5..56135edeb1 100644
--- a/include/wx/msw/dialog.h
+++ b/include/wx/msw/dialog.h
@@ -97,7 +97,7 @@ public:
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,
diff --git a/include/wx/msw/frame.h b/include/wx/msw/frame.h
index 21b6badf86..0680ada270 100644
--- a/include/wx/msw/frame.h
+++ b/include/wx/msw/frame.h
@@ -126,7 +126,7 @@ protected:
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);
diff --git a/include/wx/msw/mdi.h b/include/wx/msw/mdi.h
index 7e2297986f..1d5e440809 100644
--- a/include/wx/msw/mdi.h
+++ b/include/wx/msw/mdi.h
@@ -90,9 +90,9 @@ public:
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:
@@ -164,8 +164,8 @@ public:
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();
diff --git a/include/wx/msw/notebook.h b/include/wx/msw/notebook.h
index b7ad535337..6e19b04fa3 100644
--- a/include/wx/msw/notebook.h
+++ b/include/wx/msw/notebook.h
@@ -177,7 +177,7 @@ protected:
// 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)
diff --git a/include/wx/msw/radiobox.h b/include/wx/msw/radiobox.h
index 9b3a90c121..093dca1f3a 100644
--- a/include/wx/msw/radiobox.h
+++ b/include/wx/msw/radiobox.h
@@ -112,7 +112,7 @@ public:
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);
diff --git a/include/wx/msw/statbmp.h b/include/wx/msw/statbmp.h
index 8920d1be7e..7aed8c8b12 100644
--- a/include/wx/msw/statbmp.h
+++ b/include/wx/msw/statbmp.h
@@ -77,7 +77,7 @@ public:
#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;
diff --git a/include/wx/msw/statbox.h b/include/wx/msw/statbox.h
index 5bce253763..decf37139d 100644
--- a/include/wx/msw/statbox.h
+++ b/include/wx/msw/statbox.h
@@ -42,7 +42,7 @@ public:
// 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; }
diff --git a/include/wx/msw/tbar95.h b/include/wx/msw/tbar95.h
index e184cd87c5..03cb30b657 100644
--- a/include/wx/msw/tbar95.h
+++ b/include/wx/msw/tbar95.h
@@ -101,7 +101,7 @@ protected:
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;
diff --git a/include/wx/msw/textctrl.h b/include/wx/msw/textctrl.h
index 058004f57a..71ac994ad9 100644
--- a/include/wx/msw/textctrl.h
+++ b/include/wx/msw/textctrl.h
@@ -202,7 +202,7 @@ protected:
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)
diff --git a/include/wx/msw/treectrl.h b/include/wx/msw/treectrl.h
index 4a0a5278f8..effeda59ff 100644
--- a/include/wx/msw/treectrl.h
+++ b/include/wx/msw/treectrl.h
@@ -413,7 +413,7 @@ public:
// 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);
diff --git a/include/wx/msw/wince/tbarwce.h b/include/wx/msw/wince/tbarwce.h
index e1a7346294..b8041224e3 100644
--- a/include/wx/msw/wince/tbarwce.h
+++ b/include/wx/msw/wince/tbarwce.h
@@ -112,7 +112,7 @@ protected:
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;
diff --git a/include/wx/msw/window.h b/include/wx/msw/window.h
index d936b7a8d6..225e229ae4 100644
--- a/include/wx/msw/window.h
+++ b/include/wx/msw/window.h
@@ -347,10 +347,10 @@ public:
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
diff --git a/include/wx/msw/wx.rc b/include/wx/msw/wx.rc
index 69db0764c3..9b30263ba5 100644
--- a/include/wx/msw/wx.rc
+++ b/include/wx/msw/wx.rc
@@ -203,7 +203,9 @@ wxBITMAP_STD_COLOURS BITMAP "wx/msw/colours.bmp"
// 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
diff --git a/include/wx/univ/window.h b/include/wx/univ/window.h
index a01a6e29b4..9bb9477eb1 100644
--- a/include/wx/univ/window.h
+++ b/include/wx/univ/window.h
@@ -261,7 +261,7 @@ protected:
#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:
diff --git a/src/generic/scrlwing.cpp b/src/generic/scrlwing.cpp
index deea726fb6..05e5a0c48c 100644
--- a/src/generic/scrlwing.cpp
+++ b/src/generic/scrlwing.cpp
@@ -1257,12 +1257,12 @@ void wxGenericScrolledWindow::OnPaint(wxPaintEvent& event)
}
#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
diff --git a/src/msw/button.cpp b/src/msw/button.cpp
index bffc09013b..46d520bcf7 100644
--- a/src/msw/button.cpp
+++ b/src/msw/button.cpp
@@ -435,7 +435,7 @@ bool wxButton::MSWCommand(WXUINT param, WXWORD WXUNUSED(id))
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
diff --git a/src/msw/choice.cpp b/src/msw/choice.cpp
index 8623579663..b1809f6c04 100644
--- a/src/msw/choice.cpp
+++ b/src/msw/choice.cpp
@@ -233,7 +233,7 @@ wxChoice::~wxChoice()
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)"));
@@ -253,7 +253,7 @@ int wxChoice::DoInsert(const wxString& item, int pos)
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)"));
@@ -536,7 +536,7 @@ wxSize wxChoice::DoGetBestSize() const
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 )
{
diff --git a/src/msw/combobox.cpp b/src/msw/combobox.cpp
index e62a0ed5a7..7c60aa5121 100644
--- a/src/msw/combobox.cpp
+++ b/src/msw/combobox.cpp
@@ -238,7 +238,7 @@ WXHBRUSH wxComboBox::OnCtlColor(WXHDC pDC,
// 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)
@@ -253,7 +253,7 @@ long wxComboBox::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
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);
diff --git a/src/msw/dialog.cpp b/src/msw/dialog.cpp
index d1f46b4b37..f43c35fe3f 100644
--- a/src/msw/dialog.cpp
+++ b/src/msw/dialog.cpp
@@ -440,9 +440,9 @@ void wxDialog::OnSysColourChanged(wxSysColourChangedEvent& WXUNUSED(event))
// 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 )
diff --git a/src/msw/frame.cpp b/src/msw/frame.cpp
index c2412f9155..6cf9c3a2d8 100644
--- a/src/msw/frame.cpp
+++ b/src/msw/frame.cpp
@@ -864,9 +864,9 @@ bool wxFrame::HandleMenuLoop(const wxEventType& evtType, WXWORD isPopup)
// 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 )
diff --git a/src/msw/mdi.cpp b/src/msw/mdi.cpp
index 5f980abb3d..3f3754a68b 100644
--- a/src/msw/mdi.cpp
+++ b/src/msw/mdi.cpp
@@ -382,11 +382,11 @@ void wxMDIParentFrame::ActivatePrevious()
// 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 )
@@ -596,7 +596,7 @@ bool wxMDIParentFrame::HandleCommand(WXWORD id, WXWORD cmd, WXHWND hwnd)
return false;
}
-long wxMDIParentFrame::MSWDefWindowProc(WXUINT message,
+WXLRESULT wxMDIParentFrame::MSWDefWindowProc(WXUINT message,
WXWPARAM wParam,
WXLPARAM lParam)
{
@@ -859,11 +859,11 @@ void wxMDIChildFrame::Activate()
// 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 )
@@ -1078,7 +1078,7 @@ bool wxMDIChildFrame::HandleGetMinMaxInfo(void *mmInfo)
// 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);
diff --git a/src/msw/notebook.cpp b/src/msw/notebook.cpp
index 432bcdda67..c027ef2d79 100644
--- a/src/msw/notebook.cpp
+++ b/src/msw/notebook.cpp
@@ -997,7 +997,7 @@ void wxNotebook::ApplyThemeBackground(wxWindow*, const wxColour&)
}
#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;
diff --git a/src/msw/radiobox.cpp b/src/msw/radiobox.cpp
index 0434f16e2e..29943e25c8 100644
--- a/src/msw/radiobox.cpp
+++ b/src/msw/radiobox.cpp
@@ -823,7 +823,7 @@ bool wxRadioBox::SetFont(const wxFont& font)
// our window proc
// ----------------------------------------------------------------------------
-long wxRadioBox::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
+WXLRESULT wxRadioBox::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
{
switch ( nMsg )
{
@@ -839,7 +839,7 @@ long wxRadioBox::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
wxBrush *brush = wxTheBrushList->FindOrCreateBrush(colBack, wxSOLID);
- return (WXHBRUSH)brush->GetResourceHandle();
+ return (WXLRESULT)brush->GetResourceHandle();
}
#endif // Win32
diff --git a/src/msw/spinctrl.cpp b/src/msw/spinctrl.cpp
index 34b9c39b51..4f2f56cca2 100644
--- a/src/msw/spinctrl.cpp
+++ b/src/msw/spinctrl.cpp
@@ -158,7 +158,7 @@ LRESULT APIENTRY _EXPORT wxBuddyTextWndProc(HWND hwnd,
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
diff --git a/src/msw/statbmp.cpp b/src/msw/statbmp.cpp
index 211bb7e249..a367e2df50 100644
--- a/src/msw/statbmp.cpp
+++ b/src/msw/statbmp.cpp
@@ -316,7 +316,7 @@ bool wxStaticBitmap::MSWOnDraw(WXDRAWITEMSTRUCT *item)
#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)
{
diff --git a/src/msw/statbox.cpp b/src/msw/statbox.cpp
index 2a622955cb..5c82943b73 100644
--- a/src/msw/statbox.cpp
+++ b/src/msw/statbox.cpp
@@ -154,7 +154,7 @@ wxSize wxStaticBox::DoGetBestSize() const
return wxSize(wBox, hBox);
}
-long wxStaticBox::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
+WXLRESULT wxStaticBox::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
{
switch ( nMsg )
{
diff --git a/src/msw/tbar95.cpp b/src/msw/tbar95.cpp
index 425a9c80b4..d782709dd2 100644
--- a/src/msw/tbar95.cpp
+++ b/src/msw/tbar95.cpp
@@ -1368,7 +1368,7 @@ void wxToolBar::HandleMouseMove(WXWPARAM WXUNUSED(wParam), WXLPARAM lParam)
}
}
-long wxToolBar::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
+WXLRESULT wxToolBar::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
{
switch ( nMsg )
{
diff --git a/src/msw/textctrl.cpp b/src/msw/textctrl.cpp
index 966fff942b..fa977a9896 100644
--- a/src/msw/textctrl.cpp
+++ b/src/msw/textctrl.cpp
@@ -1728,9 +1728,9 @@ void wxTextCtrl::OnChar(wxKeyEvent& event)
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 )
{
diff --git a/src/msw/treectrl.cpp b/src/msw/treectrl.cpp
index ba700d35ee..56ac64cba6 100644
--- a/src/msw/treectrl.cpp
+++ b/src/msw/treectrl.cpp
@@ -2138,10 +2138,10 @@ bool wxTreeCtrl::MSWCommand(WXUINT cmd, WXWORD id)
// 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) )
diff --git a/src/msw/wince/tbarwce.cpp b/src/msw/wince/tbarwce.cpp
index f5b7b164ef..f6fa2b5a57 100644
--- a/src/msw/wince/tbarwce.cpp
+++ b/src/msw/wince/tbarwce.cpp
@@ -1175,7 +1175,7 @@ void wxToolBar::HandleMouseMove(WXWPARAM wParam, WXLPARAM lParam)
}
}
-long wxToolBar::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
+WXLRESULT wxToolBar::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
{
#if 0
switch ( nMsg )
diff --git a/src/msw/window.cpp b/src/msw/window.cpp
index f6ba76104f..d58cf40d7e 100644
--- a/src/msw/window.cpp
+++ b/src/msw/window.cpp
@@ -1763,7 +1763,7 @@ bool wxWindowMSW::DoPopupMenu(wxMenu *menu, int x, int y)
// 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);
@@ -2184,7 +2184,7 @@ LRESULT WXDLLEXPORT APIENTRY _EXPORT wxWndProc(HWND hWnd, UINT message, WPARAM w
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;
@@ -2193,7 +2193,7 @@ long wxWindowMSW::MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam
union
{
bool allow;
- long result;
+ WXLRESULT result;
WXHICON hIcon;
WXHBRUSH hBrush;
} rc;
@@ -2888,7 +2888,7 @@ long wxWindowMSW::MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam
// 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);
}
diff --git a/src/univ/winuniv.cpp b/src/univ/winuniv.cpp
index 2a5b246c93..7b6895d501 100644
--- a/src/univ/winuniv.cpp
+++ b/src/univ/winuniv.cpp
@@ -1339,7 +1339,7 @@ void wxWindow::OnKeyUp(wxKeyEvent& event)
#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 )
{
diff --git a/wxPython/contrib/iewin/wxactivex.cpp b/wxPython/contrib/iewin/wxactivex.cpp
index 5196a9f6f6..a77919344f 100644
--- a/wxPython/contrib/iewin/wxactivex.cpp
+++ b/wxPython/contrib/iewin/wxactivex.cpp
@@ -1082,7 +1082,7 @@ void wxActiveX::OnMouse(wxMouseEvent& event)
// 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);
diff --git a/wxPython/contrib/iewin/wxactivex.h b/wxPython/contrib/iewin/wxactivex.h
index 6098fad89d..4c88a1d3f3 100644
--- a/wxPython/contrib/iewin/wxactivex.h
+++ b/wxPython/contrib/iewin/wxactivex.h
@@ -352,7 +352,7 @@ protected:
FuncXArray m_events;
MemberIdList m_eventsIdx;
- long MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
+ WXLRESULT MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
};
// events
-
How is wxWindows being developed?
+How is wxWidgets being developed?
-We are using the CVS system to develop and maintain wxWindows. This allows +We are using the CVS 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.-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.
-
How is wxWindows distributed?
+How is wxWidgets distributed?
-By ftp, and via the wxWindows CD-ROM. +By ftp, and via the wxWidgets CD-ROM.If you are feeling adventurous, you may also check out the sources directly from cvs. @@ -227,40 +227,40 @@ from cvs.
What are the plans for the future?
-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.-Other possibilities include: DCOM/CORBA compatibility; a wxWindows book; +Other possibilities include: DCOM/CORBA compatibility; a wxWidgets book; wxWorkshop, an IDE; other platforms, especially embedded systems; other interface abilities such as speech output.
-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.
-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!
What is wxBase?
-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).What is wxUniversal?
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.You may find more about wxUniversal here. @@ -269,7 +269,7 @@ You may find more about wxUniversal here. 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 wxWindows is as high as ever.
+from Java, and the level of interest in wxWidgets is as high as ever.
What about .NET/Mono?
@@ -281,27 +281,27 @@ garbage collection and various other Java-like language features.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.
- Not everyone wants or needs net services.
- C++ will be used for a long time to come; compared with C++, C# is a recent development and its future is not certain.
- 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).
- C# is usually byte-compiled and therefore slower. Plus, .NET adds a layer of overhead to the client computer -that wxWindows does not require. -
- 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. +
- Mono hasn't proven its long-term viability yet (it's a complex system of components); wxWidgets is ready now.
- You may not wish to buy into Microsoft marketing spin and APIs.
- Microsoft may at some point sue developers of non-Microsoft .NET implementations. After all, platform-independence is not in Microsoft's interest.
- .NET might never be implemented on some platforms, especially Mac and embedded variants of Linux. -
- wxPython and other language variants provide further reasons for wxWindows to continue. +
- wxPython and other language variants provide further reasons for wxWidgets to continue.
- 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!)
-See also top-level FAQ page +See also top-level FAQ page and Unix FAQ page.
List of questions in this category
-
-
- What is wxWindows 2 for GTK+? -
- Why doesn't reading floating point numbers work when using wxWindows? +
- What is wxWidgets 2 for GTK+? +
- Why doesn't reading floating point numbers work when using wxWidgets?
- Does wxGTK have GNOME support?
- Warning about GTK libraries supplied with RedHat
- What range of Intel Linux platforms will a given application binary be usable on? @@ -38,14 +39,14 @@ and Unix FAQ page.
- What are the smart preprocessing errors with the Apple Developer Tools?
- How does wxMac support the standard Apple About menu item and Help menu?
- How do I add an icon to my application? -
- How can I easily switch between different versions of wxWindows in CodeWarrior? +
- How can I easily switch between different versions of wxWidgets in CodeWarrior?
-
What is wxWindows 2 for GTK?
+What is wxWidgets 2 for GTK?
-wxWindows 2 for GTK is a port of wxWindows to the GTK+ toolkit, -which is freely available for most flavours of Unix with X. wxWindows 2 for GTK is +wxWidgets 2 for GTK is a port of wxWidgets to the GTK+ toolkit, +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 here.-
Why doesn't reading floating point numbers work when using wxWindows?
+Why doesn't reading floating point numbers work when using wxWidgets?
If your program reads the floating point numbers in the format 123.45 from a file, it may suddently start returning just 123 instead of the @@ -75,7 +76,7 @@ future, probably as a separate library.Warning about GTK+ libraries supplied with RedHat
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. diff --git a/docs/html/faqmac.htm b/docs/html/faqmac.htm index 4896e7e599..3e7f255569 100644 --- a/docs/html/faqmac.htm +++ b/docs/html/faqmac.htm @@ -2,7 +2,7 @@ -@@ -54,15 +54,15 @@ The author of this port is Stefan Cs
Which Mac platforms are supported?
-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.-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.
How is the Mac OS X port different from the Classic Mac OS port?
-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.This hybrid approach was suggested by Apple to the Fizzilla team working on Mozilla for Mac OS X.
@@ -87,7 +87,7 @@ Under Mac OS X, the Developer Tools are sufficient to build wxMac. CodeWarrior P
How does CVS handle file types/creators under Mac OS 8.x/9.x?
-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 treatxpm and xbm 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 xpm and xbm images correctly:
- bring up the Internet control panel, select the Advanced Options tab, click on the File Mapping icon from the list at the left and see if there are is an entry for ".xpm" files and another for ".xbm".
- if an entry exists, click Change... and make sure File Type is
TEXT(just those four capital letters); correct it if necessary. If there is no entry, make one with type set toTEXTand creator set to anything you like; reasonable choices includeGKON(Graphic Converter) orCWIE(CodeWarrior). @@ -101,8 +101,8 @@ The Mac OS X CVS client does not handle file types and creators at all (just likAll 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:
-
-
- decode and decompress the file
wxWindows/docs/mac/TypeAsMetrowerksText.sea.hqx- - drag the wxWindows CVS sandbox directory onto the autotyper and most of the files will be typed according to the file extension +
- decode and decompress the file
wxWidgets/docs/mac/TypeAsMetrowerksText.sea.hqx+ - drag the wxWidgets CVS sandbox directory onto the autotyper and most of the files will be typed according to the file extension
@@ -125,11 +125,11 @@ This is also necessary even if you don'want to build the Carbon targets.
Build the projects (
makemac6.mcpfor CodeWarrior Pro 6;makemac.mpcfor CodeWarrior Pro 5) in the following five directories:-
-
- wxWindows:src: -
- wxWindows:src:jpeg: -
- wxWindows:src:png: -
- wxWindows:src:tiff: -
- wxWindows:src:zlib: +
- wxWidgets:src: +
- wxWidgets:src:jpeg: +
- wxWidgets:src:png: +
- wxWidgets:src:tiff: +
- wxWidgets:src:zlib:
@@ -139,8 +139,8 @@ You need to have the Apple Developer Tools installed. The Developer Tools CD is
Building wxMac completely without configure is not supported.
-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:
mkdir macbuildcd macbuild@@ -197,12 +197,12 @@ This error can sometimes be corrected or avoided by modifying the source code. HHow does wxMac support the standard Apple About menu item and Help menu?
-Because wxWindows does not have a specific API for the About menu item or the Help 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 About menu item or the Help menu, the Mac OS port uses some static variables to help the engine make the right decisions:- It assumes that the About menu item is part of a Help menu.
- The title of the Help menu is stored in
wxApp::s_macHelpMenuTitleName, it defaults to "&Help", but you can change it in your constructor to your specific menu title. - The item Id of the About menu is stored in
wxApp::s_macAboutMenuItemID, it defaults towxID_ABOUT, but can be changed as well to suit your needs. - - The other items of the wxWindows help menu are appended to the Mac OS Help menu and the translation of Ids is handled transparently for your application. +
- The other items of the wxWidgets help menu are appended to the Mac OS Help menu and the translation of Ids is handled transparently for your application.
@@ -215,10 +215,10 @@ your project and in the CodeWarrior Settings add a check mark under Linker:Outpu Flags/Finder Flags/Has Custom Icon.
-
How can I easily switch between different versions of wxWindows in CodeWarrior?
+How can I easily switch between different versions of wxWidgets in CodeWarrior?
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.Under Edit-Preferences in General:Source Trees, type a name (for example WXWIN) diff --git a/docs/html/faqmot.htm b/docs/html/faqmot.htm index 609f6b70cc..6a7fdd83eb 100644 --- a/docs/html/faqmot.htm +++ b/docs/html/faqmot.htm @@ -1,7 +1,8 @@ +
-wxWindows 2 for Motif FAQ +wxWidgets 2 for Motif FAQ @@ -12,7 +13,7 @@-wxWindows 2 for Motif FAQ +wxWidgets 2 for Motif FAQ - What version of Motif do I need?
- What features are missing or partially implemented? -
- Does Dialog Editor work with wxWindows for Motif? +
- Does Dialog Editor work with wxWidgets for Motif?
- Why are windows are not refreshed properly until I resize them?
@@ -62,7 +63,7 @@ system is in preparation.-
Does Dialog Editor work with wxWindows for Motif?
+Does Dialog Editor work with wxWidgets for Motif?
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. diff --git a/docs/html/faqmsw.htm b/docs/html/faqmsw.htm index 79b0ce996f..aa0dcbe3cb 100644 --- a/docs/html/faqmsw.htm +++ b/docs/html/faqmsw.htm @@ -1,7 +1,8 @@ + -wxWindows 2 for Windows FAQ +wxWidgets 2 for Windows FAQ @@ -12,7 +13,7 @@-wxWindows 2 for Windows FAQ +wxWidgets 2 for Windows FAQ - What about Windows CE?
- What do I need to do for Windows XP?
- What compilers are supported? -
- Which is the best compiler to use with wxWindows 2? +
- Which is the best compiler to use with wxWidgets 2?
- Is Unicode supported? -
- Does wxWindows support double byte fonts (Chinese/Japanese/Korean etc.)? -
- Can you compile wxWindows 2 as a DLL? +
- Does wxWidgets support double byte fonts (Chinese/Japanese/Korean etc.)? +
- Can you compile wxWidgets 2 as a DLL?
- How can I reduce executable size? -
- Is wxWindows compatible with MFC? +
- Is wxWidgets compatible with MFC?
- Why do I get errors about setup.h not being found?
- Why do I get errors about FooBarA when I only use FooBar in my program?
- Why my code fails to compile with strange errors about new operator? -
- How do I port MFC applications to wxWindows? +
- How do I port MFC applications to wxWidgets?
- Why do I sometimes get bizarre crash problems using VC++ 5/6? -
- How are the wxWindows makefiles edited under Windows? -
- How do you use VC++'s memory leak checking instead of that in wxWindows? +
- How are the wxWidgets makefiles edited under Windows? +
- How do you use VC++'s memory leak checking instead of that in wxWidgets?
- Why are menu hotkeys or shortcuts not working in my application?
- Why can I not write to the HKLM part of the registry with wxRegConfig?
- Is MS Active Accessibility supported? -
- Why does Visual C++ complain about corrupted project files?? +
- Why does Visual C++ complain about corrupted project files{/a>
Which Windows platforms are supported?
-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).-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 @@ -64,12 +65,12 @@ makefiles to see what other files have been left out. 16-bit compilation is supported under Visual C++ 1.5, and Borland BC++ 4 to 5.
-wxWindows 2 for Windows will also compile on Unix with gcc using Wine from WineHQ. +wxWidgets 2 for Windows will also compile on Unix with gcc using Wine from WineHQ. The resulting executables are Unix binaries that work with the Wine Windows API emulator.
-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.
@@ -116,7 +117,7 @@ line:
1 24 "winxp.manifest" -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.
@@ -127,7 +128,7 @@ article
- decode and decompress the file
What compilers are supported?
-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:
-
@@ -143,18 +144,18 @@ currently the following are known to work:
- Or leave them on but do #undef new 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
-
Which is the best compiler to use with wxWindows 2?
+Which is the best compiler to use with wxWidgets 2?
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 wxWindows samples.+for wxWidgets samples.
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.
-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).
You can't beat Cygwin's price (free), and you can debug adequately using gdb. However, it's @@ -167,7 +168,7 @@ Watcom C++ is a little slow and the debugger is not really up to today's sta 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.
Is Unicode supported?
@@ -176,32 +177,32 @@ support for it under Windows 9x using MSLU.-
Does wxWindows support double byte fonts (Chinese/Japanese/Korean etc.)?
+Does wxWidgets support double byte fonts (Chinese/Japanese/Korean etc.)?
-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 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage=932 (default is 1252 for Western). Then you can see all the Japanese letters in -wxWindows applications. +wxWidgets applications.-
Can you compile wxWindows 2 as a DLL?
+Can you compile wxWidgets 2 as a DLL?
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.-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!
How can I reduce executable size?
-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.
@@ -214,27 +215,27 @@ use DLLs. Another good compression tool (probably better than Petite) is
+for the enormous increase in productivity you get with wxWidgets is almost always well worth it.
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.
-
@@ -276,16 +277,16 @@ The most common cause of this problem is the memory debugging settings in
setting wxUSE_GLOBAL_MEMORY_OPERATORS and
wxUSE_DEBUG_NEW_ALWAYS to 0 in this file
Is wxWindows compatible with MFC?
+Is wxWidgets compatible with MFC?
-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.Why do I get errors about setup.h not being found?
-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:
How do I port MFC applications to wxWindows?
+How do I port MFC applications to wxWidgets?
-Set up your interface from scratch using wxWindows (especially wxDesigner +Set up your interface from scratch using wxWidgets (especially wxDesigner or DialogBlocks -- it'll save you a lot of time) and when you have a shell prepared, you can start 'pouring in' code from the MFC app, with appropriate @@ -293,14 +294,14 @@ modifications. This is the approach I have used, and I found 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.Why do I sometimes get bizarre crash problems using VC++ 5/6?
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 @@ -313,13 +314,13 @@ Editor, in Release mode with optimizations on. If in doubt, 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.-
How are the wxWindows makefiles edited under Windows?
+How are the wxWidgets makefiles edited under Windows?
-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.Here are Vadim's notes:
@@ -334,7 +335,7 @@ example) and regenerate the makefile using tmake.
tmake can be found at www.troll.no/freebies/tmake.html. -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 @@ -343,7 +344,7 @@ just go to distrib/msw/tmake and type
tmake -t b32 wxwin.pro -o ../../src/msw/makefile.b32
-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 @@ -365,7 +366,7 @@ files to be compiled. Some of them are only compiled in 16/32 bit mode. Some other are only compiled with some compilers (others can't compile them) - all this info is contained in this file.
-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.
@@ -375,11 +376,11 @@ I don't need it and can't test it, but it should be trivial to create 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 wxWindows.dsp run
+others. To generate wxWidgets.dsp run
-
tmake -t vc6 wxwin.pro -o ../../wxWindows.dsp
+
tmake -t vc6 wxwin.pro -o ../../wxWidgets.dsp
Then just include this project in any workspace or open it from VC IDE and it will create a new workspace for you.
@@ -393,13 +394,13 @@ directory by 10 (and the number of files to be maintained too).
-
How do you use VC++'s memory leak checking instead of that in wxWindows?
+How do you use VC++'s memory leak checking instead of that in wxWidgets?
Vadim Zeitlin: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 @@ -436,7 +437,7 @@ Currently this is not possible because the wxConfig family of classes is 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.First, you can use wxRegKey directly, for example: @@ -450,7 +451,7 @@ 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\\"); @@ -496,9 +497,9 @@ for the current status.
-
Why does Visual C++ complain about corrupted project files??
+Why does Visual C++ complain about corrupted project files{/a>
-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 .tar.gz 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 diff --git a/docs/html/faqx11.htm b/docs/html/faqx11.htm index ddcd399d65..7ebaf3f5a0 100644 --- a/docs/html/faqx11.htm +++ b/docs/html/faqx11.htm @@ -1,7 +1,8 @@ + -wxWindows 2 for X11 FAQ +wxWidgets 2 for X11 FAQ @@ -12,7 +13,7 @@diff --git a/docs/html/i18n.htm b/docs/html/i18n.htm index c9d065dc67..21531213cb 100644 --- a/docs/html/i18n.htm +++ b/docs/html/i18n.htm @@ -1,8 +1,9 @@ + - -wxWindows 2 for X11 FAQ +wxWidgets 2 for X11 FAQ List of translators for wxWindows +List of translators for wxWidgets @@ -10,7 +11,7 @@@@ -23,9 +24,9 @@ -wxWindows internationalization +wxWidgets internationalization -wxWindows uses a certain number of user-readable strings such as +wxWidgets uses a certain number of user-readable strings such as "help" or "Load file" 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. @@ -33,22 +34,22 @@ 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 -see below if you would like to translate wxWindows to +see below 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). -
+
Available translations
-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.
Please note that email addresses in the table below are intentionally invalid @@ -58,7 +59,7 @@ to foil spam robots, remove one @ from them.
| Languages supported in wxWindows 2.x | +Languages supported in wxWidgets 2.x | ||||
| Russian | |
Roman Rolinsky, - Vadim Zeitlin + Vadim Zeitlin Andrew V. Samoilov | @@ -230,7 +232,7 @@ to foil spam robots, remove one @ from them.Spanish | |
Guillermo Rodriguez Garcia, - JSJ | + JSJ
| wxWindows 2 Platforms | |||||
| Platform | -Compiler | -Status | -Tested by | -Remarks | +|
| Platform | +Compiler | +Status | +Tested by | +Remarks | |
| Win32 (Win 9x/NT/2K) |
+Win32 (Win 9x/NT/2K) |
Visual C++ 4.2/5.x/6.0 | | VZ, JS | Project files are provided for all versions except 4.2 |
| Borland C++ 5.0 | | Also works with free command line Borland C++ 5.5 | |||
| Mingw32 | | GRG, VZ | Cross compilation from Linux works as well @@ -71,66 +71,73 @@ often don't work. | ||
| Digital Mars (was Symantec C++) | | Chris Elliott | Tested with 8.34beta | ||
| Win64 (Windows XP/2003) |
+ Visual C++ 7.1 | | Some minor corrections not done yet but will be in time for 2.6.0... | +||
| Win16 (Windows 3.1) |
+Win16 (Windows 3.1) |
Visual C++ 1.52 | | Some features are missing (OLE related classes, threads, ...) - Borland C++ can't cope with ODBC, resources and new wxGrid class. Last tested in wxWindows 2.2.7. |
+ Borland C++ can't cope with ODBC, resources and new wxGrid class.|
| Borland C++ 4.0/5.0 | | JS | |||
| Linux x86 | -wxGTK with gcc 2.7.2 | | Should work, but nobody uses it any more | -||
| wxGTK with egcs 1.1.1 | | VZ, RR | |||
| wxGTK with gcc 2.95 | | ||||
| wxMotif with egcs 1.1.1 | | with LessTif 0.87 | -|||
| wxMotif with gcc 2.95 | | with OpenMotif | +|||
| Linux x86 | +wxGTK with gcc 2.7.2 | | Might work, but nobody uses it any more | +||
| wxGTK with gcc 2.95--3.3 | | VZ, RR | |||
| wxMotif | | with LessTif 0.87 | +|||
| wxMotif | | with OpenMotif | |||
| All BSD systems tests are for wxGTK using gcc. | +|||||
| All BSD systems tests are for wxGTK using gcc. | |||||
| FreeBSD | +FreeBSD | all versions between 3.2 and 5.1 x86 | | VZ | |
| NetBSD | +NetBSD | 1.6, Alpha | | VZ | |
| OpenBSD | +OpenBSD | 3.1, Alpha | | VZ | Some problems with shared libraries, ok with static ones |
| Solaris | +|||||
| Solaris | wxMotif with Sun CC 4.2 | | VZ | Thread support must be disabled on system with not MT-safe X11 | -|
| wxMotif with gcc | | ||||
| wxGTK with Sun CC 4.2 | | ||||
| wxGTK with gcc | | ||||
| wxGTK with Sun CC 5.0 and 6.1 (Solaris 7 and 8) | | Jiri Mracek | You have to edit line 2079 in glib.h to fix GTK+ error | +||
| wxMotif with gcc | | ||||
| wxGTK with Sun CC 4.2 | | ||||
| wxGTK with gcc | | ||||
| wxGTK with Sun CC 5.0 and 6.1 (Solaris 7 and 8) | | Jiri Mracek | You have to edit line 2079 in glib.h to fix GTK+ error | +||
| wxGTK 2.5.1 with Sun CC 6.2 (Solaris 6 and 8) | | Carl Godkin | Using GNU make | ||
| AIX | +AIX | wxGTK 2.2.9 with gcc 3.0.4 | | Ian Brown | Shared library building doesn't work, use --disable-shared |
| wxGTK 2.3.3 with xlC (AIX 4.3.2) | | Irvin Probst | Both static and shared wxGTK libraries work, but only with static GTK+ and GLib | ||
| wxMotif with xlC 3.1.4.0 (AIX 4.2) | |
Bernhard Eck | Some problems with OpenGL and native X server | +||
| wxX11 2.4.2 with xlC 6 (AIX 5.1) | | Swengtoo | In 2.4.2 you need to remove parentheses from the configure line containing AIX_CXX_LD; you should also use GNU make | ||
| HP-UX 10.20 | +|||||
| HP-UX 10.20 | wxGTK with HP CC A.10.22 or HP aCC B3910B A.01.18 | | Staf Verhaegen | you need to add -Aa -D_HPUX_SOURCE to CFLAGS | -|
| wxGTK with gcc | | Julian Albo Garcia | |||
| wxGTK with gcc | | Julian Albo Garcia | |||
| IRIX | +IRIX | ||||
| Note that all entries use MIPSPro 7.3 compiler on IRIX 6.5.9 with -mips3 -n32 flags if not mentioned otherwise. Also note that you need to set LD_LIBRARYN32_PATH under IRIX to run wxWindows programs. @@ -141,36 +148,43 @@ often don't work. | |||||
| Ian | ||||
| SCO UnixWare | +|||||
| SCO UnixWare | wxGTK with gcc | | William Suetholz | UnixWare 2.1.3 with UnixWare 7 compatibility PTF | |
| DEC OSF/1 | +DEC OSF/1 | wxGTK with gcc | | Fabrice Didierjean | OSF1 4.0 on Dec Alpha you may need to run configure with --host=alpha-dec-osf switch |
| OS/2 | +|||||
| OS/2 | VisualAge 3.0/4.0 | | DW | OS/2 port is work in progress... | -|
| EMX | | SN | -|||
| wxGTK with EMX | | SN | configure scripts need to be regenerated with OS/2 port of autoconf | -||
| wxMotif with EMX | | SN | with LessTif 0.89; configure scripts need to be regenerated with OS/2 port of autoconf | +||
| EMX | | SN | +|||
| wxGTK with EMX | | SN | configure scripts need to be regenerated with OS/2 port of autoconf | +||
| wxMotif with EMX | | SN | with LessTif 0.89; configure scripts need to be regenerated with OS/2 port of autoconf | ||
| OpenVMS | +OpenVMS | wxGTK with Compaq-C++ V6.2 (OpenVMS Alpha 7.3) | | Jouk Jansen | |
| Linux S/390 | +|||||
| Linux S/390 | wxGTK with gcc 2.95.2 | | VZ | 2.3.1+ only | |
| Mac OS | +|||||
| wxMac CFM (OS 8.6+) | | SC | with Metrowerks CodeWarrior 8.3 | ||
| wxMac Mach-O (OS X) | | SC | CodeWarrior or Apple DevTools (gcc) | ||
| wxCocoa (OS X) | | DE | Apple DevTools (gcc) | ||
diff --git a/docs/latex/wx/db.tex b/docs/latex/wx/db.tex index c30477bb89..b735d34814 100644 --- a/docs/latex/wx/db.tex +++ b/docs/latex/wx/db.tex @@ -1708,15 +1708,15 @@ one in to the function. \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.} @@ -1760,7 +1760,7 @@ automatically, and manage the destruction of the handle. 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. @@ -1784,10 +1784,10 @@ Frees the SQL environment handle being managed by the instance of this class. \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. diff --git a/docs/publicity/announce.txt b/docs/publicity/announce.txt index 0ef3435e40..0214920d5a 100644 --- a/docs/publicity/announce.txt +++ b/docs/publicity/announce.txt @@ -1,41 +1,56 @@ -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. + +To get wxWidgets, go to the Download page at: 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. +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 wxWindows +*** About wxWidgets -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. +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, wxWindows adopts the native look and feel of +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 @@ -44,18 +59,18 @@ handlers for eading and writing many image types, resizeable panels 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 @@ -64,84 +79,5 @@ If you're considering wxWindows, do check out some of these links: 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 diff --git a/docs/x11/readme.txt b/docs/x11/readme.txt index a9ece6e956..422839a2e2 100644 --- a/docs/x11/readme.txt +++ b/docs/x11/readme.txt @@ -1,7 +1,7 @@ - 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 diff --git a/include/wx/defs.h b/include/wx/defs.h index e2e134ea9e..a5e656d224 100644 --- a/include/wx/defs.h +++ b/include/wx/defs.h @@ -2166,22 +2166,22 @@ typedef WX_NSView WXWidget; /* wxWindows BASE definition */ #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; @@ -2189,9 +2189,9 @@ 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; @@ -2203,8 +2203,16 @@ typedef WXHWND WXWidget; #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)(); diff --git a/include/wx/generic/scrolwin.h b/include/wx/generic/scrolwin.h index faf66d635a..4d0d0e3307 100644 --- a/include/wx/generic/scrolwin.h +++ b/include/wx/generic/scrolwin.h @@ -79,7 +79,7 @@ protected: // 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: diff --git a/include/wx/msw/button.h b/include/wx/msw/button.h index 77df19e446..8e5a62461e 100644 --- a/include/wx/msw/button.h +++ b/include/wx/msw/button.h @@ -51,7 +51,7 @@ public: // 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__ diff --git a/include/wx/msw/choice.h b/include/wx/msw/choice.h index d02f98dcd8..690b168605 100644 --- a/include/wx/msw/choice.h +++ b/include/wx/msw/choice.h @@ -83,7 +83,7 @@ public: // 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); diff --git a/include/wx/msw/combobox.h b/include/wx/msw/combobox.h index e7b3dc1f42..cd0880a81f 100644 --- a/include/wx/msw/combobox.h +++ b/include/wx/msw/combobox.h @@ -95,7 +95,7 @@ public: // 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); diff --git a/include/wx/msw/dialog.h b/include/wx/msw/dialog.h index 7073936cc5..56135edeb1 100644 --- a/include/wx/msw/dialog.h +++ b/include/wx/msw/dialog.h @@ -97,7 +97,7 @@ public: 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, diff --git a/include/wx/msw/frame.h b/include/wx/msw/frame.h index 21b6badf86..0680ada270 100644 --- a/include/wx/msw/frame.h +++ b/include/wx/msw/frame.h @@ -126,7 +126,7 @@ protected: 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); diff --git a/include/wx/msw/mdi.h b/include/wx/msw/mdi.h index 7e2297986f..1d5e440809 100644 --- a/include/wx/msw/mdi.h +++ b/include/wx/msw/mdi.h @@ -90,9 +90,9 @@ public: 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: @@ -164,8 +164,8 @@ public: 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(); diff --git a/include/wx/msw/notebook.h b/include/wx/msw/notebook.h index b7ad535337..6e19b04fa3 100644 --- a/include/wx/msw/notebook.h +++ b/include/wx/msw/notebook.h @@ -177,7 +177,7 @@ protected: // 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) diff --git a/include/wx/msw/radiobox.h b/include/wx/msw/radiobox.h index 9b3a90c121..093dca1f3a 100644 --- a/include/wx/msw/radiobox.h +++ b/include/wx/msw/radiobox.h @@ -112,7 +112,7 @@ public: 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); diff --git a/include/wx/msw/statbmp.h b/include/wx/msw/statbmp.h index 8920d1be7e..7aed8c8b12 100644 --- a/include/wx/msw/statbmp.h +++ b/include/wx/msw/statbmp.h @@ -77,7 +77,7 @@ public: #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; diff --git a/include/wx/msw/statbox.h b/include/wx/msw/statbox.h index 5bce253763..decf37139d 100644 --- a/include/wx/msw/statbox.h +++ b/include/wx/msw/statbox.h @@ -42,7 +42,7 @@ public: // 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; } diff --git a/include/wx/msw/tbar95.h b/include/wx/msw/tbar95.h index e184cd87c5..03cb30b657 100644 --- a/include/wx/msw/tbar95.h +++ b/include/wx/msw/tbar95.h @@ -101,7 +101,7 @@ protected: 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; diff --git a/include/wx/msw/textctrl.h b/include/wx/msw/textctrl.h index 058004f57a..71ac994ad9 100644 --- a/include/wx/msw/textctrl.h +++ b/include/wx/msw/textctrl.h @@ -202,7 +202,7 @@ protected: 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) diff --git a/include/wx/msw/treectrl.h b/include/wx/msw/treectrl.h index 4a0a5278f8..effeda59ff 100644 --- a/include/wx/msw/treectrl.h +++ b/include/wx/msw/treectrl.h @@ -413,7 +413,7 @@ public: // 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); diff --git a/include/wx/msw/wince/tbarwce.h b/include/wx/msw/wince/tbarwce.h index e1a7346294..b8041224e3 100644 --- a/include/wx/msw/wince/tbarwce.h +++ b/include/wx/msw/wince/tbarwce.h @@ -112,7 +112,7 @@ protected: 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; diff --git a/include/wx/msw/window.h b/include/wx/msw/window.h index d936b7a8d6..225e229ae4 100644 --- a/include/wx/msw/window.h +++ b/include/wx/msw/window.h @@ -347,10 +347,10 @@ public: 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 diff --git a/include/wx/msw/wx.rc b/include/wx/msw/wx.rc index 69db0764c3..9b30263ba5 100644 --- a/include/wx/msw/wx.rc +++ b/include/wx/msw/wx.rc @@ -203,7 +203,9 @@ wxBITMAP_STD_COLOURS BITMAP "wx/msw/colours.bmp" // 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 diff --git a/include/wx/univ/window.h b/include/wx/univ/window.h index a01a6e29b4..9bb9477eb1 100644 --- a/include/wx/univ/window.h +++ b/include/wx/univ/window.h @@ -261,7 +261,7 @@ protected: #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: diff --git a/src/generic/scrlwing.cpp b/src/generic/scrlwing.cpp index deea726fb6..05e5a0c48c 100644 --- a/src/generic/scrlwing.cpp +++ b/src/generic/scrlwing.cpp @@ -1257,12 +1257,12 @@ void wxGenericScrolledWindow::OnPaint(wxPaintEvent& event) } #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 diff --git a/src/msw/button.cpp b/src/msw/button.cpp index bffc09013b..46d520bcf7 100644 --- a/src/msw/button.cpp +++ b/src/msw/button.cpp @@ -435,7 +435,7 @@ bool wxButton::MSWCommand(WXUINT param, WXWORD WXUNUSED(id)) 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 diff --git a/src/msw/choice.cpp b/src/msw/choice.cpp index 8623579663..b1809f6c04 100644 --- a/src/msw/choice.cpp +++ b/src/msw/choice.cpp @@ -233,7 +233,7 @@ wxChoice::~wxChoice() 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)")); @@ -253,7 +253,7 @@ int wxChoice::DoInsert(const wxString& item, int pos) 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)")); @@ -536,7 +536,7 @@ wxSize wxChoice::DoGetBestSize() const 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 ) { diff --git a/src/msw/combobox.cpp b/src/msw/combobox.cpp index e62a0ed5a7..7c60aa5121 100644 --- a/src/msw/combobox.cpp +++ b/src/msw/combobox.cpp @@ -238,7 +238,7 @@ WXHBRUSH wxComboBox::OnCtlColor(WXHDC pDC, // 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) @@ -253,7 +253,7 @@ long wxComboBox::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam) 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); diff --git a/src/msw/dialog.cpp b/src/msw/dialog.cpp index d1f46b4b37..f43c35fe3f 100644 --- a/src/msw/dialog.cpp +++ b/src/msw/dialog.cpp @@ -440,9 +440,9 @@ void wxDialog::OnSysColourChanged(wxSysColourChangedEvent& WXUNUSED(event)) // 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 ) diff --git a/src/msw/frame.cpp b/src/msw/frame.cpp index c2412f9155..6cf9c3a2d8 100644 --- a/src/msw/frame.cpp +++ b/src/msw/frame.cpp @@ -864,9 +864,9 @@ bool wxFrame::HandleMenuLoop(const wxEventType& evtType, WXWORD isPopup) // 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 ) diff --git a/src/msw/mdi.cpp b/src/msw/mdi.cpp index 5f980abb3d..3f3754a68b 100644 --- a/src/msw/mdi.cpp +++ b/src/msw/mdi.cpp @@ -382,11 +382,11 @@ void wxMDIParentFrame::ActivatePrevious() // 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 ) @@ -596,7 +596,7 @@ bool wxMDIParentFrame::HandleCommand(WXWORD id, WXWORD cmd, WXHWND hwnd) return false; } -long wxMDIParentFrame::MSWDefWindowProc(WXUINT message, +WXLRESULT wxMDIParentFrame::MSWDefWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam) { @@ -859,11 +859,11 @@ void wxMDIChildFrame::Activate() // 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 ) @@ -1078,7 +1078,7 @@ bool wxMDIChildFrame::HandleGetMinMaxInfo(void *mmInfo) // 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); diff --git a/src/msw/notebook.cpp b/src/msw/notebook.cpp index 432bcdda67..c027ef2d79 100644 --- a/src/msw/notebook.cpp +++ b/src/msw/notebook.cpp @@ -997,7 +997,7 @@ void wxNotebook::ApplyThemeBackground(wxWindow*, const wxColour&) } #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; diff --git a/src/msw/radiobox.cpp b/src/msw/radiobox.cpp index 0434f16e2e..29943e25c8 100644 --- a/src/msw/radiobox.cpp +++ b/src/msw/radiobox.cpp @@ -823,7 +823,7 @@ bool wxRadioBox::SetFont(const wxFont& font) // our window proc // ---------------------------------------------------------------------------- -long wxRadioBox::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam) +WXLRESULT wxRadioBox::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam) { switch ( nMsg ) { @@ -839,7 +839,7 @@ long wxRadioBox::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam) wxBrush *brush = wxTheBrushList->FindOrCreateBrush(colBack, wxSOLID); - return (WXHBRUSH)brush->GetResourceHandle(); + return (WXLRESULT)brush->GetResourceHandle(); } #endif // Win32 diff --git a/src/msw/spinctrl.cpp b/src/msw/spinctrl.cpp index 34b9c39b51..4f2f56cca2 100644 --- a/src/msw/spinctrl.cpp +++ b/src/msw/spinctrl.cpp @@ -158,7 +158,7 @@ LRESULT APIENTRY _EXPORT wxBuddyTextWndProc(HWND hwnd, 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 diff --git a/src/msw/statbmp.cpp b/src/msw/statbmp.cpp index 211bb7e249..a367e2df50 100644 --- a/src/msw/statbmp.cpp +++ b/src/msw/statbmp.cpp @@ -316,7 +316,7 @@ bool wxStaticBitmap::MSWOnDraw(WXDRAWITEMSTRUCT *item) #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) { diff --git a/src/msw/statbox.cpp b/src/msw/statbox.cpp index 2a622955cb..5c82943b73 100644 --- a/src/msw/statbox.cpp +++ b/src/msw/statbox.cpp @@ -154,7 +154,7 @@ wxSize wxStaticBox::DoGetBestSize() const return wxSize(wBox, hBox); } -long wxStaticBox::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam) +WXLRESULT wxStaticBox::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam) { switch ( nMsg ) { diff --git a/src/msw/tbar95.cpp b/src/msw/tbar95.cpp index 425a9c80b4..d782709dd2 100644 --- a/src/msw/tbar95.cpp +++ b/src/msw/tbar95.cpp @@ -1368,7 +1368,7 @@ void wxToolBar::HandleMouseMove(WXWPARAM WXUNUSED(wParam), WXLPARAM lParam) } } -long wxToolBar::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam) +WXLRESULT wxToolBar::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam) { switch ( nMsg ) { diff --git a/src/msw/textctrl.cpp b/src/msw/textctrl.cpp index 966fff942b..fa977a9896 100644 --- a/src/msw/textctrl.cpp +++ b/src/msw/textctrl.cpp @@ -1728,9 +1728,9 @@ void wxTextCtrl::OnChar(wxKeyEvent& event) 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 ) { diff --git a/src/msw/treectrl.cpp b/src/msw/treectrl.cpp index ba700d35ee..56ac64cba6 100644 --- a/src/msw/treectrl.cpp +++ b/src/msw/treectrl.cpp @@ -2138,10 +2138,10 @@ bool wxTreeCtrl::MSWCommand(WXUINT cmd, WXWORD id) // 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) ) diff --git a/src/msw/wince/tbarwce.cpp b/src/msw/wince/tbarwce.cpp index f5b7b164ef..f6fa2b5a57 100644 --- a/src/msw/wince/tbarwce.cpp +++ b/src/msw/wince/tbarwce.cpp @@ -1175,7 +1175,7 @@ void wxToolBar::HandleMouseMove(WXWPARAM wParam, WXLPARAM lParam) } } -long wxToolBar::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam) +WXLRESULT wxToolBar::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam) { #if 0 switch ( nMsg ) diff --git a/src/msw/window.cpp b/src/msw/window.cpp index f6ba76104f..d58cf40d7e 100644 --- a/src/msw/window.cpp +++ b/src/msw/window.cpp @@ -1763,7 +1763,7 @@ bool wxWindowMSW::DoPopupMenu(wxMenu *menu, int x, int y) // 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); @@ -2184,7 +2184,7 @@ LRESULT WXDLLEXPORT APIENTRY _EXPORT wxWndProc(HWND hWnd, UINT message, WPARAM w 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; @@ -2193,7 +2193,7 @@ long wxWindowMSW::MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam union { bool allow; - long result; + WXLRESULT result; WXHICON hIcon; WXHBRUSH hBrush; } rc; @@ -2888,7 +2888,7 @@ long wxWindowMSW::MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam // 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); } diff --git a/src/univ/winuniv.cpp b/src/univ/winuniv.cpp index 2a5b246c93..7b6895d501 100644 --- a/src/univ/winuniv.cpp +++ b/src/univ/winuniv.cpp @@ -1339,7 +1339,7 @@ void wxWindow::OnKeyUp(wxKeyEvent& event) #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 ) { diff --git a/wxPython/contrib/iewin/wxactivex.cpp b/wxPython/contrib/iewin/wxactivex.cpp index 5196a9f6f6..a77919344f 100644 --- a/wxPython/contrib/iewin/wxactivex.cpp +++ b/wxPython/contrib/iewin/wxactivex.cpp @@ -1082,7 +1082,7 @@ void wxActiveX::OnMouse(wxMouseEvent& event) // 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); diff --git a/wxPython/contrib/iewin/wxactivex.h b/wxPython/contrib/iewin/wxactivex.h index 6098fad89d..4c88a1d3f3 100644 --- a/wxPython/contrib/iewin/wxactivex.h +++ b/wxPython/contrib/iewin/wxactivex.h @@ -352,7 +352,7 @@ protected: FuncXArray m_events; MemberIdList m_eventsIdx; - long MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam); + WXLRESULT MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam); }; // events