-
<HTML>
<HEAD>
<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>
<li><a href="#access">Is MS Active Accessibility supported?</a></li>
+<li><a href="#dspfmt">Why does Visual C++ complain about corrupted project files??</a></li>
</ul>
<hr>
<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
-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
-storage should not be a problem.<P>
+This port is largely complete. For further information, see the <a href="http://www.wxwindows.org/embedded.htm#wxwince">wxEmbedded</a> page.<P>
<h3><a name="winxp">What do I need to do for Windows XP?</a></h3>
currently the following are known to work:<P>
<ul>
-<li>Visual C++ 1.5, 4.0, 5.0, 6.0
-<li>Borland C++ 4.5, 5.0
-<li>Borland C++Builder 1.0, 3.0
-<li>Watcom C++ 10.6 (WIN32)
-<li>Cygwin b20
+<li>Visual C++ 1.5, 4.0, 5.0, 6.0, 7.0, 7.1
+<li>Borland C++ 4.5, 5.0, 5.5
+<li>Borland C++Builder 1.0, 3.0, X
+<li>Watcom C++ 10.6 (Win32), OpenWatcom 1.0
+<li>Cygwin (using configure)
<li>Mingw32
-<li>MetroWerks CodeWarrior 4
+<li>MetroWerks CodeWarrior (many versions)
+<li>Digital Mars 8.34+
</ul>
<P>
-There is a linking problem with Symantec C++ which I hope someone can help solve.
-<P>
<h3><a name="bestcompiler">Which is the best compiler to use with wxWindows 2?</a></h3>
<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).
+Yes, Unicode is fully supported under Windows NT/2000 and there is limited
+support for it under Windows 9x using <a
+href="http://www.microsoft.com/globaldev/handson/dev/mslu_announce.mspx">MSLU</a>.
+<p>
<h3><a name="doublebyte">Does wxWindows support double byte fonts (Chinese/Japanese/Korean etc.)?</a></h3>
-An answer from <a href="mailto:goedde@logosoft.de">Klaus Goedde</a>:<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>
-
-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>
+For Japanese under Win2000, it seems that wxWindows 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
+<tt>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage=932</tt>
+(default is 1252 for Western). Then you can see all the Japanese letters in
+wxWindows applications.
+<p>
<h3><a name="dll">Can you compile wxWindows 2 as a DLL?</a></h3>
When you build the wxWindows 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
+depends on the configuration you're building). So you need to add
this include path if building using the static Debug library:<P>
lib/mswd<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
+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
<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
+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
regKey.SetName(idName);
{
- wxLogNull dummy;
+ wxLogNull dummy;
if (!regKey.Create())
{
idName = wxT("HKEY_CURRENT_USER\\SOFTWARE\\My Company\\My Product\\Stuff\\");
<P>
+
+<h3><a name="#dspfmt">Why does Visual C++ complain about corrupted project files??</a></h3>
+
+If you have downloaded the wxWindows sources from the cvs using a Unix cvs
+client or downloaded a daily snapshot in <tt>.tar.gz</tt> 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.
+<p>
+Of course, another possibility is to always use only the Windows cvs client
+and to avoid this problem completely.
+<p>
+
</font>
</BODY>
projects / wxWidgets.git / blobdiff