-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,18 +68,18 @@ 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.
+This port is largely complete. For further information, see the wxEmbedded page.
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 +131,7 @@ article.
-
+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 +171,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.
-
-
-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!
@@ -214,27 +218,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.
+Also, run 'strip' after linking to remove all traces of debug info.
-
@@ -243,7 +247,7 @@ lib/mswd
or if building the static Release library, lib/msw.
-See also the wxWiki Contents
+See also the wxWiki Contents
for more information.
@@ -276,16 +280,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:
-
-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 +342,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 +351,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 +373,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 +383,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 +401,13 @@ directory by 10 (and the number of files to be maintained too).
-
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 +444,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 +458,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\\"); @@ -490,15 +498,15 @@ bool myGlobalConfig::Write (const wxString& key, const wxString& value)
Is MS Active Accessibility supported?
-This is being worked on. Please see this page +This is being worked on. Please see this page for the current status.-
Why does Visual C++ complain about corrupted project files??
+Why does Visual C++ complain about corrupted project files?
-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 @@ -509,6 +517,58 @@ Of course, another possibility is to always use only the Windows cvs client and to avoid this problem completely.+
Visual C++ gives errors about multiply defined symbols, what can I do?
+ +If you get errors like this + ++MSVCRTD.lib(MSVCRTD.dll) : error LNK2005: _xxxxxx already defined in LIBCD.lib(yyyyy.obj) ++ +when linking your project, this means that you used different versions of CRT +(C Run-Time) library for wxWindows (or possibly another library) and the main +project. Visual C++ provides static or dynamic and multithread safe or not +versions of CRT for each of debug and release builds, for a total of 8 +libraries. You can choose among them by going to the "Code generation" +page/subitem of the "C++" tab/item in the project proprieties dialog in VC6/7. ++To avoid problems, you must use the same one for all +components of your project. wxWindows uses multithread safe DLL version of the +CRT which is a good choice but may be problematic when distributing your +applications if you don't include the CRT DLL in your installation -- in this +case you may decide to switch to using a static CRT version. If you build with +wxUSE_THREADS == 0 you may also use the non MT-safe version as it is +slightly smaller and faster. +
+But the most important thing is to use the same CRT setting for +all components of your project. + +
Why do I get compilation errors when using wxWidgets with DirectShow?
+ +If you get errors when including Microsoft DirectShow or DirectDraw headers, +the following message from Peter Whaite could help: ++ ++> This causes compilation errors within DirectShow: +> +> wxutil.h(125) : error C2065: 'EXECUTE_ASSERT' : undeclared identifier +> amfilter.h(1099) : error C2065: 'ASSERT' : undeclared identifier + +The reason for this is that __WXDEBUG__ is also used by the DXSDK (9.0 +in my case) to '#pragma once' the contents of +DXSDK/Samples/C++/DirectShow/BaseClasses/wxdebug.h. So if __WXDEBUG__ +is defined, then wxdebug.h doesn't get included, and the assert macros +don't get defined. You have to #undef __WXDEBUG__ before including the +directshow baseclass's <streams.h>. +How do I handle Windows messages in my wxWidgets program?
+ +To handle a Windows message you need to override a virtual +MSWWindowProc() method in a wxWindow-derived class. You should then +test if nMsg parameter is the message you need to process and perform +the necessary action if it is or call the base class method otherwise. + +