[wxWidgets.git] / docs / html / faqmsw.htm

<HTML>

<HEAD>
<TITLE>wxWindows 2 for Windows FAQ</TITLE>
</HEAD>

<BODY BGCOLOR=#FFFFFF TEXT=#000000 LINK=#FF0000 VLINK=#000000>

<font face="Arial, Lucida Sans, Helvetica">

<table width=100% border=0 cellpadding=5 cellspacing=0>
<tr>
<td bgcolor="#C4ECF9">
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#000000">
wxWindows 2 for Windows FAQ
</font>
</td>
</tr>
</table>

<P>

See also <a href="faq.htm">top-level FAQ page</a>.
<hr>
<h3>List of questions in this category</h3>
<ul>
<li><a href="#platforms">Which Windows platforms are supported?</a></li>
<li><a href="#wince">What about Windows CE?</a></li>
<li><a href="#compilers">What compilers are supported?</a></li>
<li><a href="#bestcompiler">Which is the best compiler to use with wxWindows 2?</a></li>
<li><a href="#unicode">Is Unicode supported?</a></li>
<li><a href="#dll">Can you compile wxWindows 2 as a DLL?</a></li>
<li><a href="#exesize">How can I reduce executable size?</a></li>
<li><a href="#mfc">Is wxWindows compatible with MFC?</a></li>
<li><a href="#newerrors">Why my code fails to compile with strange errors about new operator?</a></li>
<li><a href="#mfcport">How do I port MFC applications to wxWindows?</a></li>
<li><a href="#crash">Why do I sometimes get bizarre crash problems using VC++ 5/6?</a></li>
<li><a href="#makefiles">How are the wxWindows makefiles edited under Windows?</a></li>
<li><a href="#vcdebug">How do you use VC++&#39;s memory leak checking instead of that in wxWindows?</a></li>
<li><a href="#shortcutproblem">Why are menu hotkeys or shortcuts not working in my application?</a></li>
</ul>
<hr>

<h3><a name="platforms">Which Windows platforms are supported?</a></h3>

wxWindows 2 can be used to develop and deliver applications on Windows 3.1, Win32s,
Windows 95, Windows 98, and Windows NT. A Windows CE version is being looked into (see below).<P>

wxWindows 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&#39;t expect very Windows-95-specific classes to work, such as wxTaskBarIcon. The wxRegConfig
class doesn&#39;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.
<P>

wxWindows 2 for Windows will also compile on Unix with gcc using TWIN32 from <a href="http://www.willows.com" target=_top>Willows</a>,
although TWIN32 is still in a preliminary state. The resulting executables are
Unix binaries that work with the TWIN32 Windows API emulator.<P>

You can also compile wxWindows 2 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 wxWindows for Windows
programs with TWIN32, and finally produce an ix86 Windows executable using Cygwin/Mingw32,
without ever needing a copy of Microsoft Windows. See the Technical Note on the Web site detailing cross-compilation.<P>

<h3><a name="wince">What about Windows CE?</a></h3>

This is under consideration, though we need to get wxWindows Unicode-aware first.
There are other interesting issues, such as how to combine the menubar and toolbar APIs
as Windows CE requires. But there&#39;s no doubt that it will be possible, albeit
by mostly cutting down wxWindows 2 API functionality, and adding a few classes here
and there. Since wxWindows for 2 produces small binaries (less than 300K for
the statically-linked &#39;minimal&#39; sample), shoehorning wxWindows 2 into a Windows CE device&#39;s limited
storage should not be a problem.<P>

<h3><a name="compilers">What compilers are supported?</a></h3>

Please see the wxWindows 2 for Windows install.txt file for up-to-date information, but
currently the following are known to work:<P>

<ul>
<li>Visual C++ 1.5, 4.0, 5.0, 6.0
<li>Borland C++ 4.5, 5.0
<li>Borland C++Builder 1.0, 3.0
<li>Watcom C++ 10.6 (WIN32)
<li>Cygwin b20
<li>Mingw32
<li>MetroWerks CodeWarrior 4
</ul>
<P>

There is a linking problem with Symantec C++ which I hope someone can help solve.
<P>

<h3><a name="bestcompiler">Which is the best compiler to use with wxWindows 2?</a></h3>

It&#39;s partly a matter of taste, but I (JACS) prefer Visual C++ since the debugger is very
good, it&#39;s very stable, the documentation is extensive, and it generates small executables.
Since project files are plain text, it&#39;s easy for me to generate appropriate project files
for wxWindows samples.<P>

Borland C++ is fine - and very fast - but it&#39;s hard (impossible?) to use the debugger without using project files, and
the debugger is nowhere near up to VC++&#39;s quality. The IDE isn&#39;t great.<P>

C++Builder&#39;s power isn&#39;t really used with wxWindows since it needs integration with its
own class library (VCL). For wxWindows, I&#39;ve only used it with makefiles, in which case
it&#39;s almost identical to BC++ 5.0 (the same makefiles can be used).<P>

You can&#39;t beat Cygwin&#39;s price (free), and you can debug adequately using gdb. However, it&#39;s
quite slow to compile since it does not use precompiled headers.<P>

CodeWarrior is cross-platform - you can debug and generate Windows executables from a Mac, but not
the other way around I think - but the IDE is, to my mind, a bit primitive.<P>

Watcom C++ is a little slow and the debugger is not really up to today&#39;s standards.<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
wxWindows.

<h3><a name="unicode">Is Unicode supported?</a></h3>

Yes, Unicode is fully supported under Windows NT/2000 (Windows 9x don&#39;t
have Unicode support anyhow).

<h3><a name="dll">Can you compile wxWindows 2 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&#39;re
delivering a suite of separate programs, or you&#39;re compiling a lot of wxWindows applications
and have limited hard disk space.<P>

With a DLL approach, and with different versions and configurations of wxWindows
needing to be catered for, the end user may end up with a host of large DLLs in his or her Windows system directory,
negating the point of using DLLs. Of course, this is not a problem just associated with
wxWindows!
<P>

<h3><a name="exesize">How can I reduce executable size?</a></h3>

You can compile wxWindows as a DLL (see above, VC++/BC++ only at present). You should also
compile your programs for release using non-debugging and space-optimisation options, but
take with VC++ 5/6 space optimisation: it can sometimes cause problems.<P>

Statically-linked wxWindows 2 programs are smaller than wxWindows 1.xx programs, because of the way
wxWindows 2 has been designed to reduce dependencies between classes, and other
techniques. The linker will not include code from the library that is not (directly or
indirectly) referenced
by your application. So for example, the &#39;minimal&#39; sample is less than 300KB using VC++ 6.<P>

If you want to distribute really small executables, you can
use <a href="http://www.icl.ndirect.co.uk/petite/" target=_top>Petite</a>
by Ian Luck. This nifty utility compresses Windows executables by around 50%, so your 500KB executable
will shrink to a mere 250KB. With this sort of size, there is reduced incentive to
use DLLs.<P>

<H3><a name="mfc">Is wxWindows compatible with MFC?</a></H3>

There is a sample which demonstrates MFC and wxWindows code co-existing in the same
application. However, don&#39;t expect to be able to enable wxWindows windows with OLE-2
functionality using MFC.<P>

<H3><a name="newerrors">Why my code fails to compile with strange errors about new operator?</a></H3>

The most common cause of this problem is the memory debugging settings in
<tt>wx/msw/setup.h</tt>. You have several choices:

<ul>
    <li> Either disable overloading the global operator new completely by
         setting <tt>wxUSE_GLOBAL_MEMORY_OPERATORS</tt> and
         <tt>wxUSE_DEBUG_NEW_ALWAYS</tt> to 0 in this file
    <li> Or leave them on but do <tt>#undef new</tt> after including any
         wxWindows headers, like this the memory debugging will be still on
         for wxWindows sources but off for your own code
</ul>

Notice that IMHO the first solution is preferable for VC++ users who can use
the <a href="#vcdebug">VC++ CRT memory debugging features</a> instead.

<H3><a name="mfcport">How do I port MFC applications to wxWindows?</a></H3>

Set up your interface from scratch using wxWindows (especially wxDesigner --
it&#39;ll save you a <i>lot</i> of time) and when you have a shell prepared, you can start
&#39;pouring in&#39; code from the MFC app, with appropriate
modifications. This is the approach I have used, and I found
it very satisfactory. A two-step process then - reproduce the bare
interface first, then wire it up afterwards. That way you deal
with each area of complexity separately. Don&#39;t try to think MFC
and wxWindows simultaneously from the beginning - it is easier to
reproduce the initial UI by looking at the behaviour of the MFC
app, not its code.

<H3><a name="crash">Why do I sometimes get bizarre crash problems using VC++ 5/6?</a></H3>

Some crash problems can be due to inconsistent compiler
options (and of course this isn&#39;t limited to wxWindows).
If strange/weird/impossible things start to happen please
check (dumping IDE project file as makefile and doing text comparison
if necessary) that the project settings, especially the list of defined
symbols, struct packing, etc. are exactly the same for all items in
the project. After this, delete everything (including PCH) and recompile.<P>

VC++ 5&#39;s optimization code seems to be broken and can
cause problems: this can be seen when deleting an object Dialog
Editor, in Release mode with optimizations on. If in doubt,
switch off optimisations, although this will result in much
larger executables. It seems possible that the library can be created with
strong optimization, so long as the application is not strongly
optimized. For example, in wxWindows project, set to &#39;Minimum
Size&#39;. In Dialog Editor project, set to &#39;Customize: Favor Small
Code&#39; (and no others). This will then work.<P>

<H3><a name="makefiles">How are the wxWindows makefiles edited under Windows?</a></H3>

As of wxWindows 2.1, there is a new system written by Vadim Zeitlin, that
generates the makefiles from templates using tmake.<P>

Here are Vadim&#39;s notes:<P>

<blockquote>
To use these new makefiles, you don&#39;t need anything (but see below).
However, you should NOT modify them because these files will be
rewritten when I regenerate them using tmake the next time. So, if
you find a problem with any of these makefiles (say, makefile.b32)
you&#39;ll need to modify the corresponding template (b32.t in this
example) and regenerate the makefile using tmake.<P>

tmake can be found at
<a href="http://www.troll.no/freebies/tmake.html" target=_new>www.troll.no/freebies/tmake.html</a>.
It&#39;s a Perl5 program and so it needs Perl (doh). There is a binary for 
Windows (available from the same page), but I haven&#39;t used it, so
I don&#39;t know if it works as flawlessly as "perl tmake" does (note
for people knowing Perl: don&#39;t try to run tmake with -w, it won&#39;t
do you any good). Using it extremely simple: to regenerate makefile.b32
just go to distrib/msw/tmake and type<P>

<pre>tmake -t b32 wxwin.pro -o ../../src/msw/makefile.b32</pre><P>

The makefiles are untested - I don&#39;t have any of Borland, Watcom  or
Symantec and I don&#39;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
(should I say bugs?) in some of makefiles, some files were not compiled
without any reason etc. Please test them and notify me about any problems.
Better yet, modify the template files to generate the correct makefiles
and check them in.<P>

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&#39;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>

Another important file is filelist.txt: it contains the list of all
files to be compiled. Some of them are only compiled in 16/32 bit mode.
Some other are only compiled with some compilers (others can&#39;t compile
them) - all this info is contained in this file.<P>

So now adding a new file to wxWindows is as easy as modifying filelist.txt
(and Makefile.ams for Unix ports) and regenerating the makefiles - no
need to modify all files manually any more.<P>

 Finally, there is also a file vc6.t which I use myself: this one
generates a project file for VC++ 6.0 (I didn&#39;t create vc5.t because
I don&#39;t need it and can&#39;t test it, but it should be trivial to create
one from vc6.t - probably the only things to change would be the
version number in the very beginning and the /Z option - VC5 doesn&#39;t
support edit-and=continue). This is not an officially supported way
of building wxWindows (that is, nobody guarantees that it will work),
but it has been very useful to me and I hope it will be also for
others. To generate wxWindows.dsp run<P>

<pre>tmake -t vc6 wxwin.pro -o ../../wxWindows.dsp</pre><P>

Then just include this project in any workspace or open it from VC IDE
and it will create a new workspace for you.<P>

If all goes well, I&#39;m planning to create a template file for Makefile.ams
under src/gtk and src/motif and also replace all makefiles in the samples
subdirectories with the project files from which all the others will be
generated. At least it will divide the number of files in samples
directory by 10 (and the number of files to be maintained too).
</blockquote>

<P>

<H3><a name="vcdebug">How do you use VC++&#39;s memory leak checking instead of that in wxWindows?</a></H3>

Vadim Zeitlin:

<pre>
On the VC++ level, it&#39;s just the matter of calling _CrtSetDbgFlag() in the very
beginning of the program. In wxWindows, this is done automatically when
compiling with VC++ in debug mode unless wxUSE_GLOBAL_MEMORY_OPERATORS or
__NO_VC_CRTDBG__ are defined - this check is done in wx/msw/msvcrt.h which
is included from app.cpp which then calls wxCrtSetDbgFlag() without any
ifdefs.

This works quite well: at the end of the program, all leaked blocks with their
malloc count are shown. This number (malloc count) can be used to determine
where exactly the object was allocated: for this it&#39;s enough to set the variable
_crtBreakAlloc (look in VC98\crt\srs\dbgheap.c line 326) to this number and
a breakpoint will be triggered when the block with this number is allocated.

For simple situations it works like a charm. For something more complicated
like reading uninitialized memory a specialized tool is probably better...

Regards,
VZ
</pre>

<P>

<H3><a name="shortcutproblem">Why are menu hotkeys or shortcuts not working in my application?</a></H3>

This can happen if you have a child window intercepting EVT_CHAR events and swallowing
all keyboard input. You should ensure that event.Skip() is called for all input that
isn&#39;used by the event handler.


</font>

</BODY>

</HTML>
Commit	Line	Data
ce3ed50d JS	1	<HTML>
	2
	3	<HEAD>
	4	<TITLE>wxWindows 2 for Windows FAQ</TITLE>
	5	</HEAD>
	6
	7	<BODY BGCOLOR=#FFFFFF TEXT=#000000 LINK=#FF0000 VLINK=#000000>
	8
	9	<font face="Arial, Lucida Sans, Helvetica">
	10
f6bcfd97	11	<table width=100% border=0 cellpadding=5 cellspacing=0>
ce3ed50d	12	<tr>
f6bcfd97 BP	13	<td bgcolor="#C4ECF9">
f6bcfd97 BP	14	<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#000000">
ce3ed50d JS	15	wxWindows 2 for Windows FAQ
	16	</font>
	17	</td>
	18	</tr>
	19	</table>
	20
	21	<P>
	22
	23	See also <a href="faq.htm">top-level FAQ page</a>.
	24	<hr>
8b283bb8 JS	25	<h3>List of questions in this category</h3>
	26	<ul>
	27	<li><a href="#platforms">Which Windows platforms are supported?</a></li>
	28	<li><a href="#wince">What about Windows CE?</a></li>
	29	<li><a href="#compilers">What compilers are supported?</a></li>
	30	<li><a href="#bestcompiler">Which is the best compiler to use with wxWindows 2?</a></li>
	31	<li><a href="#unicode">Is Unicode supported?</a></li>
	32	<li><a href="#dll">Can you compile wxWindows 2 as a DLL?</a></li>
	33	<li><a href="#exesize">How can I reduce executable size?</a></li>
	34	<li><a href="#mfc">Is wxWindows compatible with MFC?</a></li>
	35	<li><a href="#newerrors">Why my code fails to compile with strange errors about new operator?</a></li>
	36	<li><a href="#mfcport">How do I port MFC applications to wxWindows?</a></li>
	37	<li><a href="#crash">Why do I sometimes get bizarre crash problems using VC++ 5/6?</a></li>
	38	<li><a href="#makefiles">How are the wxWindows makefiles edited under Windows?</a></li>
	39	<li><a href="#vcdebug">How do you use VC++'s memory leak checking instead of that in wxWindows?</a></li>
	40	<li><a href="#shortcutproblem">Why are menu hotkeys or shortcuts not working in my application?</a></li>
	41	</ul>
	42	<hr>
ce3ed50d	43
8b283bb8	44	<h3><a name="platforms">Which Windows platforms are supported?</a></h3>
ce3ed50d	45
0bc9b25e	46	wxWindows 2 can be used to develop and deliver applications on Windows 3.1, Win32s,
b953bdc2 JS	47	Windows 95, Windows 98, and Windows NT. A Windows CE version is being looked into (see below).<P>
	48
	49	wxWindows 2 is designed to make use of WIN32 features and controls. However, unlike Microsoft,
	50	we have not forgotten users of 16-bit Windows. Most features
ce3ed50d	51	work under Windows 3.1, including wxTreeCtrl and wxListCtrl using the generic implementation.
8b283bb8 JS	52	However, don't expect very Windows-95-specific classes to work, such as wxTaskBarIcon. The wxRegConfig
8b283bb8 JS	53	class doesn't work either because the Windows 3.1 registry is very simplistic. Check out the 16-bit
ce3ed50d JS	54	makefiles to see what other files have been left out.
	55	<P>
	56	16-bit compilation is supported under Visual C++ 1.5, and Borland BC++ 4 to 5.
	57	<P>
	58
b953bdc2 JS	59	wxWindows 2 for Windows will also compile on Unix with gcc using TWIN32 from <a href="http://www.willows.com" target=_top>Willows</a>,
	60	although TWIN32 is still in a preliminary state. The resulting executables are
	61	Unix binaries that work with the TWIN32 Windows API emulator.<P>
	62
	63	You can also compile wxWindows 2 for Windows on Unix with Cygwin or Mingw32, resulting
	64	in executables that will run on Windows. So in theory you could write your applications
	65	using wxGTK or wxMotif, then check/debug your wxWindows for Windows
	66	programs with TWIN32, and finally produce an ix86 Windows executable using Cygwin/Mingw32,
	67	without ever needing a copy of Microsoft Windows. See the Technical Note on the Web site detailing cross-compilation.<P>
	68
8b283bb8	69	<h3><a name="wince">What about Windows CE?</a></h3>
b953bdc2 JS	70
	71	This is under consideration, though we need to get wxWindows Unicode-aware first.
	72	There are other interesting issues, such as how to combine the menubar and toolbar APIs
8b283bb8	73	as Windows CE requires. But there's no doubt that it will be possible, albeit
b953bdc2 JS	74	by mostly cutting down wxWindows 2 API functionality, and adding a few classes here
b953bdc2 JS	75	and there. Since wxWindows for 2 produces small binaries (less than 300K for
8b283bb8	76	the statically-linked 'minimal' sample), shoehorning wxWindows 2 into a Windows CE device's limited
b953bdc2 JS	77	storage should not be a problem.<P>
b953bdc2 JS	78
8b283bb8	79	<h3><a name="compilers">What compilers are supported?</a></h3>
ce3ed50d JS	80
	81	Please see the wxWindows 2 for Windows install.txt file for up-to-date information, but
	82	currently the following are known to work:<P>
	83
	84	<ul>
	85	<li>Visual C++ 1.5, 4.0, 5.0, 6.0
	86	<li>Borland C++ 4.5, 5.0
	87	<li>Borland C++Builder 1.0, 3.0
	88	<li>Watcom C++ 10.6 (WIN32)
	89	<li>Cygwin b20
	90	<li>Mingw32
	91	<li>MetroWerks CodeWarrior 4
	92	</ul>
	93	<P>
	94
	95	There is a linking problem with Symantec C++ which I hope someone can help solve.
	96	<P>
	97
8b283bb8	98	<h3><a name="bestcompiler">Which is the best compiler to use with wxWindows 2?</a></h3>
ce3ed50d	99
8b283bb8 JS	100	It's partly a matter of taste, but I (JACS) prefer Visual C++ since the debugger is very
	101	good, it's very stable, the documentation is extensive, and it generates small executables.
	102	Since project files are plain text, it's easy for me to generate appropriate project files
ce3ed50d JS	103	for wxWindows samples.<P>
ce3ed50d JS	104
8b283bb8 JS	105	Borland C++ is fine - and very fast - but it's hard (impossible?) to use the debugger without using project files, and
8b283bb8 JS	106	the debugger is nowhere near up to VC++'s quality. The IDE isn't great.<P>
ce3ed50d	107
8b283bb8 JS	108	C++Builder's power isn't really used with wxWindows since it needs integration with its
	109	own class library (VCL). For wxWindows, I've only used it with makefiles, in which case
	110	it's almost identical to BC++ 5.0 (the same makefiles can be used).<P>
ce3ed50d	111
8b283bb8	112	You can't beat Cygwin's price (free), and you can debug adequately using gdb. However, it's
ce3ed50d JS	113	quite slow to compile since it does not use precompiled headers.<P>
	114
	115	CodeWarrior is cross-platform - you can debug and generate Windows executables from a Mac, but not
	116	the other way around I think - but the IDE is, to my mind, a bit primitive.<P>
	117
8b283bb8	118	Watcom C++ is a little slow and the debugger is not really up to today's standards.<P>
ce3ed50d	119
8b283bb8 JS	120	Among the free compilers the best choice seem to be Borland C++ command line
	121	tools and mingw32 (port of gcc to Win32). Both of them are supported by
	122	wxWindows.
ce3ed50d	123
8b283bb8	124	<h3><a name="unicode">Is Unicode supported?</a></h3>
ce3ed50d	125
8b283bb8 JS	126	Yes, Unicode is fully supported under Windows NT/2000 (Windows 9x don't
8b283bb8 JS	127	have Unicode support anyhow).
ce3ed50d	128
8b283bb8	129	<h3><a name="dll">Can you compile wxWindows 2 as a DLL?</a></h3>
ce3ed50d	130
9838df2c	131	Yes (using the Visual C++ or Borland C++ makefile), but be aware that distributing DLLs is a thorny issue
8b283bb8 JS	132	and you may be better off compiling statically-linked applications, unless you're
8b283bb8 JS	133	delivering a suite of separate programs, or you're compiling a lot of wxWindows applications
b953bdc2 JS	134	and have limited hard disk space.<P>
	135
	136	With a DLL approach, and with different versions and configurations of wxWindows
	137	needing to be catered for, the end user may end up with a host of large DLLs in his or her Windows system directory,
	138	negating the point of using DLLs. Of course, this is not a problem just associated with
	139	wxWindows!
	140	<P>
	141
8b283bb8	142	<h3><a name="exesize">How can I reduce executable size?</a></h3>
9838df2c JS	143
9838df2c JS	144	You can compile wxWindows as a DLL (see above, VC++/BC++ only at present). You should also
0bc9b25e JS	145	compile your programs for release using non-debugging and space-optimisation options, but
0bc9b25e JS	146	take with VC++ 5/6 space optimisation: it can sometimes cause problems.<P>
9838df2c JS	147
	148	Statically-linked wxWindows 2 programs are smaller than wxWindows 1.xx programs, because of the way
	149	wxWindows 2 has been designed to reduce dependencies between classes, and other
	150	techniques. The linker will not include code from the library that is not (directly or
	151	indirectly) referenced
8b283bb8	152	by your application. So for example, the 'minimal' sample is less than 300KB using VC++ 6.<P>
9838df2c JS	153
	154	If you want to distribute really small executables, you can
	155	use <a href="http://www.icl.ndirect.co.uk/petite/" target=_top>Petite</a>
	156	by Ian Luck. This nifty utility compresses Windows executables by around 50%, so your 500KB executable
	157	will shrink to a mere 250KB. With this sort of size, there is reduced incentive to
	158	use DLLs.<P>
	159
8b283bb8	160	<H3><a name="mfc">Is wxWindows compatible with MFC?</a></H3>
b953bdc2 JS	161
b953bdc2 JS	162	There is a sample which demonstrates MFC and wxWindows code co-existing in the same
8b283bb8	163	application. However, don't expect to be able to enable wxWindows windows with OLE-2
b953bdc2	164	functionality using MFC.<P>
ce3ed50d	165
8b283bb8 JS	166	<H3><a name="newerrors">Why my code fails to compile with strange errors about new operator?</a></H3>
	167
	168	The most common cause of this problem is the memory debugging settings in
	169	<tt>wx/msw/setup.h</tt>. You have several choices:
	170
	171	<ul>
	172	<li> Either disable overloading the global operator new completely by
	173	setting <tt>wxUSE_GLOBAL_MEMORY_OPERATORS</tt> and
	174	<tt>wxUSE_DEBUG_NEW_ALWAYS</tt> to 0 in this file
	175	<li> Or leave them on but do <tt>#undef new</tt> after including any
	176	wxWindows headers, like this the memory debugging will be still on
	177	for wxWindows sources but off for your own code
	178	</ul>
	179
	180	Notice that IMHO the first solution is preferable for VC++ users who can use
	181	the <a href="#vcdebug">VC++ CRT memory debugging features</a> instead.
	182
	183	<H3><a name="mfcport">How do I port MFC applications to wxWindows?</a></H3>
	184
	185	Set up your interface from scratch using wxWindows (especially wxDesigner --
	186	it'll save you a <i>lot</i> of time) and when you have a shell prepared, you can start
	187	'pouring in' code from the MFC app, with appropriate
	188	modifications. This is the approach I have used, and I found
	189	it very satisfactory. A two-step process then - reproduce the bare
	190	interface first, then wire it up afterwards. That way you deal
	191	with each area of complexity separately. Don't try to think MFC
	192	and wxWindows simultaneously from the beginning - it is easier to
	193	reproduce the initial UI by looking at the behaviour of the MFC
	194	app, not its code.
	195
	196	<H3><a name="crash">Why do I sometimes get bizarre crash problems using VC++ 5/6?</a></H3>
ad813b00 JS	197
ad813b00 JS	198	Some crash problems can be due to inconsistent compiler
8b283bb8	199	options (and of course this isn't limited to wxWindows).
ad813b00 JS	200	If strange/weird/impossible things start to happen please
	201	check (dumping IDE project file as makefile and doing text comparison
	202	if necessary) that the project settings, especially the list of defined
	203	symbols, struct packing, etc. are exactly the same for all items in
	204	the project. After this, delete everything (including PCH) and recompile.<P>
	205
8b283bb8	206	VC++ 5's optimization code seems to be broken and can
ad813b00 JS	207	cause problems: this can be seen when deleting an object Dialog
	208	Editor, in Release mode with optimizations on. If in doubt,
	209	switch off optimisations, although this will result in much
	210	larger executables. It seems possible that the library can be created with
	211	strong optimization, so long as the application is not strongly
8b283bb8 JS	212	optimized. For example, in wxWindows project, set to 'Minimum
	213	Size'. In Dialog Editor project, set to 'Customize: Favor Small
	214	Code' (and no others). This will then work.<P>
ad813b00	215
8b283bb8	216	<H3><a name="makefiles">How are the wxWindows makefiles edited under Windows?</a></H3>
91c93c99 JS	217
	218	As of wxWindows 2.1, there is a new system written by Vadim Zeitlin, that
	219	generates the makefiles from templates using tmake.<P>
	220
8b283bb8	221	Here are Vadim's notes:<P>
91c93c99 JS	222
91c93c99 JS	223	<blockquote>
8b283bb8	224	To use these new makefiles, you don't need anything (but see below).
91c93c99 JS	225	However, you should NOT modify them because these files will be
	226	rewritten when I regenerate them using tmake the next time. So, if
	227	you find a problem with any of these makefiles (say, makefile.b32)
8b283bb8	228	you'll need to modify the corresponding template (b32.t in this
91c93c99 JS	229	example) and regenerate the makefile using tmake.<P>
	230
	231	tmake can be found at
	232	<a href="http://www.troll.no/freebies/tmake.html" target=_new>www.troll.no/freebies/tmake.html</a>.
8b283bb8 JS	233	It's a Perl5 program and so it needs Perl (doh). There is a binary for
	234	Windows (available from the same page), but I haven't used it, so
	235	I don't know if it works as flawlessly as "perl tmake" does (note
	236	for people knowing Perl: don't try to run tmake with -w, it won't
91c93c99 JS	237	do you any good). Using it extremely simple: to regenerate makefile.b32
	238	just go to distrib/msw/tmake and type<P>
	239
	240	<pre>tmake -t b32 wxwin.pro -o ../../src/msw/makefile.b32</pre><P>
	241
8b283bb8 JS	242	The makefiles are untested - I don't have any of Borland, Watcom or
8b283bb8 JS	243	Symantec and I don't have enough diskspace to recompile even with
91c93c99 JS	244	VC6 using makefiles. The new makefiles are as close as possible to the
	245	old ones, but not closer: in fact, there has been many strange things
	246	(should I say bugs?) in some of makefiles, some files were not compiled
	247	without any reason etc. Please test them and notify me about any problems.
	248	Better yet, modify the template files to generate the correct makefiles
	249	and check them in.<P>
	250
	251	The templates are described in tmake ref manual (1-2 pages of text)
	252	and are quite simple. They do contain some Perl code, but my Perl is
	253	primitive (very C like) so it should be possible for anybody to make
	254	trivial modifications to it (I hope that only trivial modifications
8b283bb8	255	will be needed). I've tagged the ol makefiles as MAKEFILES_WITHOUT_TMAKE
91c93c99 JS	256	in the cvs, so you can always retrieve them and compare the new ones,
	257	this will make it easier to solve the problems you might have.<P>
	258
	259	Another important file is filelist.txt: it contains the list of all
	260	files to be compiled. Some of them are only compiled in 16/32 bit mode.
8b283bb8	261	Some other are only compiled with some compilers (others can't compile
91c93c99 JS	262	them) - all this info is contained in this file.<P>
	263
	264	So now adding a new file to wxWindows is as easy as modifying filelist.txt
	265	(and Makefile.ams for Unix ports) and regenerating the makefiles - no
	266	need to modify all files manually any more.<P>
	267
	268	Finally, there is also a file vc6.t which I use myself: this one
8b283bb8 JS	269	generates a project file for VC++ 6.0 (I didn't create vc5.t because
8b283bb8 JS	270	I don't need it and can't test it, but it should be trivial to create
91c93c99	271	one from vc6.t - probably the only things to change would be the
8b283bb8	272	version number in the very beginning and the /Z option - VC5 doesn't
91c93c99 JS	273	support edit-and=continue). This is not an officially supported way
	274	of building wxWindows (that is, nobody guarantees that it will work),
	275	but it has been very useful to me and I hope it will be also for
	276	others. To generate wxWindows.dsp run<P>
	277
	278	<pre>tmake -t vc6 wxwin.pro -o ../../wxWindows.dsp</pre><P>
	279
	280	Then just include this project in any workspace or open it from VC IDE
	281	and it will create a new workspace for you.<P>
	282
8b283bb8	283	If all goes well, I'm planning to create a template file for Makefile.ams
91c93c99 JS	284	under src/gtk and src/motif and also replace all makefiles in the samples
	285	subdirectories with the project files from which all the others will be
	286	generated. At least it will divide the number of files in samples
	287	directory by 10 (and the number of files to be maintained too).
	288	</blockquote>
ce3ed50d	289
f6081a04 JS	290	<P>
f6081a04 JS	291
8b283bb8	292	<H3><a name="vcdebug">How do you use VC++'s memory leak checking instead of that in wxWindows?</a></H3>
f6081a04 JS	293
	294	Vadim Zeitlin:
	295
	296	<pre>
8b283bb8	297	On the VC++ level, it's just the matter of calling _CrtSetDbgFlag() in the very
f6081a04 JS	298	beginning of the program. In wxWindows, this is done automatically when
	299	compiling with VC++ in debug mode unless wxUSE_GLOBAL_MEMORY_OPERATORS or
	300	__NO_VC_CRTDBG__ are defined - this check is done in wx/msw/msvcrt.h which
	301	is included from app.cpp which then calls wxCrtSetDbgFlag() without any
8b283bb8	302	ifdefs.
f6081a04 JS	303
	304	This works quite well: at the end of the program, all leaked blocks with their
	305	malloc count are shown. This number (malloc count) can be used to determine
8b283bb8	306	where exactly the object was allocated: for this it's enough to set the variable
f6081a04 JS	307	_crtBreakAlloc (look in VC98\crt\srs\dbgheap.c line 326) to this number and
	308	a breakpoint will be triggered when the block with this number is allocated.
	309
	310	For simple situations it works like a charm. For something more complicated
	311	like reading uninitialized memory a specialized tool is probably better...
	312
	313	Regards,
	314	VZ
	315	</pre>
	316
8b283bb8 JS	317	<P>
	318
	319	<H3><a name="shortcutproblem">Why are menu hotkeys or shortcuts not working in my application?</a></H3>
	320
	321	This can happen if you have a child window intercepting EVT_CHAR events and swallowing
	322	all keyboard input. You should ensure that event.Skip() is called for all input that
	323	isn'used by the event handler.
	324
f6081a04	325
ce3ed50d JS	326	</font>
	327
	328	</BODY>
	329
	330	</HTML>