X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/fc2171bd4c660b8554dae2a1cbf34ff09f3032a6..c8c77ee2af68bcea8ba157b4d5a4e2cd5b4912bd:/docs/html/faqmsw.htm diff --git a/docs/html/faqmsw.htm b/docs/html/faqmsw.htm deleted file mode 100644 index aa0dcbe3cb..0000000000 --- a/docs/html/faqmsw.htm +++ /dev/null @@ -1,517 +0,0 @@ - - - - -wxWidgets 2 for Windows FAQ - - - - - - - - - - -
- -wxWidgets 2 for Windows FAQ - -
- -

- -See also top-level FAQ page. -


-

List of questions in this category

- -
- -

Which Windows platforms are 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).

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

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

- -

What about Windows CE?

- -This port is largely complete. For further information, see the wxEmbedded page.

- -

What do I need to do for Windows XP?

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

- -

What compilers are supported?

- -Please see the wxWidgets 2 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 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 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. - -

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

- -

Can you compile wxWidgets 2 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/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.

- - -

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?

- -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 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{/a>

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

- - - - - -