X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/ddcc5f5bc6336d1b02923e731d25d95380c6dc30..80a779275ae04443c568dca919adb26cf6f5002c:/docs/html/faqmsw.htm diff --git a/docs/html/faqmsw.htm b/docs/html/faqmsw.htm new file mode 100644 index 0000000000..5a117ed58c --- /dev/null +++ b/docs/html/faqmsw.htm @@ -0,0 +1,576 @@ + + + + +wxWidgets for Windows FAQ + + + + + + + + + + +
+ +wxWidgets for Windows FAQ + +
+ +

+ +See also top-level FAQ page. +


+

List of questions in this category

+ +
+ +

Which Windows platforms are supported?

+ +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).

+ +16-bit compilation is only supported for wxWidgets 2.4 and previous versions, +using Visual C++ 1.5 and Borland BC++ 4 to 5. +

+ +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 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 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.

+ +

What about Windows CE?

+ +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.

+ +

What do I need to do for Windows XP?

+ +From wxWidgets 2.5, the XP manifest is included in wx/msw/wx.rc and +so your application will be themed automatically so long as you include wx.rc +in your own .rc file.

+ +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: + +

+<?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"
+
+ +For an explanation of this syntax, please see +this +article. +

+ +

What compilers are supported?

+ +Please see the wxWidgets for Windows install.txt file for up-to-date information, but +currently the following are known to work:

+ +

+

+ + +

Which is the best compiler to use with wxWidgets?

+ +It's partly a matter of taste, but some people 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.

+ +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 +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.

+ +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. However BC++ has trouble compiling large executables statically, +so you need to dynamically link the wxWidgets libraries.

+ +

Is Unicode supported?

+ +Yes, Unicode is fully supported under Windows NT/2000 and there is limited +support for it under Windows 9x using MSLU. +

+ +

Does wxWidgets support double byte fonts (Chinese/Japanese/Korean etc.)?

+ +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. +

+ +

Can you compile wxWidgets as a DLL?

+ +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! +

+ +

How can I reduce executable size?

+ +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. +

+ +

Is wxWidgets compatible with MFC?

+ +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.

+ +

Why do I get errors about setup.h not being found?

+ +When you build the wxWidgets library, setup.h is copied +from include/wx/msw/setup.h to e.g. lib/vc_msw/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/vc_lib/mswd

+ +or if building the static Release library, lib/vc_lib/msw.

+ +See also the wxWiki Contents +for more information.

+ + +

Why do I get errors about FooBarA when I only use FooBar in my program?

+ +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. + +

Why my code fails to compile with strange errors about new operator?

+ +The most common cause of this problem is the memory debugging settings in +wx/msw/setup.h. You have several choices: + + + +Notice that IMHO the first solution is preferable for VC++ users who can use +the VC++ CRT memory debugging features instead. + +

How do I port MFC applications to wxWidgets?

+ +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. + +

Why do I sometimes get bizarre crash problems using VC++ 5/6?

+ +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.

+ +

How are the wxWidgets makefiles edited under Windows?

+ +wxWidgets 2.5.x and above uses Bakefile to generate makefiles, which +is described in technical note 16 under docs/tech in your distribution.

+ +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 on tmake:

+ +

+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 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.

+ +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). +

+ +

+ +

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 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
+
+ +

+ +

Why are menu hotkeys or shortcuts not working in my application?

+ +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.

+ +

Why can I not write to the HKLM part of the registry with wxRegConfig?

+ +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 +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);
+}
+
+ +

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. + + +
+ + + +