+
<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>
+<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="#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="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>
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've tagged the old makefiles as MAKEFILES_WITHOUT_TMAKE
+will be needed). I'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>
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>
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>
+<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
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
If you get errors when including Microsoft DirectShow or DirectDraw headers,
the following message from Peter Whaite could help:
-<blockquote>
+<blockquote><pre>
> This causes compilation errors within DirectShow:
>
> wxutil.h(125) : error C2065: 'EXECUTE_ASSERT' : undeclared identifier
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>.
-</blockquote>
+</pre></blockquote>
<h3><a name="#handlewm">How do I handle Windows messages in my wxWidgets program?</a></h3>
projects / wxWidgets.git / blobdiff