-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 @@ -61,25 +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 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 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 -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 is largely complete. For further information, see the wxEmbedded page.
+ +
+ 1 24 "winxp.manifest" ++ +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.
+ +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 @@ -155,67 +171,86 @@ 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.
- -"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 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 +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 300KB using VC++ 6.
- 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 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/mswd
+ +or if building the static Release library, 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 +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:
@@ -333,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.
@@ -343,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.
@@ -361,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 @@ -392,7 +432,11 @@ VZ This can happen if you have a child window intercepting EVT_CHAR events and swallowing all keyboard input. You should ensure that event.Skip() is called for all input that -isn'used by the event handler. +isn'used by the event handler.++ +It can also happen if you append the submenu to the parent +menu {\it before} you have added your menu items. Do the append {\it after} adding +your items, or accelerators may not be registered properly.
Why can I not write to the HKLM part of the registry with wxRegConfig?
@@ -400,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: @@ -414,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\\"); @@ -452,6 +496,80 @@ bool myGlobalConfig::Write (const wxString& key, const wxString& value) }
+ + +
+Of course, another possibility is to always use only the Windows cvs client +and to avoid this problem completely. +
+ +
+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. + +
+ + ++> 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>. +