-|
-
-wxWindows 2 for Windows FAQ
+ |
+
+wxWindows 2 for Windows FAQ
|
@@ -26,25 +27,31 @@ See also top-level FAQ page.
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).
+Windows 95, Windows 98, Windows NT, Windows 2000, and Windows XP. A Windows CE
+version is being looked into (see below).
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
@@ -56,14 +63,13 @@ 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.
-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.
@@ -76,6 +82,54 @@ 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
storage should not be a problem.
+
+
+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 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.
+
+
Please see the wxWindows 2 for Windows install.txt file for up-to-date information, but
@@ -126,6 +180,22 @@ wxWindows.
Yes, Unicode is fully supported under Windows NT/2000 (Windows 9x don't
have Unicode support anyhow).
+
+
+An answer from Klaus Goedde:
+
+"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."
+
+
Yes (using the Visual C++ or Borland C++ makefile), but be aware that distributing DLLs is a thorny issue
@@ -145,17 +215,26 @@ You can compile wxWindows as a DLL (see above, VC++/BC++ only at present). You s
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.
-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
+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.
+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.
+
@@ -163,6 +242,25 @@ There is a sample which demonstrates MFC and wxWindows code co-existing in the s
application. However, don't expect to be able to enable wxWindows windows with OLE-2
functionality using MFC.
+
+
+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
@@ -320,8 +418,76 @@ 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.
+
+
+
+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.
+
+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.
+
+