Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fixed source for WinCE compatibility

Browse Source 
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@25842 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Julian Smart
2004-02-17 10:06:26 +00:00
parent 2eb85fe466
commit d61c1a6f21
21 changed files with 1228 additions and 154 deletions
Download Patch File Download Diff File Expand all files Collapse all files

73
docs/html/faqmsw.htm
View File

@@ -1,4 +1,3 @@
<HTML>
<HEAD>
@@ -45,6 +44,7 @@ See also <a href="faq.htm">top-level FAQ page</a>.
<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>
@@ -75,13 +75,7 @@ without ever needing a copy of Microsoft Windows. See the Technical Note on the
<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&#39;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 &#39;minimal&#39; sample), shoehorning wxWindows 2 into a Windows CE device&#39;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>
@@ -137,18 +131,17 @@ Please see the wxWindows 2 for Windows install.txt file for up-to-date informati
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>
@@ -178,24 +171,20 @@ wxWindows.
<h3><a name="unicode">Is Unicode supported?</a></h3>
Yes, Unicode is fully supported under Windows NT/2000 (Windows 9x don&#39;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&#39;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&#39;t now whether it works on non W2K systems, because I&#39;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>
@@ -247,7 +236,7 @@ functionality using MFC.<P>
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&#39;re building). So you need to add
this include path if building using the static Debug library:<P>
lib/mswd<P>
@@ -345,7 +334,7 @@ example) and regenerate the makefile using tmake.<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&#39;s a Perl5 program and so it needs Perl (doh). There is a binary for
It&#39;s a Perl5 program and so it needs Perl (doh). There is a binary for
Windows (available from the same page), but I haven&#39;t used it, so
I don&#39;t know if it works as flawlessly as "perl tmake" does (note
for people knowing Perl: don&#39;t try to run tmake with -w, it won&#39;t
@@ -354,7 +343,7 @@ just go to distrib/msw/tmake and type<P>
<pre>tmake -t b32 wxwin.pro -o ../../src/msw/makefile.b32</pre><P>
The makefiles are untested - I don&#39;t have any of Borland, Watcom or
The makefiles are untested - I don&#39;t have any of Borland, Watcom or
Symantec and I don&#39;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
@@ -461,7 +450,7 @@ First, you can use wxRegKey directly, for example:
regKey.SetName(idName);
{
wxLogNull dummy;
wxLogNull dummy;
if (!regKey.Create())
{
idName = wxT("HKEY_CURRENT_USER\\SOFTWARE\\My Company\\My Product\\Stuff\\");
@@ -506,6 +495,20 @@ for the current status.
<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>