<html>
<head>
-<title>wxWidgets 2 FAQ</title>
+<title>wxWidgets FAQ</title>
</head>
<body bgcolor=#ffffff text=#000000 vlink="#00376a" link="#00529c" alink="#313063">
<tr>
<td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif">
<font size=+1 face="arial, lucida sans, helvetica" color="#ffffff">
-<b>wxWidgets 2 FAQ</b>
+<b>wxWidgets FAQ</b>
</font>
</td>
</tr>
+
<HTML>
<HEAD>
-<TITLE>wxWidgets 2 FAQ: General</TITLE>
+<TITLE>wxWidgets FAQ: General</TITLE>
</HEAD>
<BODY BGCOLOR=#FFFFFF TEXT=#000000 VLINK="#00376A" LINK="#00529C" ALINK="#313063">
<tr>
<td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif">
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
-<b>wxWidgets 2 FAQ: General</b>
+<b>wxWidgets FAQ: General</b>
</font>
</td>
</tr>
<h3>List of questions in this category</h3>
<ul>
<li><a href="#whatis">What is wxWidgets?</a></li>
-<li><a href="#licence">Can I use wxWidgets 2 for both proprietary projects, and GPL'ed projects?</a></li>
+<li><a href="#licence">Can I use wxWidgets for both proprietary projects, and GPL'ed projects?</a></li>
<li><a href="#support">Is there support?</a></li>
<li><a href="#users">Who uses wxWidgets?</a></li>
<li><a href="#platforms">What platforms are supported by wxWidgets?</a></li>
<li><a href="#exceptions">How to use C++ exceptions with wxWidgets?</a></ li>
<li><a href="#dev">How is wxWidgets being developed?</a></li>
<li><a href="#distrib">How is wxWidgets distributed?</a></li>
+<!--
<li><a href="#future">What are the plans for the future?</a></li>
+-->
<li><a href="#base">What is wxBase?</a></li>
<li><a href="#univ">What is wxUniversal?</a></li>
<li><a href="#jave">What about Java?</a></li>
and Anthemion Software's <a href="http://www.anthemion.co.uk/dialogblocks/" target=_new>DialogBlocks</a>
are two commercial examples, but there are others: see the <a href="lnk_tool.htm">Useful Tools</a> page.<P>
-You don't have to use C++ to use wxWidgets: there is a <a href="http://wxpython.org">Python interface</a> for wxWidgets 2,
+You don't have to use C++ to use wxWidgets: there is a <a href="http://wxpython.org">Python interface</a> for wxWidgets,
and also a <a href="http://wxperl.sourceforge.net" target=_top>Perl interface</a>.
<P>
-<h3><a name="licence">Can I use wxWidgets 2 for both proprietary (commercial) projects, and GPL'ed projects?</a></h3>
+<h3><a name="licence">Can I use wxWidgets for both proprietary (commercial) projects, and GPL'ed projects?</a></h3>
Yes. Please see the <a href="newlicen.htm">licence</a> for details, but basically
you can distribute proprietary binaries without distributing any source code, and neither will wxWidgets
conflict with GPL code you may be using or developing with it.
<P>
-The conditions for using wxWidgets 2 are the same whether you are a personal, academic
+The conditions for using wxWidgets are the same whether you are a personal, academic
or commercial developer.
<P>
and his <a href="http://www.osafoundation.org" target=_new>Open Source Applications Foundation</a>.
<P>
-<H3><a name="platforms">What platforms are supported by wxWidgets 2?</a></H3>
+<H3><a name="platforms">What platforms are supported by wxWidgets?</a></H3>
<ul>
<li>Windows 3.1, Windows 95/98, Windows NT, Windows 2000, Windows ME.
</ul>
<P>
-<H3><a name="specific">How does wxWidgets 2 support platform-specific
+<H3><a name="specific">How does wxWidgets support platform-specific
features?</a></H3>
This is a hotly-debated topic amongst the developers. My own philosophy
Currently resources such as bitmaps and icons are handled in a platform-specific
way, but it is hoped to reduce this dependence in due course.<P>
-Another reason why wxWidgets 2 is not a 'lowest common denominator' toolkit is that
+Another reason why wxWidgets is not a 'lowest common denominator' toolkit is that
some functionality missing on some platform has been provided using generic,
platform-independent code, such as the wxTreeCtrl and wxListCtrl classes.<P>
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 strenuously trying to avoid.<P>
+wxWidgets 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
<P>
-<H3><a name="richedit">Is there a rich edit/markup widget for wxWidgets 2?</a></H3>
+<H3><a name="richedit">Is there a rich edit/markup widget for wxWidgets?</a></H3>
These are the possibilities so far:<P>
from <a href="cvs.htm">cvs</a>.
<p>
+<!--
<H3><a name="future">What are the plans for the future?</a></H3>
-Currently we're working too hard on getting wxWidgets finished (are GUI toolkits ever
-finished?) to think very far ahead. However, we know we want to make wxWidgets as robust
-and well-publicised as possible. We also want to aim for better platform-independence of
-resources such as icons and bitmaps, standardising on PNG and XPM for all platforms.<P>
-
-Other possibilities include: DCOM/CORBA compatibility; a wxWidgets book;
-<a href="http://wxworkshop.sourceforge.net/">wxWorkshop</a>, an IDE;
-other platforms, especially embedded systems; other interface abilities such as speech output.<P>
+TODO
-We will investigate the possibility of compiler or operating system vendors bundling wxWidgets with
-their product.<P>
+<p>
-The high-level goal of wxWidgets is to be thought of as the number one C++ framework,
-for virtually any platform. Move over, MFC!<P>
+-->
<h3><a name="base">What is wxBase?</a></h3>
+
<HTML>
<HEAD>
-<TITLE>wxWidgets 2 for GTK FAQ</TITLE>
+<TITLE>wxWidgets for GTK FAQ</TITLE>
</HEAD>
<BODY BGCOLOR=#FFFFFF TEXT=#000000 VLINK="#00376A" LINK="#00529C" ALINK="#313063">
<tr>
<td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif">
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
-<b>wxWidgets 2 for GTK FAQ</b>
+<b>wxWidgets for GTK FAQ</b>
</font>
</td>
</tr>
<P>
-See also <a href="faq.htm">top-level FAQ page</a>
+See also <a href="faq.htm">top-level FAQ page</a>
and <a href="faqunx.htm">Unix FAQ page</a>.
<hr>
<h3>List of questions in this category</h3>
<ul>
-<li><a href="#wxgtk">What is wxWidgets 2 for GTK+?</a></li>
+<li><a href="#wxgtk">What is wxWidgets for GTK+?</a></li>
<li><a href="#locale">Why doesn't reading floating point numbers work when using wxWidgets?</a></li>
<li><a href="#gnome">Does wxGTK have GNOME support?</a></li>
<li><a href="#redhat">Warning about GTK libraries supplied with RedHat</a></li>
<hr>
-<h3><a name="wxgtk">What is wxWidgets 2 for GTK?</a></h3>
+<h3><a name="wxgtk">What is wxWidgets for GTK?</a></h3>
-wxWidgets
2 for GTK is a port of wxWidgets to the <a href="http://www.gimp.org/gtk" target=_top>GTK+ toolkit</a>,
-which is freely available for most flavours of Unix with X. wxWidgets 2 for GTK is
+wxWidgets for GTK is a port of wxWidgets to the <a href="http://www.gimp.org/gtk" target=_top>GTK+ toolkit</a>,
+which is freely available for most flavours of Unix with X. wxWidgets for GTK is
often abbreviated to wxGTK. wxGTK has a separate home page <a href="http://www.freiburg.linux.de/~wxxt" target=_top>here</a>.
<P>
<HTML>
<HEAD>
-<TITLE>wxWidgets 2 for Mac FAQ</TITLE>
+<TITLE>wxWidgets for Mac FAQ</TITLE>
</HEAD>
<BODY BGCOLOR=#FFFFFF TEXT=#000000 VLINK="#00376A" LINK="#00529C" ALINK="#313063">
<tr>
<td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif">
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
-<b>wxWidgets 2 for Mac FAQ</b>
+<b>wxWidgets for Mac FAQ</b>
</font>
</td>
</tr>
<ul>
<li><a href="#release">Where should I download wxMac from?</a></li>
<li><a href="#macplat">Which Mac platforms are supported?</a></li>
-<li><a href="#macosx">How is the Mac OS X port different from the Classic Mac OS port?</a></li>
-<li><a href="#macclassic">How are improvements to the Classic Mac OS port integrated into the Mac OS X port?</a></li>
<li><a href="#compilers">What compilers are supported?</a></li>
+<li><a href="#conflicts">What can I do if I get conflicts between different installed versions of wxWidgets?</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>
<h3><a name="release">Where should I download wxMac from?</a></h3>
Please see the <a href="dl_mac2.htm">downloads page</a>.
-The version of wxMac in CVS advances quickly so it is recommended that you download the
-the sources from the <a href="cvs.htm">CVS trunk</a>.
-There is also a wxMac 2.3.1 <a href="dl_mac2.htm#dev">development snapshot</a>.
<P>
The author of this port is <a href="mailto:csomor@advancedconcepts.ch">Stefan Csomor</a>.
<P>
<h3><a name="macplat">Which Mac platforms are supported?</a></h3>
-wxWidgets 2 can be used to develop and deliver applications on Classic Mac OS (e.g. Mac OS 8.x/9.x) both as Carbon and non-Carbon applications.
-<P>
-A Mac OS X port is in progress in order to be able to build wxWidgets applications using the Apple Developer Tools that are delivered with every copy of Mac OS X.
-The Mac OS X port is based on and, for the most part, merged with the Carbon code for Classic Mac OS.
+wxWidgets can be used to develop and deliver applications on Mac OS X and Mac Classic (e.g. Mac OS 8.x/9.x) both as Carbon and non-Carbon applications.
+However the Mac OS X port is the most actively developed one, and Mac Classic will not be supported
+after 2.6. wxMac works best with Mac OS X 10.3 and above.
<P>
-<h3><a name="macosx">How is the Mac OS X port different from the Classic Mac OS port?</a></h3>
+<h3><a name="compilers">What compilers are supported?</a></h3>
-wxMac for Mac OS X shares code both with wxMac for Mac OS and common Unix code in wxWidgets. The aim is to use the same Mac OS Carbon code both for Classic Mac OS and for Mac OS X while leveraging the fact that Mac OS X is a BSD Unix.
+Under Classic Mac OS, MetroWerks CodeWarrior Pro 6 (or above) is required to build wxMac.
<P>
-This hybrid approach was suggested by Apple to the <a href="http://www.mozilla.org/ports/fizzilla/">Fizzilla</a> team working on <a href="http://www.mozilla.org/">Mozilla</a> for Mac OS X.
+Under Mac OS X, the Developer Tools are sufficient to build wxMac. CodeWarrior Pro 6 can also be used to build the Carbon targets.
<P>
-<h3><a name="macclassic">How are improvements to the Classic Mac OS port integrated into the Mac OS X port?</a></h3>
-
-Since the source code is shared between the two ports, any Carbon compliant improvements to wxMac for Classic Mac OS are automatically available in the Mac OS X port.
-<P>
-The following points should be considered when improving wxMac:
-<ul>
-<li>Non Carbon compliant changes for Classic Mac OS will most likely break the Mac OS X port. <em>Such changes should be tested using the Carbon targets in the CodeWarrior projects for Classic Mac OS.</em>
-<li>Non Carbon compliant changes for Mac OS X will most likely break the Classic Mac OS port. <em>Such changes should be tested using CodeWarrior under Mac OS 8.x/9.x.</em>
-</ul>
-<P>
+<h3><a name="conflicts">What can I do if I get conflicts between different installed versions of wxWidgets?</a></h3>
-<h3><a name="compilers">What compilers are supported?</a></h3>
+Some versions of Mac OS X install an older version of wxMac than the one you may be using
+for development. This can cause conflicts, such as link errors when building your
+applications. A user reports:<p>
-Under Classic Mac OS, MetroWerks CodeWarrior Pro 5.3 or 6 are required to build wxMac.
-<P>
-Under Mac OS X, the Developer Tools are sufficient to build wxMac. CodeWarrior Pro 6 can also be used to build the Carbon targets.
-<P>
+<blockquote>
+I got it to work. I removed the original wxMac build-release folder
+and recompiled wxMac following instructions in your book. I then ran
+"sudo make install" which I didn't do the first time. I figured I
+could now run wx-config --cxxflags from my home directory because
+/usr/local/bin/wx-config was in my $PATH. However, OSX 10.4 installed
+a version of wxWidgets. When I ran wx-config I was getting wx 2.5
+libs instead of the 2.6.1 libs I just compiled. When I ran
+"/usr/local/bin/wx-config --cxxflags" and "/usr/local/bin/wx-config --libs"
+and pasted that output into XCode preferences, everything worked fine.
+</blockquote>
+<p>
<h3><a name="filetypes">How does CVS handle file types/creators under Mac OS 8.x/9.x?</a></h3>
</ul>
<P>
+<!--
<h3><a name="cwpro53">What steps are required to build wxMac using CodeWarrior Pro 5.3?</a></h3>
The latest build for Carbon support lead to a few changes that you will have to follow in order to successfully compile the code.
<li>wxWidgets:src:zlib:
</ul>
<P>
+-->
<h3><a name="buildx">What steps are required to build wxMac under Mac OS X?</a></h3>
<HTML>
<HEAD>
-<TITLE>wxWidgets 2 for Motif FAQ</TITLE>
+<TITLE>wxWidgets for Motif FAQ</TITLE>
</HEAD>
<BODY BGCOLOR=#FFFFFF TEXT=#000000 VLINK="#00376A" LINK="#00529C" ALINK="#313063">
<tr>
<td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif">
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
-<b>wxWidgets 2 for Motif FAQ</b>
+<b>wxWidgets for Motif FAQ</b>
</font>
</td>
</tr>
+
<HTML>
<HEAD>
-<TITLE>wxWidgets 2 for Windows FAQ</TITLE>
+<TITLE>wxWidgets for Windows FAQ</TITLE>
</HEAD>
<BODY BGCOLOR=#FFFFFF TEXT=#000000 VLINK="#00376A" LINK="#00529C" ALINK="#313063">
<tr>
<td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif">
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
-<b>wxWidgets 2 for Windows FAQ</b>
+<b>wxWidgets for Windows FAQ</b>
</font>
</td>
</tr>
<li><a href="#wince">What about Windows CE?</a></li>
<li><a href="#winxp">What do I need to do for Windows XP?</a></li>
<li><a href="#compilers">What compilers are supported?</a></li>
-<li><a href="#bestcompiler">Which is the best compiler to use with wxWidgets 2?</a></li>
+<li><a href="#bestcompiler">Which is the best compiler to use with wxWidgets?</a></li>
<li><a href="#unicode">Is Unicode supported?</a></li>
<li><a href="#doublebyte">Does wxWidgets support double byte fonts (Chinese/Japanese/Korean etc.)?</a></li>
-<li><a href="#dll">Can you compile wxWidgets 2 as a DLL?</a></li>
+<li><a href="#dll">Can you compile wxWidgets as a DLL?</a></li>
<li><a href="#exesize">How can I reduce executable size?</a></li>
<li><a href="#mfc">Is wxWidgets compatible with MFC?</a></li>
<li><a href="#setuph">Why do I get errors about setup.h not being found?</a></li>
<h3><a name="platforms">Which Windows platforms are supported?</a></h3>
-wxWidgets 2 can be used to develop and deliver applications on Windows 3.1, Win32s,
-Windows 95, Windows 98, Windows NT, Windows 2000, and Windows XP. A Windows CE
-
version is being looked into (see below).<P>
+wxWidgets can be used to develop and deliver applications on Windows 95, Windows 98, Windows NT,
+Windows 2000, Windows XP, and Windows Vista. A Windows CE
+
port is also available (see below).<P>
-wxWidgets 2 is designed to make use of WIN32 features and controls. However, unlike Microsoft,
-we have not forgotten users of 16-bit Windows. Most features
-work under Windows 3.1, including wxTreeCtrl and wxListCtrl using the generic implementation.
-However, don't expect very Windows-95-specific classes to work, such as wxTaskBarIcon. The wxRegConfig
-class doesn't work either because the Windows 3.1 registry is very simplistic. Check out the 16-bit
-makefiles to see what other files have been left out.
-<P>
-16-bit compilation is supported under Visual C++ 1.5, and Borland BC++ 4 to 5.
+16-bit compilation is only supported for wxWidgets 2.4 and previous versions,
+using Visual C++ 1.5 and Borland BC++ 4 to 5.
<P>
-wxWidgets
2 for Windows will also compile on Unix with gcc using Wine from <a href="http://www.winehq.org" target=_top>WineHQ</a>.
+wxWidgets for Windows will also compile on Unix with gcc using Wine from <a href="http://www.winehq.org" target=_top>WineHQ</a>.
The resulting executables are Unix binaries that work with the Wine Windows API emulator.<P>
-You can also compile wxWidgets 2 for Windows on Unix with Cygwin or Mingw32, resulting
+You can also compile wxWidgets for Windows on Unix with Cygwin or Mingw32, resulting
in executables that will run on Windows. So in theory you could write your applications
using wxGTK or wxMotif, then check/debug your wxWidgets for Windows
programs with Wine, and finally produce an ix86 Windows executable using Cygwin/Mingw32,
<h3><a name="wince">What about Windows CE?</a></h3>
-This port is largely complete. For further information, see the <a href="http://www.wxwidgets.org/embedded.htm#wxwince">wxEmbedded</a> page.<P>
+This port supports Pocket PC 2002/2003 and MS Smartphone 2002/2003, using
+Embedded Visual C++ 3 or 4. For further information, see the wxMSW section in
+the wxWidgets Reference Manual, and also the <a href="http://www.wxwidgets.org/embedded.htm#wxwince">wxEmbedded</a> page.<P>
<h3><a name="winxp">What do I need to do for Windows XP?</a></h3>
+From wxWidgets 2.5, the XP manifest is included in wx/msw/wx.rc and
+so your application will be themed automatically so long as you include wx.rc
+in your own .rc file.<P>
+
+For versions of wxWidgets below 2.5, you need to provide the manifest
+explicitly, as follows.<p>
+
In the same directory as you have your executable (e.g. foo.exe) you
put a file called foo.exe.manifest in which you have something like
the following:
1 24 "winxp.manifest"
</PRE>
-In wxWidgets 2.5, this will be in the wx/msw/wx.rc and
-so will happen automatically so long as you include wx.rc
-in your own .rc file.<P>
-
For an explanation of this syntax, please see
<a href="http://delphi.about.com/library/bluc/text/uc111601a.htm" target=_new>this
article</a>.
<h3><a name="compilers">What compilers are supported?</a></h3>
-Please see the wxWidgets 2 for Windows install.txt file for up-to-date information, but
+Please see the wxWidgets for Windows install.txt file for up-to-date information, but
currently the following are known to work:<P>
<ul>
<P>
-<h3><a name="bestcompiler">Which is the best compiler to use with wxWidgets 2?</a></h3>
+<h3><a name="bestcompiler">Which is the best compiler to use with wxWidgets?</a></h3>
-It's partly a matter of taste, but I (JACS) prefer Visual C++ since the debugger is very
+It's partly a matter of taste, but some people prefer Visual C++ since the debugger is very
good, it's very stable, the documentation is extensive, and it generates small executables.
Since project files are plain text, it's easy for me to generate appropriate project files
for wxWidgets samples.<P>
Among the free compilers the best choice seem to be Borland C++ command line
tools and mingw32 (port of gcc to Win32). Both of them are supported by
-wxWidgets.
+wxWidgets. However BC++ has trouble compiling large executables statically,
+so you need to dynamically link the wxWidgets libraries.<p>
<h3><a name="unicode">Is Unicode supported?</a></h3>
<h3><a name="doublebyte">Does wxWidgets support double byte fonts (Chinese/Japanese/Korean etc.)?</a></h3>
-For Japanese under Win2000, it seems that wxWidgets has no problems to work
+For Japanese under Win2000, it seems that wxWidgets has no problems working
with double byte char sets (meaning DBCS, not Unicode). First you have to
install Japanese support on your Win2K system and choose for ANSI translation
<tt>HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage=932</tt>
wxWidgets applications.
<p>
-<h3><a name="dll">Can you compile wxWidgets 2 as a DLL?</a></h3>
+<h3><a name="dll">Can you compile wxWidgets as a DLL?</a></h3>
Yes (using the Visual C++ or Borland C++ makefile), but be aware that distributing DLLs is a thorny issue
and you may be better off compiling statically-linked applications, unless you're
<H3><a name="setuph">Why do I get errors about setup.h not being found?</a></H3>
When you build the wxWidgets library, setup.h is copied
-from include/wx/msw/setup.h to e.g. lib/mswd/wx/setup.h (the path
+from include/wx/msw/setup.h to e.g. lib/vc_msw/mswd/wx/setup.h (the path
depends on the configuration you're building). So you need to add
this include path if building using the static Debug library:<P>
-lib/mswd<P>
-or if building the static Release library, lib/msw.<P>
+or if building the static Release library, lib/
vc_lib/msw.<P>
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>
+is described in technical note 16 under docs/tech in your distribution.<p>
-As of wxWidgets 2.1, there is a new system written by Vadim Zeitlin, that
+For 2.4.x, there is a system written by Vadim Zeitlin that
generates the makefiles from templates using tmake.<P>
-Here are Vadim's notes:<P>
+Here are Vadim's notes
on tmake:<P>
<blockquote>
To use these new makefiles, you don't need anything (but see below).
tmake can be found at
<a href="http://www.troll.no/freebies/tmake.html" target=_new>www.troll.no/freebies/tmake.html</a>.
-It's a Perl5 program and so it needs Perl (doh). There is a binary for
+It's a Perl5 program and so it needs Perl (doh). There is a binary for
Windows (available from the same page), but I haven't used it, so
I don't know if it works as flawlessly as "perl tmake" does (note
for people knowing Perl: don't try to run tmake with -w, it won't
<pre>tmake -t b32 wxwin.pro -o ../../src/msw/makefile.b32</pre><P>
-The makefiles are untested - I don't have any of Borland, Watcom or
+The makefiles are untested - I don't have any of Borland, Watcom or
Symantec and I don'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
regKey.SetName(idName);
{
- wxLogNull dummy;
+ wxLogNull dummy;
if (!regKey.Create())
{
idName = wxT("HKEY_CURRENT_USER\\SOFTWARE\\My Company\\My Product\\Stuff\\");
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:
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__
+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
+don't get defined. You have to #undef __WXDEBUG__ before including the
directshow baseclass's <streams.h>.
</blockquote>
<HTML>
<HEAD>
-<TITLE>wxWidgets 2 for X11 FAQ</TITLE>
+<TITLE>wxWidgets for X11 FAQ</TITLE>
</HEAD>
<BODY BGCOLOR=#FFFFFF TEXT=#000000 VLINK="#00376A" LINK="#00529C" ALINK="#313063">
<tr>
<td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif">
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
-<b>wxWidgets 2 for X11 FAQ</b>
+<b>wxWidgets for X11 FAQ</b>
</font>
</td>
</tr>
projects / wxWidgets.git / commitdiff
