*** empty log message ***
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@30073 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
parent
dbd94b7501
commit
c6900c006b
@ -140,10 +140,10 @@ platform-independent code, such as the wxTreeCtrl and wxListCtrl classes.<P>
|
||||
No. This is a much-discussed topic that has (many times) ended with the conclusion that it is in
|
||||
wxWidgets' best interests to avoid use of templates. Not all compilers can handle
|
||||
templates adequately so it would dramatically reduce the number of compilers
|
||||
and platforms that could be supported. It would also be undersirable to make
|
||||
and platforms that could be supported. It would also be undesirable to make
|
||||
wxWidgets dependent on another large library that may have to be downloaded and installed.
|
||||
In addition, use of templates can lead to executable bloat, which is something
|
||||
wxWidgets 2 is strenously trying to avoid.<P>
|
||||
wxWidgets 2 is strenuously trying to avoid.<P>
|
||||
|
||||
The standard C++ string class is not used, again because it is not available to all compilers,
|
||||
and it is not necessarily a very efficient implementation. Also, we retain more flexibility
|
||||
|
@ -49,7 +49,7 @@ often abbreviated to wxGTK. wxGTK has a separate home page <a href="http://www.f
|
||||
<h3><a name="locale">Why doesn't reading floating point numbers work when using wxWidgets?</a></h3>
|
||||
|
||||
If your program reads the floating point numbers in the format <tt>123.45</tt>
|
||||
from a file, it may suddently start returning just <tt>123</tt> instead of the
|
||||
from a file, it may suddenly start returning just <tt>123</tt> instead of the
|
||||
correct value on some systems -- which is all the more mysterious as the same
|
||||
code in a standalone program works just fine.
|
||||
|
||||
|
@ -32,7 +32,7 @@ See also <a href="faq.htm">top-level FAQ page</a>.
|
||||
<li><a href="#compilers">What compilers are supported?</a></li>
|
||||
<li><a href="#filetypes">How does CVS handle file types/creators under Mac OS 8.x /9.x?</a></li>
|
||||
<li><a href="#filetypesx">How does CVS handle file types/creators under Mac OS X? </a></li>
|
||||
<li><a href="#cwpro53">What steps are required to build wxMac using CodeWarrior P ro 5.3?</a></li>
|
||||
<li><a href="#cwpro53">What steps are required to build wxMac using CodeWarrior Pro 5.3?</a></li>
|
||||
<li><a href="#buildx">What steps are required to build wxMac under Mac OS X?</a></li>
|
||||
<li><a href="#settings">What important settings are required in the CodeWarrior Project Preferences?</a></li>
|
||||
<li><a href="#smarterrors">What are the smart preprocessing errors with the Apple Developer Tools?</a></li>
|
||||
@ -200,7 +200,7 @@ This error can sometimes be corrected or avoided by modifying the source code. H
|
||||
Because wxWidgets does not have a specific API for the <i>About</i> menu item or the <i>Help</i> menu, the Mac OS port uses some static variables to help the engine make the right decisions:
|
||||
<ul>
|
||||
<li>It assumes that the <i>About</i> menu item is part of a <i>Help</i> menu.
|
||||
<li>The title of the <i>Help</i> menu is stored in <code>wxApp::s_macHelpMenuTitleName</code>, it defaults to "&Help", but you can change it in your constructor to your specific menu title.
|
||||
<li>The title of the <i>Help</i> menu is stored in <code>wxApp::s_macHelpMenuTitleName</code>, it defaults to "&Help", but you can change it in your constructor to your specific menu title.
|
||||
<li>The item Id of the <i>About</i> menu is stored in <code>wxApp::s_macAboutMenuItemID</code>, it defaults to <code>wxID_ABOUT</code>, but can be changed as well to suit your needs.
|
||||
<li>The other items of the wxWidgets help menu are appended to the Mac OS <i>Help</i> menu and the translation of Ids is handled transparently for your application.
|
||||
</ul>
|
||||
|
@ -65,7 +65,7 @@ system is in preparation.
|
||||
|
||||
<h3><a name="dialoged">Does Dialog Editor work with wxWidgets for Motif?</a></h3>
|
||||
|
||||
Suport for Dialog Editor is almost there, but there are some wrinkles to iron
|
||||
Support for Dialog Editor is almost there, but there are some wrinkles to iron
|
||||
out. You may find it's useful though: compile it and see.
|
||||
<P>
|
||||
|
||||
|
@ -46,7 +46,7 @@ See also <a href="faq.htm">top-level FAQ page</a>.
|
||||
<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="#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="#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>
|
||||
</ul>
|
||||
<hr>
|
||||
@ -359,7 +359,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've tagged the ol makefiles as MAKEFILES_WITHOUT_TMAKE
|
||||
will be needed). I've tagged the old 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 +437,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 writeable by a user with Administrator privileges. In theory,
|
||||
only supposed to be writable 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>
|
||||
@ -525,7 +525,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 proprieties dialog in VC6/7.
|
||||
page/subitem of the "C++" tab/item in the project properties 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 +538,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 erros when using wxWidgets with DirectShow?</a></h3>
|
||||
<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:
|
||||
|
Loading…
Reference in New Issue
Block a user