-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.
+wxWindows 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 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, +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 +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 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.
- -In a wxTextCtrl control you have to set the window style "wxTE_RICH", otherwise this control shows the wrong -letters. - -I don't now whether it works on non W2K systems, because I'm just starting using wxWindows." -
+For Japanese under Win2000, it seems that wxWindows 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. +
-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 wxWindows, 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 wxWindows 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 +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.
+ + +
+
+or similar ones for the other functions, i.e. the compiler error messages +mention the function with the 'A' suffix while you didn't +use it in your code, the explanation is that you had included +<windows.h> header which redefines many symbols to have such +suffix (or 'W' in the Unicode builds). + +
+The fix is to either not include <windows.h> at all or include +"wx/msw/winundef.h" immediately after it. +
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 @@ -292,7 +343,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 @@ -373,7 +424,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.
+ + +
+Of course, another possibility is to always use only the Windows cvs client +and to avoid this problem completely. +
+