+isn'used by the event handler.<P>
+
+It can also happen if you append the submenu to the parent
+menu {\it before} you have added your menu items. Do the append {\it after} adding
+your items, or accelerators may not be registered properly.<P>
+
+<H3><a name="#regconfig">Why can I not write to the HKLM part of the registry with wxRegConfig?</a></H3>
+
+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 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>
+
+First, you can use wxRegKey directly, for example:
+
+<pre>
+ wxRegKey regKey;
+
+ wxString idName(wxT("HKEY_LOCAL_MACHINE\\SOFTWARE\\My Company\\My Product\\Stuff\\"));
+ idName += packid;
+
+ regKey.SetName(idName);
+
+ {
+ wxLogNull dummy;
+ if (!regKey.Create())
+ {
+ idName = wxT("HKEY_CURRENT_USER\\SOFTWARE\\My Company\\My Product\\Stuff\\");
+ idName += packid;
+ regKey.SetName(idName);
+ if (!regKey.Create())
+ return FALSE;
+ }
+ }
+
+ if (!regKey.SetValue(wxT("THING"), (long) thing)) err += 1;
+
+ regKey.Close();
+
+</pre>
+
+Or, you can employ this trick suggested by Istvan Kovacs:
+
+<pre>
+class myGlobalConfig : public wxConfig
+{
+ myGlobalConfig() :
+ wxConfig ("myApp", "myCompany", "", "", wxCONFIG_USE_GLOBAL_FILE)
+{};
+ bool Write(const wxString& key, const wxString& value);
+}
+
+bool myGlobalConfig::Write (const wxString& key, const wxString& value)
+{
+ wxString path = wxString ("SOFTWARE\\myCompany\\myApp\\") + wxPathOnly(key);
+ wxString new_path = path.Replace ("/", "\\", true);
+ wxString new_key = wxFileNameFromPath (key);
+ LocalKey().SetName (wxRegKey::HKLM, path);
+ return wxConfig::Write (new_key, value);
+}
+</pre>
+
+<H3><a name="#access">Is MS Active Accessibility supported?</a></H3>
+
+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>
+
+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
+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>
+
+<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>
+> 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>.
+</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.
projects / wxWidgets.git / blobdiff