<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 erros when using wxWidgets with DirectShow?</a></li>
+<li><a href="#handlewm">How do I handle Windows messages in my wxWidgets program?</a></li>
</ul>
<hr>
<h3><a name="wince">What about Windows CE?</a></h3>
-This port is largely complete. For further information, see the <a href="http://www.wxwi
ndows.org/embedded.htm#wxwince">wxEmbedded</a> page.<P>
+This port is largely complete. For further information, see the <a href="http://www.wxwi
dgets.org/embedded.htm#wxwince">wxEmbedded</a> page.<P>
<h3><a name="winxp">What do I need to do for Windows XP?</a></h3>
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.
+Also, run 'strip' after linking to remove all traces of debug info.
<P>
<H3><a name="mfc">Is wxWidgets compatible with MFC?</a></H3>
or if building the static Release library, lib/msw.<P>
-See also the <a href="http://wiki.wxwindows.org/wiki.pl?Table_Of_Contents">wxWiki Contents</a>
+See also the <a href="http://wiki.wxwidgets.org/wiki.pl?Table_Of_Contents">wxWiki Contents</a>
for more information.<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>
<H3><a name="#access">Is MS Active Accessibility supported?</a></H3>
-This is being worked on. Please see <a href="http://www.wxwindows.org/access.htm">this page</a>
+This is being worked on. Please see <a href="http://www.wxwidgets.org/access.htm">this page</a>
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
and to avoid this problem completely.
<p>
+<h3><a name="#crtmismatch">Visual C++ gives errors about multiply defined symbols, what can I do?</a></h3>
+
+If you get errors like this
+
+<pre>
+MSVCRTD.lib(MSVCRTD.dll) : error LNK2005: _xxxxxx already defined in LIBCD.lib(yyyyy.obj)
+</pre>
+
+when linking your project, this means that you used different versions of CRT
+(C Run-Time) library for wxWindows (or possibly another library) and the main
+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 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
+CRT which is a good choice but may be problematic when distributing your
+applications if you don't include the CRT DLL in your installation -- in this
+case you may decide to switch to using a static CRT version. If you build with
+<tt>wxUSE_THREADS == 0</tt> you may also use the non MT-safe version as it is
+slightly smaller and faster.
+<p>
+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>
+
+If you get errors when including Microsoft DirectShow or DirectDraw headers,
+the following message from Peter Whaite could help:
+<blockquote><pre>
+> This causes compilation errors within DirectShow:
+>
+> wxutil.h(125) : error C2065: 'EXECUTE_ASSERT' : undeclared identifier
+> amfilter.h(1099) : error C2065: 'ASSERT' : undeclared identifier
+
+The reason for this is that __WXDEBUG__ is also used by the DXSDK (9.0
+in my case) to '#pragma once' the contents of
+DXSDK/Samples/C++/DirectShow/BaseClasses/wxdebug.h. So if __WXDEBUG__
+is defined, then wxdebug.h doesn't get included, and the assert macros
+don't get defined. You have to #undef __WXDEBUG__ before including the
+directshow baseclass's <streams.h>.
+</pre></blockquote>
+
+<h3><a name="#handlewm">How do I handle Windows messages in my wxWidgets program?</a></h3>
+
+To handle a Windows message you need to override a virtual
+<tt>MSWWindowProc()</tt> method in a wxWindow-derived class. You should then
+test if <tt>nMsg</tt> parameter is the message you need to process and perform
+the necessary action if it is or call the base class method otherwise.
+
+
</font>
</BODY>
projects / wxWidgets.git / blobdiff