X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/0bc9b25e9a0218d5ddc1d12c40dd96216bb275e7..3520ad4b92d6035da93978ad9a015f64e81dd3e2:/docs/html/faqmsw.htm diff --git a/docs/html/faqmsw.htm b/docs/html/faqmsw.htm index b373e725de..30970bb620 100644 --- a/docs/html/faqmsw.htm +++ b/docs/html/faqmsw.htm @@ -1,18 +1,19 @@ + <HTML> <HEAD> <TITLE>wxWindows 2 for Windows FAQ</TITLE> </HEAD> -<BODY BGCOLOR=#FFFFFF TEXT=#000000 LINK=#FF0000 VLINK=#000000> +<BODY BGCOLOR=#FFFFFF TEXT=#000000 VLINK="#00376A" LINK="#00529C" ALINK="#313063"> <font face="Arial, Lucida Sans, Helvetica"> -<table width=100% border=4 cellpadding=5 cellspacing=0> +<table width=100% border=0 cellpadding=3 cellspacing=0> <tr> -<td bgcolor="#660000"> +<td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif"> <font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF"> -wxWindows 2 for Windows FAQ +<b>wxWindows 2 for Windows FAQ</b> </font> </td> </tr> @@ -22,17 +23,39 @@ wxWindows 2 for Windows FAQ See also <a href="faq.htm">top-level FAQ page</a>. <hr> +<h3>List of questions in this category</h3> +<ul> +<li><a href="#platforms">Which Windows platforms are supported?</a></li> +<li><a href="#wince">What about Windows CE?</a></li> +<li><a href="#winxp">What do I need to do for Windows XP?</a></li> +<li><a href="#compilers">What compilers are supported?</a></li> +<li><a href="#bestcompiler">Which is the best compiler to use with wxWindows 2?</a></li> +<li><a href="#unicode">Is Unicode supported?</a></li> +<li><a href="#doublebyte">Does wxWindows support double byte fonts (Chinese/Japanese/Korean etc.)?</a></li> +<li><a href="#dll">Can you compile wxWindows 2 as a DLL?</a></li> +<li><a href="#exesize">How can I reduce executable size?</a></li> +<li><a href="#mfc">Is wxWindows compatible with MFC?</a></li> +<li><a href="#newerrors">Why my code fails to compile with strange errors about new operator?</a></li> +<li><a href="#mfcport">How do I port MFC applications to wxWindows?</a></li> +<li><a href="#crash">Why do I sometimes get bizarre crash problems using VC++ 5/6?</a></li> +<li><a href="#makefiles">How are the wxWindows makefiles edited under Windows?</a></li> +<li><a href="#vcdebug">How do you use VC++'s memory leak checking instead of that in wxWindows?</a></li> +<li><a href="#shortcutproblem">Why are menu hotkeys or shortcuts not working in my application?</a></li> +<li><a href="#regconfig">Why can I not write to the HKLM part of the registry with wxRegConfig?</a></li> +</ul> +<hr> -<h3>Which Windows platforms are supported?</h3> +<h3><a name="platforms">Which Windows platforms are supported?</a></h3> wxWindows 2 can be used to develop and deliver applications on Windows 3.1, Win32s, -Windows 95, Windows 98, and Windows NT. A Windows CE version is being looked into (see below).<P> +Windows 95, Windows 98, Windows NT, Windows 2000, and Windows XP. A Windows CE +version is being looked into (see below).<P> 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 +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. <P> 16-bit compilation is supported under Visual C++ 1.5, and Borland BC++ 4 to 5. @@ -48,17 +71,48 @@ using wxGTK or wxMotif, then check/debug your wxWindows for Windows programs with TWIN32, 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.<P> -<h3>What about Windows CE?</h3> +<h3><a name="wince">What about Windows CE?</a></h3> 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. But there's no doubt that it will be possible, albeit +as Windows CE requires. But there's no doubt that it will be possible, albeit by mostly cutting down wxWindows 2 API functionality, and adding a few classes here and there. Since wxWindows for 2 produces small binaries (less than 300K for -the statically-linked 'minimal' sample), shoehorning wxWindows 2 into a Windows CE device's limited +the statically-linked 'minimal' sample), shoehorning wxWindows 2 into a Windows CE device's limited storage should not be a problem.<P> -<h3>What compilers are supported?</h3> +<h3><a name="winxp">What do I need to do for Windows XP?</a></h3> + +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: + +<pre> +<?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> +</pre> + +<h3><a name="compilers">What compilers are supported?</a></h3> Please see the wxWindows 2 for Windows install.txt file for up-to-date information, but currently the following are known to work:<P> @@ -77,43 +131,58 @@ currently the following are known to work:<P> There is a linking problem with Symantec C++ which I hope someone can help solve. <P> -<h3>Which is the best compiler to use with wxWindows 2?</h3> +<h3><a name="bestcompiler">Which is the best compiler to use with wxWindows 2?</a></h3> -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 +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.<P> -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.<P> +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.<P> -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).<P> +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).<P> -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.<P> 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.<P> -Watcom C++ is a little slow and the debugger is not really up to today's standards.<P> +Watcom C++ is a little slow and the debugger is not really up to today's standards.<P> + +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. + +<h3><a name="unicode">Is Unicode supported?</a></h3> + +Yes, Unicode is fully supported under Windows NT/2000 (Windows 9x don't +have Unicode support anyhow). -<h3>Is Unicode supported?</h3> +<h3><a name="doublebyte">Does wxWindows support double byte fonts (Chinese/Japanese/Korean etc.)?</a></h3> -Not yet, although there are other internationalisation features.<P> +An answer from <a href="mailto:goedde@logosoft.de">Klaus Goedde</a>:<p> -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 above), and will probably be added in time for version 2.1.<P> +"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.<P> -<h3>Can you compile wxWindows 2 as a DLL?</h3> +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." +<P> + +<h3><a name="dll">Can you compile wxWindows 2 as a DLL?</a></h3> 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 wxWindows applications +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 wxWindows applications and have limited hard disk space.<P> With a DLL approach, and with different versions and configurations of wxWindows @@ -122,7 +191,7 @@ negating the point of using DLLs. Of course, this is not a problem just associat wxWindows! <P> -<H3>How can I reduce executable size?</H3> +<h3><a name="exesize">How can I reduce executable size?</a></h3> You can compile wxWindows 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 @@ -132,20 +201,237 @@ Statically-linked wxWindows 2 programs are smaller than wxWindows 1.xx programs, 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.<P> +by your application. So for example, the 'minimal' sample is less than 300KB using VC++ 6.<P> If you want to distribute really small executables, you can -use <a href="http://www.icl.ndirect.co.uk/petite/" target=_top>Petite</a> +use <a href="http://www.un4seen.com/petite/" target=_top>Petite</a> 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.<P> +use DLLs. Another good compression tool is <a href="http://upx.sourceforge.net/" target=_top>UPX</a>. +<P> -<H3>Is wxWindows compatible with MFC?</H3> +<H3><a name="mfc">Is wxWindows compatible with MFC?</a></H3> 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 +application. However, don't expect to be able to enable wxWindows windows with OLE-2 functionality using MFC.<P> +<H3><a name="newerrors">Why my code fails to compile with strange errors about new operator?</a></H3> + +The most common cause of this problem is the memory debugging settings in +<tt>wx/msw/setup.h</tt>. You have several choices: + +<ul> + <li> Either disable overloading the global operator new completely by + setting <tt>wxUSE_GLOBAL_MEMORY_OPERATORS</tt> and + <tt>wxUSE_DEBUG_NEW_ALWAYS</tt> to 0 in this file + <li> Or leave them on but do <tt>#undef new</tt> after including any + wxWindows headers, like this the memory debugging will be still on + for wxWindows sources but off for your own code +</ul> + +Notice that IMHO the first solution is preferable for VC++ users who can use +the <a href="#vcdebug">VC++ CRT memory debugging features</a> instead. + +<H3><a name="mfcport">How do I port MFC applications to wxWindows?</a></H3> + +Set up your interface from scratch using wxWindows (especially wxDesigner -- +it'll save you a <i>lot</i> 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 wxWindows simultaneously from the beginning - it is easier to +reproduce the initial UI by looking at the behaviour of the MFC +app, not its code. + +<H3><a name="crash">Why do I sometimes get bizarre crash problems using VC++ 5/6?</a></H3> + +Some crash problems can be due to inconsistent compiler +options (and of course this isn't limited to wxWindows). +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.<P> + +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 wxWindows project, set to 'Minimum +Size'. In Dialog Editor project, set to 'Customize: Favor Small +Code' (and no others). This will then work.<P> + +<H3><a name="makefiles">How are the wxWindows makefiles edited under Windows?</a></H3> + +As of wxWindows 2.1, there is a new system written by Vadim Zeitlin, that +generates the makefiles from templates using tmake.<P> + +Here are Vadim's notes:<P> + +<blockquote> +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.<P> + +tmake can be found at +<a href="http://www.troll.no/freebies/tmake.html" target=_new>www.troll.no/freebies/tmake.html</a>. +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<P> + +<pre>tmake -t b32 wxwin.pro -o ../../src/msw/makefile.b32</pre><P> + +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.<P> + +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 ol 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.<P> + +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.<P> + +So now adding a new file to wxWindows 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.<P> + + 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 wxWindows (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<P> + +<pre>tmake -t vc6 wxwin.pro -o ../../wxWindows.dsp</pre><P> + +Then just include this project in any workspace or open it from VC IDE +and it will create a new workspace for you.<P> + +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). +</blockquote> + +<P> + +<H3><a name="vcdebug">How do you use VC++'s memory leak checking instead of that in wxWindows?</a></H3> + +Vadim Zeitlin: + +<pre> +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 +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 +</pre> + +<P> + +<H3><a name="shortcutproblem">Why are menu hotkeys or shortcuts not working in my application?</a></H3> + +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. + +<H3><a name="#regconfig">Why can I not write to the HKLM part of the registry with wxRegConfig?</a></H3> + +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 +need to write to HKLM.<P> + +First, you can use wxRegKey directly, for example: + +<pre> + 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(); + +</pre> + +Or, you can employ this trick suggested by Istvan Kovacs: + +<pre> +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); +} +</pre> </font>