]> git.saurik.com Git - wxWidgets.git/blobdiff - docs/html/faqmsw.htm
use unsgined int instead of int for 1 bit bitfields (SGI CC warning fix)
[wxWidgets.git] / docs / html / faqmsw.htm
index ff37bf0d35b6946ef6dcb11bf8f7a4efc9c53d24..b3c333d71f0ea8500f7d952cbdf13943412497c4 100644 (file)
@@ -44,7 +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>
+<li><a href="#dspfmt">Why does Visual C++ complain about corrupted project files?</a></li>
 <li><a href="#crtmismatch">Visual C++ gives errors about multiply defined symbols, what can I do?</a></li>
 <li><a href="#directx">Why do I get compilation errors when using wxWidgets with DirectShow?</a></li>
 <li><a href="#handlewm">How do I handle Windows messages in my wxWidgets program?</a></li>
@@ -322,6 +322,10 @@ Code&#39; (and no others). This will then work.<P>
 
 <H3><a name="makefiles">How are the wxWidgets makefiles edited under Windows?</a></H3>
 
+wxWidgets 2.5.x and above uses Bakefile to generate makefiles, which
+is described in technical note 16 under docs/tech in your distribution.
+For 2.4.x, the following explanation applies.<P>
+
 As of wxWidgets 2.1, there is a new system written by Vadim Zeitlin, that
 generates the makefiles from templates using tmake.<P>
 
@@ -337,7 +341,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
@@ -346,7 +350,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
@@ -359,7 +363,7 @@ 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&#39;ve tagged the old makefiles as MAKEFILES_WITHOUT_TMAKE
+will be needed). I&#39;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.<P>
 
@@ -437,7 +441,7 @@ your items, or accelerators may not be registered properly.<P>
 
 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 writable by a user with Administrator privileges. In theory,
+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.<P>
@@ -453,7 +457,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\\");
@@ -499,7 +503,7 @@ for the current status.
 <P>
 
 
-<h3><a name="#dspfmt">Why does Visual C++ complain about corrupted project files??</a></h3>
+<h3><a name="#dspfmt">Why does Visual C++ complain about corrupted project files?</a></h3>
 
 If you have downloaded the wxWidgets sources from the cvs using a Unix cvs
 client or downloaded a daily snapshot in <tt>.tar.gz</tt> format, it is likely
@@ -525,7 +529,7 @@ when linking your project, this means that you used different versions of CRT
 project. Visual C++ provides static or dynamic and multithread safe or not
 versions of CRT for each of debug and release builds, for a total of 8
 libraries. You can choose among them by going to the "Code generation"
-page/subitem of the "C++" tab/item in the project properties dialog in VC6/7.
+page/subitem of the "C++" tab/item in the project proprieties dialog in VC6/7.
 <p>
 To avoid problems, you <strong>must</strong> use the same one for all
 components of your project. wxWindows uses multithread safe DLL version of the
@@ -538,7 +542,7 @@ slightly smaller and faster.
 But the most important thing is to use the <strong>same</strong> CRT setting for
 all components of your project.
 
-<h3><a name="#directx">Why do I get compilation errors when using wxWidgets with DirectShow?</a></h3>
+<h3><a name="#directx">Why do I get compilation erros when using wxWidgets with DirectShow?</a></h3>
 
 If you get errors when including Microsoft DirectShow or DirectDraw headers,
 the following message from Peter Whaite could help:
@@ -550,9 +554,9 @@ the following message from Peter Whaite could help:
 
 The reason for this is that __WXDEBUG__ is also used by the DXSDK (9.0
 in my case) to &#39;#pragma once&#39; the contents of
-DXSDK/Samples/C++/DirectShow/BaseClasses/wxdebug.h.  So if __WXDEBUG__
+DXSDK/Samples/C++/DirectShow/BaseClasses/wxdebug.h. So if __WXDEBUG__
 is defined, then wxdebug.h doesn&#39;t get included, and the assert macros
-don&#39;t get defined.  You have to #undef __WXDEBUG__ before including the
+don&#39;t get defined. You have to #undef __WXDEBUG__ before including the
 directshow baseclass&#39;s &lt;streams.h&gt;.
 </blockquote>