-|
+ |
-wxWindows 2 for Windows FAQ
+wxWidgets 2 for Windows FAQ
|
@@ -22,74 +22,547 @@ wxWindows 2 for Windows FAQ
See also top-level FAQ page.
+List of questions in this category
+
+
+
+
-Is Windows 3.1 supported?
+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).
-Yes! Unlike Microsoft, we have not forgotten users of 16-bit Windows. Most features
+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 Windows 95-specific classes to work, such as wxTaskBar. The wxRegConfig
-class doesn't work either because the Windows 3.1 registry is very simplistic. Check out the 16-bit
+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.
-
What compilers are supported?
+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 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 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.
-Please see the wxWindows 2 for Windows install.txt file for up-to-date information, but
+
+
+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:
+
+
+<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
+<assembly
+ xmlns="urn:schemas-microsoft-com:asm.v1"
+ manifestVersion="1.0">
+<assemblyIdentity
+ processorArchitecture="x86"
+ version="5.1.0.0"
+ type="win32"
+ name="foo.exe"/>
+ <description>Foo program</description>
+ <dependency>
+ <dependentAssembly>
+ <assemblyIdentity
+ type="win32"
+ name="Microsoft.Windows.Common-Controls"
+ version="6.0.0.0"
+ publicKeyToken="6595b64144ccf1df"
+ language="*"
+ processorArchitecture="x86"/>
+ </dependentAssembly>
+ </dependency>
+</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"
+
+
+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.
+
+
+
+
+Please see the wxWidgets 2 for Windows install.txt file for up-to-date information, but
currently the following are known to work:
-- Visual C++ 1.5, 4.0, 5.0, 6.0
-
- Borland C++ 4.5, 5.0
-
- Borland C++Builder 1.0, 3.0
-
- Watcom C++ 10.6 (WIN32)
-
- Cygwin b20
+
- Visual C++ 1.5, 4.0, 5.0, 6.0, 7.0, 7.1
+
- Borland C++ 4.5, 5.0, 5.5
+
- Borland C++Builder 1.0, 3.0, X
+
- Watcom C++ 10.6 (Win32), OpenWatcom 1.0
+
- Cygwin (using configure)
- Mingw32
-
- MetroWerks CodeWarrior 4
+
- MetroWerks CodeWarrior (many versions)
+
- Digital Mars 8.34+
-There is a linking problem with Symantec C++ which I hope someone can help solve.
-
-
Which is the best compiler to use with wxWindows 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.
+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 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.
+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
-it's almost identical to BC++ 5.0 (the same makefiles can be used).
+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
+You can't beat Cygwin's price (free), and you can debug adequately using gdb. However, it's
quite slow to compile since it does not use precompiled headers.
CodeWarrior is cross-platform - you can debug and generate Windows executables from a Mac, but not
the other way around I think - but the IDE is, to my mind, a bit primitive.
-Watcom C++ is a little slow and the debugger is not really up to today's standards.
+Watcom C++ is a little slow and the debugger is not really up to today's standards.
+
+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
+wxWidgets.
+
+
+
+Yes, Unicode is fully supported under Windows NT/2000 and there is limited
+support for it under Windows 9x using MSLU.
+
+
+
+
+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.
+
+
+
+
+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 wxWidgets applications
+and have limited hard disk space.
+
+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
+wxWidgets!
+
+
+
+
+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.
+
+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 (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.
+
+
+
+
+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.
+
+
+
+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:
+
+lib/mswd
+
+or if building the static Release library, lib/msw.
+
+See also the wxWiki Contents
+for more information.
+
+
+
+
+If you get errors like
+
+
+no matching function for call to 'wxDC::DrawTextA(const char[5], int,
+int)'
+
+
+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.
+
+
+
+The most common cause of this problem is the memory debugging settings in
+wx/msw/setup.h. You have several choices:
+
+
+ - Either disable overloading the global operator new completely by
+ 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
+ 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.
+
+
+
+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
+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 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.
+
+
+
+Some crash problems can be due to inconsistent compiler
+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
+symbols, struct packing, etc. are exactly the same for all items in
+the project. After this, delete everything (including PCH) and recompile.
+
+VC++ 5's optimization code seems to be broken and can
+cause problems: this can be seen when deleting an object Dialog
+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 wxWidgets project, set to 'Minimum
+Size'. In Dialog Editor project, set to 'Customize: Favor Small
+Code' (and no others). This will then work.
+
+
+
+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:
+
+
+To use these new makefiles, you don't need anything (but see below).
+However, you should NOT modify them because these files will be
+rewritten when I regenerate them using tmake the next time. So, if
+you find a problem with any of these makefiles (say, makefile.b32)
+you'll need to modify the corresponding template (b32.t in this
+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
+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
+do you any good). Using it extremely simple: to regenerate makefile.b32
+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
+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
+(should I say bugs?) in some of makefiles, some files were not compiled
+without any reason etc. Please test them and notify me about any problems.
+Better yet, modify the template files to generate the correct makefiles
+and check them in.
+
+The templates are described in tmake ref manual (1-2 pages of text)
+and are quite simple. They do contain some Perl code, but my Perl is
+primitive (very C like) so it should be possible for anybody to make
+trivial modifications to it (I hope that only trivial modifications
+will be needed). I've tagged the old makefiles as MAKEFILES_WITHOUT_TMAKE
+in the cvs, so you can always retrieve them and compare the new ones,
+this will make it easier to solve the problems you might have.
+
+Another important file is filelist.txt: it contains the list of all
+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 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.
+
+ Finally, there is also a file vc6.t which I use myself: this one
+generates a project file for VC++ 6.0 (I didn't create vc5.t because
+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 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 wxWidgets.dsp run
+
+
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.
+
+If all goes well, I'm planning to create a template file for Makefile.ams
+under src/gtk and src/motif and also replace all makefiles in the samples
+subdirectories with the project files from which all the others will be
+generated. At least it will divide the number of files in samples
+directory by 10 (and the number of files to be maintained too).
+
+
+
+
+
+
+Vadim Zeitlin:
+
+
+On the VC++ level, it's just the matter of calling _CrtSetDbgFlag() in the very
+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
+ifdefs.
+
+This works quite well: at the end of the program, all leaked blocks with their
+malloc count are shown. This number (malloc count) can be used to determine
+where exactly the object was allocated: for this it's enough to set the variable
+_crtBreakAlloc (look in VC98\crt\srs\dbgheap.c line 326) to this number and
+a breakpoint will be triggered when the block with this number is allocated.
+
+For simple situations it works like a charm. For something more complicated
+like reading uninitialized memory a specialized tool is probably better...
+
+Regards,
+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.
+
+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.
+
+
+
+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 writable by a user with Administrator privileges. In theory,
+only installers should write to HKLM. This is still a point debated by the
+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:
+
+
+ wxRegKey regKey;
+
+ wxString idName(wxT("HKEY_LOCAL_MACHINE\\SOFTWARE\\My Company\\My Product\\Stuff\\"));
+ idName += packid;
+
+ regKey.SetName(idName);
+
+ {
+ wxLogNull dummy;
+ if (!regKey.Create())
+ {
+ idName = wxT("HKEY_CURRENT_USER\\SOFTWARE\\My Company\\My Product\\Stuff\\");
+ idName += packid;
+ regKey.SetName(idName);
+ if (!regKey.Create())
+ return FALSE;
+ }
+ }
+
+ if (!regKey.SetValue(wxT("THING"), (long) thing)) err += 1;
+
+ regKey.Close();
+
+
+
+Or, you can employ this trick suggested by Istvan Kovacs:
+
+
+class myGlobalConfig : public wxConfig
+{
+ myGlobalConfig() :
+ wxConfig ("myApp", "myCompany", "", "", wxCONFIG_USE_GLOBAL_FILE)
+{};
+ bool Write(const wxString& key, const wxString& value);
+}
+
+bool myGlobalConfig::Write (const wxString& key, const wxString& value)
+{
+ wxString path = wxString ("SOFTWARE\\myCompany\\myApp\\") + wxPathOnly(key);
+ wxString new_path = path.Replace ("/", "\\", true);
+ wxString new_key = wxFileNameFromPath (key);
+ LocalKey().SetName (wxRegKey::HKLM, path);
+ return wxConfig::Write (new_key, value);
+}
+
+
+
+
+This is being worked on. Please see this page
+for the current status.
+
+
+
+
+
+
+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.
+
+
+
+
+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 properties 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.
+
+
-Is Unicode supported?
+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
-No, although there are other internationalisation features.
+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>.
+
-However, the issues surrounding Unicode support have been looked into so we know
-what we need to do, and have some header files ready to use containing appropriate
-type definitions. Just about every file in wxWindows will need changes, due to the
-pervasive nature of characters and character arrays. Unicode support is needed
-for the port to Windows CE (see below).
-
What about Windows CE?
+
-This is under consideration, though we need to get wxWindows Unicode-aware first.
-There are other interesting issues, such as how to combine the menubar and toolbar APIs
-as Windows CE requires.
+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.