X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/8c69597207853b0495c4e0233d4d6cdf949753d1..4e4dc03dcce4f881bcf8ca3586128ddf40ba0eea:/docs/html/faqmsw.htm diff --git a/docs/html/faqmsw.htm b/docs/html/faqmsw.htm index 58dca23c94..30970bb620 100644 --- a/docs/html/faqmsw.htm +++ b/docs/html/faqmsw.htm @@ -1,18 +1,19 @@ + wxWindows 2 for Windows FAQ - + - +
- @@ -26,9 +27,11 @@ See also top-level FAQ page.

Which Windows platforms are supported?

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 @@ -76,6 +81,37 @@ 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.

+

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

What compilers are supported?

Please see the wxWindows 2 for Windows install.txt file for up-to-date information, but @@ -126,6 +162,22 @@ wxWindows. Yes, Unicode is fully supported under Windows NT/2000 (Windows 9x don't have Unicode support anyhow). +

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

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

+

Can you compile wxWindows 2 as a DLL?

Yes (using the Visual C++ or Borland C++ makefile), but be aware that distributing DLLs is a thorny issue @@ -152,10 +204,11 @@ 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 is UPX. +

Is wxWindows compatible with MFC?

@@ -322,6 +375,63 @@ This can happen if you have a child window intercepting EVT_CHAR events and swal all keyboard input. You should ensure that event.Skip() is called for all input that isn'used by the event handler. +

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 +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);
+}
+
- -wxWindows 2 for Windows FAQ + + +wxWindows 2 for Windows FAQ