+wxWidgets can be used to develop and deliver applications on Windows 95, Windows 98, Windows NT, +Windows 2000, Windows XP, and Windows Vista. A Windows CE +port is also available (see below).
-wxWindows 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 -class doesn't work either because the Windows 3.1 registry is very simplistic. Check out the 16-bit -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. +16-bit compilation is only supported for wxWidgets 2.4 and previous versions, +using Visual C++ 1.5 and Borland BC++ 4 to 5.
-wxWindows 2 for Windows will also compile on Unix with gcc using TWIN32 from Willows, -although TWIN32 is still in a preliminary state. The resulting executables are -Unix binaries that work with the TWIN32 Windows API emulator.
+wxWidgets 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 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 -programs with TWIN32, and finally produce an ix86 Windows executable using Cygwin/Mingw32, +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 supports Pocket PC 2002/2003 and MS Smartphone 2002/2003, using +Embedded Visual C++ 3 or 4. For further information, see the wxMSW section in +the wxWidgets Reference Manual, and also the wxEmbedded page.
+ +For versions of wxWidgets below 2.5, you need to provide the manifest +explicitly, as follows.
+ In the same directory as you have your executable (e.g. foo.exe) you put a file called foo.exe.manifest in which you have something like the following: @@ -113,37 +115,49 @@ the following: </assembly> +If you want to add it to your application permanently, +you can also include it in your .rc file using this +line:
+ +
+ 1 24 "winxp.manifest" ++ +For an explanation of this syntax, please see +this +article. +
+
-There is a linking problem with Symantec C++ which I hope someone can help solve. -
-
+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 @@ -156,74 +170,87 @@ 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. However BC++ has trouble compiling large executables statically, +so you need to dynamically link the wxWidgets libraries.
- -"For Japanese under Win2000, it seems that wxWindows has no problems to work with double byte char sets -(I mean DBCS, that's 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 funny Japanese letters under wxWindows too.
+Yes, Unicode is fully supported under Windows NT/2000 and there is limited +support for it under Windows 9x using MSLU. +
-In a wxTextCtrl control you have to set the window style "wxTE_RICH", otherwise this control shows the wrong -letters. +
+For Japanese under Win2000, it seems that wxWidgets has no problems working +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 +wxWidgets applications. +
-
-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!
-Statically-linked wxWindows 2 programs are smaller than wxWindows 1.xx programs, because of the way -wxWindows 2 has been designed to reduce dependencies between classes, and other -techniques. The linker will not include code from the library that is not (directly or -indirectly) referenced -by your application. So for example, the 'minimal' sample is less than 500KB using VC++ 6 -(note that this figure may be greater for the latest version of wxWindows).
- If you want to distribute really small executables, you can use Petite by Ian Luck. This nifty utility compresses Windows executables by around 50%, so your 500KB executable will shrink to a mere 250KB. With this sort of size, there is reduced incentive to -use DLLs. Another good compression tool is UPX. +use DLLs. Another good compression tool (probably better than Petite) is UPX.
Please do not be surprised if MinGW produces a statically-linked minimal executable of 1 MB. Firstly, gcc produces larger executables than some compilers. Secondly, this figure will -include most of the overhead of wxWindows, so as your application becomes more -complex, the overhead becomes proportionaly less significant. And thirdly, trading executable compactness -for the enormous increase in productivity you get with wxWindows is almost always well worth it. +include most of the overhead of wxWidgets, so as your application becomes more +complex, the overhead becomes proportionally less significant. And thirdly, trading executable compactness +for the enormous increase in productivity you get with 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 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. +
-
+
+ +lib/vc_lib/mswd
+ +or if building the static Release library, lib/vc_lib/msw.
+ +See also the wxWiki Contents +for more information.
+ +
-
-As of wxWindows 2.1, there is a new system written by Vadim Zeitlin, that +For 2.4.x, there is a system written by Vadim Zeitlin that generates the makefiles from templates using tmake.
-Here are Vadim's notes:
+Here are Vadim's notes on tmake:
To use these new makefiles, you don't need anything (but see below). @@ -341,7 +372,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.
@@ -351,11 +382,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.dspThen just include this project in any workspace or open it from VC IDE and it will create a new workspace for you.
@@ -369,13 +400,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 @@ -412,7 +443,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: @@ -464,6 +495,80 @@ bool myGlobalConfig::Write (const wxString& key, const wxString& value) }
Is MS Active Accessibility supported?
+ +This is being worked on. Please see this page +for the current status. + ++ + +
Why does Visual C++ complain about corrupted project files?
+ +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 +the files with the DOS line endings, so you must transform the files to this +format using any of the thousands ways to do it. ++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. + +