git.saurik.com Git - wxWidgets.git/blame_incremental

... / ...

Commit	Line	Data
	1
	2	<HTML>
	3
	4	<HEAD>
	5	<TITLE>wxWindows 2 for Windows FAQ</TITLE>
	6	</HEAD>
	7
	8	<BODY BGCOLOR=#FFFFFF TEXT=#000000 VLINK="#00376A" LINK="#00529C" ALINK="#313063">
	9
	10	<font face="Arial, Lucida Sans, Helvetica">
	11
	12	<table width=100% border=0 cellpadding=3 cellspacing=0>
	13	<tr>
	14	<td bgcolor="#004080" align=left height=24 background="images/bluetitlegradient.gif">
	15	<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
	16	<b>wxWindows 2 for Windows FAQ</b>
	17	</font>
	18	</td>
	19	</tr>
	20	</table>
	21
	22	<P>
	23
	24	See also <a href="faq.htm">top-level FAQ page</a>.
	25	<hr>
	26	<h3>List of questions in this category</h3>
	27	<ul>
	28	<li><a href="#platforms">Which Windows platforms are supported?</a></li>
	29	<li><a href="#wince">What about Windows CE?</a></li>
	30	<li><a href="#winxp">What do I need to do for Windows XP?</a></li>
	31	<li><a href="#compilers">What compilers are supported?</a></li>
	32	<li><a href="#bestcompiler">Which is the best compiler to use with wxWindows 2?</a></li>
	33	<li><a href="#unicode">Is Unicode supported?</a></li>
	34	<li><a href="#doublebyte">Does wxWindows support double byte fonts (Chinese/Japanese/Korean etc.)?</a></li>
	35	<li><a href="#dll">Can you compile wxWindows 2 as a DLL?</a></li>
	36	<li><a href="#exesize">How can I reduce executable size?</a></li>
	37	<li><a href="#mfc">Is wxWindows compatible with MFC?</a></li>
	38	<li><a href="#asuffix">Why do I get errors about FooBarA when I only use FooBar in my program?</a></li>
	39	<li><a href="#newerrors">Why my code fails to compile with strange errors about new operator?</a></li>
	40	<li><a href="#mfcport">How do I port MFC applications to wxWindows?</a></li>
	41	<li><a href="#crash">Why do I sometimes get bizarre crash problems using VC++ 5/6?</a></li>
	42	<li><a href="#makefiles">How are the wxWindows makefiles edited under Windows?</a></li>
	43	<li><a href="#vcdebug">How do you use VC++'s memory leak checking instead of that in wxWindows?</a></li>
	44	<li><a href="#shortcutproblem">Why are menu hotkeys or shortcuts not working in my application?</a></li>
	45	<li><a href="#regconfig">Why can I not write to the HKLM part of the registry with wxRegConfig?</a></li>
	46	<li><a href="#access">Is MS Active Accessibility supported?</a></li>
	47	</ul>
	48	<hr>
	49
	50	<h3><a name="platforms">Which Windows platforms are supported?</a></h3>
	51
	52	wxWindows 2 can be used to develop and deliver applications on Windows 3.1, Win32s,
	53	Windows 95, Windows 98, Windows NT, Windows 2000, and Windows XP. A Windows CE
	54	version is being looked into (see below).<P>
	55
	56	wxWindows 2 is designed to make use of WIN32 features and controls. However, unlike Microsoft,
	57	we have not forgotten users of 16-bit Windows. Most features
	58	work under Windows 3.1, including wxTreeCtrl and wxListCtrl using the generic implementation.
	59	However, don't expect very Windows-95-specific classes to work, such as wxTaskBarIcon. The wxRegConfig
	60	class doesn't work either because the Windows 3.1 registry is very simplistic. Check out the 16-bit
	61	makefiles to see what other files have been left out.
	62	<P>
	63	16-bit compilation is supported under Visual C++ 1.5, and Borland BC++ 4 to 5.
	64	<P>
	65
	66	wxWindows 2 for Windows will also compile on Unix with gcc using Wine from <a href="http://www.winehq.org" target=_top>WineHQ</a>.
	67	The resulting executables are Unix binaries that work with the Wine Windows API emulator.<P>
	68
	69	You can also compile wxWindows 2 for Windows on Unix with Cygwin or Mingw32, resulting
	70	in executables that will run on Windows. So in theory you could write your applications
	71	using wxGTK or wxMotif, then check/debug your wxWindows for Windows
	72	programs with Wine, and finally produce an ix86 Windows executable using Cygwin/Mingw32,
	73	without ever needing a copy of Microsoft Windows. See the Technical Note on the Web site detailing cross-compilation.<P>
	74
	75	<h3><a name="wince">What about Windows CE?</a></h3>
	76
	77	This is under consideration, though we need to get wxWindows Unicode-aware first.
	78	There are other interesting issues, such as how to combine the menubar and toolbar APIs
	79	as Windows CE requires. But there's no doubt that it will be possible, albeit
	80	by mostly cutting down wxWindows 2 API functionality, and adding a few classes here
	81	and there. Since wxWindows for 2 produces small binaries (less than 300K for
	82	the statically-linked 'minimal' sample), shoehorning wxWindows 2 into a Windows CE device's limited
	83	storage should not be a problem.<P>
	84
	85	<h3><a name="winxp">What do I need to do for Windows XP?</a></h3>
	86
	87	In the same directory as you have your executable (e.g. foo.exe) you
	88	put a file called foo.exe.manifest in which you have something like
	89	the following:
	90
	91	<pre>
	92	<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
	93	<assembly
	94	xmlns="urn:schemas-microsoft-com:asm.v1"
	95	manifestVersion="1.0">
	96	<assemblyIdentity
	97	processorArchitecture="x86"
	98	version="5.1.0.0"
	99	type="win32"
	100	name="foo.exe"/>
	101	<description>Foo program</description>
	102	<dependency>
	103	<dependentAssembly>
	104	<assemblyIdentity
	105	type="win32"
	106	name="Microsoft.Windows.Common-Controls"
	107	version="6.0.0.0"
	108	publicKeyToken="6595b64144ccf1df"
	109	language="*"
	110	processorArchitecture="x86"/>
	111	</dependentAssembly>
	112	</dependency>
	113	</assembly>
	114	</pre>
	115
	116	If you want to add it to your application permanently,
	117	you can also include it in your .rc file using this
	118	line:<P>
	119
	120	<PRE>
	121	1 24 "winxp.manifest"
	122	</PRE>
	123
	124	In wxWindows 2.5, this will be in the wx/msw/wx.rc and
	125	so will happen automatically so long as you include wx.rc
	126	in your own .rc file.<P>
	127
	128	For an explanation of this syntax, please see
	129	<a href="http://delphi.about.com/library/bluc/text/uc111601a.htm" target=_new>this
	130	article</a>.
	131	<P>
	132
	133	<h3><a name="compilers">What compilers are supported?</a></h3>
	134
	135	Please see the wxWindows 2 for Windows install.txt file for up-to-date information, but
	136	currently the following are known to work:<P>
	137
	138	<ul>
	139	<li>Visual C++ 1.5, 4.0, 5.0, 6.0
	140	<li>Borland C++ 4.5, 5.0
	141	<li>Borland C++Builder 1.0, 3.0
	142	<li>Watcom C++ 10.6 (WIN32)
	143	<li>Cygwin b20
	144	<li>Mingw32
	145	<li>MetroWerks CodeWarrior 4
	146	</ul>
	147	<P>
	148
	149	There is a linking problem with Symantec C++ which I hope someone can help solve.
	150	<P>
	151
	152	<h3><a name="bestcompiler">Which is the best compiler to use with wxWindows 2?</a></h3>
	153
	154	It's partly a matter of taste, but I (JACS) prefer Visual C++ since the debugger is very
	155	good, it's very stable, the documentation is extensive, and it generates small executables.
	156	Since project files are plain text, it's easy for me to generate appropriate project files
	157	for wxWindows samples.<P>
	158
	159	Borland C++ is fine - and very fast - but it's hard (impossible?) to use the debugger without using project files, and
	160	the debugger is nowhere near up to VC++'s quality. The IDE isn't great.<P>
	161
	162	C++Builder's power isn't really used with wxWindows since it needs integration with its
	163	own class library (VCL). For wxWindows, I've only used it with makefiles, in which case
	164	it's almost identical to BC++ 5.0 (the same makefiles can be used).<P>
	165
	166	You can't beat Cygwin's price (free), and you can debug adequately using gdb. However, it's
	167	quite slow to compile since it does not use precompiled headers.<P>
	168
	169	CodeWarrior is cross-platform - you can debug and generate Windows executables from a Mac, but not
	170	the other way around I think - but the IDE is, to my mind, a bit primitive.<P>
	171
	172	Watcom C++ is a little slow and the debugger is not really up to today's standards.<P>
	173
	174	Among the free compilers the best choice seem to be Borland C++ command line
	175	tools and mingw32 (port of gcc to Win32). Both of them are supported by
	176	wxWindows.
	177
	178	<h3><a name="unicode">Is Unicode supported?</a></h3>
	179
	180	Yes, Unicode is fully supported under Windows NT/2000 (Windows 9x don't
	181	have Unicode support anyhow).
	182
	183	<h3><a name="doublebyte">Does wxWindows support double byte fonts (Chinese/Japanese/Korean etc.)?</a></h3>
	184
	185	An answer from <a href="mailto:goedde@logosoft.de">Klaus Goedde</a>:<p>
	186
	187	"For Japanese under Win2000, it seems that wxWindows has no problems to work with double byte char sets
	188	(I mean DBCS, that's not Unicode). First you have to install Japanese support on your Win2K system
	189	and choose for ANSI translation
	190	HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage=932 (default is 1252 for Western).
	191	Then you can see all the funny Japanese letters under wxWindows too.<P>
	192
	193	In a wxTextCtrl control you have to set the window style "wxTE_RICH", otherwise this control shows the wrong
	194	letters.
	195
	196	I don't now whether it works on non W2K systems, because I'm just starting using wxWindows."
	197	<P>
	198
	199	<h3><a name="dll">Can you compile wxWindows 2 as a DLL?</a></h3>
	200
	201	Yes (using the Visual C++ or Borland C++ makefile), but be aware that distributing DLLs is a thorny issue
	202	and you may be better off compiling statically-linked applications, unless you're
	203	delivering a suite of separate programs, or you're compiling a lot of wxWindows applications
	204	and have limited hard disk space.<P>
	205
	206	With a DLL approach, and with different versions and configurations of wxWindows
	207	needing to be catered for, the end user may end up with a host of large DLLs in his or her Windows system directory,
	208	negating the point of using DLLs. Of course, this is not a problem just associated with
	209	wxWindows!
	210	<P>
	211
	212	<h3><a name="exesize">How can I reduce executable size?</a></h3>
	213
	214	You can compile wxWindows as a DLL (see above, VC++/BC++ only at present). You should also
	215	compile your programs for release using non-debugging and space-optimisation options, but
	216	take with VC++ 5/6 space optimisation: it can sometimes cause problems.<P>
	217
	218	If you want to distribute really small executables, you can
	219	use <a href="http://www.un4seen.com/petite/" target=_top>Petite</a>
	220	by Ian Luck. This nifty utility compresses Windows executables by around 50%, so your 500KB executable
	221	will shrink to a mere 250KB. With this sort of size, there is reduced incentive to
	222	use DLLs. Another good compression tool (probably better than Petite) is <a href="http://upx.sourceforge.net/" target=_top>UPX</a>.
	223	<P>
	224
	225	Please do not be surprised if MinGW produces a statically-linked minimal executable of 1 MB. Firstly, gcc
	226	produces larger executables than some compilers. Secondly, this figure will
	227	include most of the overhead of wxWindows, so as your application becomes more
	228	complex, the overhead becomes proportionally less significant. And thirdly, trading executable compactness
	229	for the enormous increase in productivity you get with wxWindows is almost always well worth it.<P>
	230
	231	If you have a really large executable compiled with MinGW (for example 20MB) then
	232	you need to configure wxWindows to compile without debugging information: see
	233	docs/msw/install.txt for details. You may find that using configure instead
	234	of makefile.g95 is easier, particularly since you can maintain debug and
	235	release versions of the library simultaneously, in different directories.
	236	Also, run 'strip' after linking to remove all traces of debug info.
	237	<P>
	238
	239	<H3><a name="mfc">Is wxWindows compatible with MFC?</a></H3>
	240
	241	There is a sample which demonstrates MFC and wxWindows code co-existing in the same
	242	application. However, don't expect to be able to enable wxWindows windows with OLE-2
	243	functionality using MFC.<P>
	244
	245	<H3><a name="asuffix">Why do I get errors about FooBarA when I only use FooBar in my program?</H3>
	246
	247	If you get errors like
	248	<p>
	249	<center>
	250	<tt>no matching function for call to 'wxDC::DrawTextA(const char[5], int,
	251	int)'</tt>
	252	</center>
	253	<p>
	254	or similar ones for the other functions, i.e. the compiler error messages
	255	mention the function with the <tt>'A'</tt> suffix while you didn't
	256	use it in your code, the explanation is that you had included
	257	<tt><windows.h></tt> header which redefines many symbols to have such
	258	suffix (or <tt>'W'</tt> in the Unicode builds).
	259
	260	<p>
	261	The fix is to either not include <tt><windows.h></tt> at all or include
	262	<tt>"wx/msw/winundef.h"</tt> immediately after it.
	263
	264	<H3><a name="newerrors">Why my code fails to compile with strange errors about new operator?</a></H3>
	265
	266	The most common cause of this problem is the memory debugging settings in
	267	<tt>wx/msw/setup.h</tt>. You have several choices:
	268
	269	<ul>
	270	<li> Either disable overloading the global operator new completely by
	271	setting <tt>wxUSE_GLOBAL_MEMORY_OPERATORS</tt> and
	272	<tt>wxUSE_DEBUG_NEW_ALWAYS</tt> to 0 in this file
	273	<li> Or leave them on but do <tt>#undef new</tt> after including any
	274	wxWindows headers, like this the memory debugging will be still on
	275	for wxWindows sources but off for your own code
	276	</ul>
	277
	278	Notice that IMHO the first solution is preferable for VC++ users who can use
	279	the <a href="#vcdebug">VC++ CRT memory debugging features</a> instead.
	280
	281	<H3><a name="mfcport">How do I port MFC applications to wxWindows?</a></H3>
	282
	283	Set up your interface from scratch using wxWindows (especially wxDesigner --
	284	it'll save you a <i>lot</i> of time) and when you have a shell prepared, you can start
	285	'pouring in' code from the MFC app, with appropriate
	286	modifications. This is the approach I have used, and I found
	287	it very satisfactory. A two-step process then - reproduce the bare
	288	interface first, then wire it up afterwards. That way you deal
	289	with each area of complexity separately. Don't try to think MFC
	290	and wxWindows simultaneously from the beginning - it is easier to
	291	reproduce the initial UI by looking at the behaviour of the MFC
	292	app, not its code.
	293
	294	<H3><a name="crash">Why do I sometimes get bizarre crash problems using VC++ 5/6?</a></H3>
	295
	296	Some crash problems can be due to inconsistent compiler
	297	options (and of course this isn't limited to wxWindows).
	298	If strange/weird/impossible things start to happen please
	299	check (dumping IDE project file as makefile and doing text comparison
	300	if necessary) that the project settings, especially the list of defined
	301	symbols, struct packing, etc. are exactly the same for all items in
	302	the project. After this, delete everything (including PCH) and recompile.<P>
	303
	304	VC++ 5's optimization code seems to be broken and can
	305	cause problems: this can be seen when deleting an object Dialog
	306	Editor, in Release mode with optimizations on. If in doubt,
	307	switch off optimisations, although this will result in much
	308	larger executables. It seems possible that the library can be created with
	309	strong optimization, so long as the application is not strongly
	310	optimized. For example, in wxWindows project, set to 'Minimum
	311	Size'. In Dialog Editor project, set to 'Customize: Favor Small
	312	Code' (and no others). This will then work.<P>
	313
	314	<H3><a name="makefiles">How are the wxWindows makefiles edited under Windows?</a></H3>
	315
	316	As of wxWindows 2.1, there is a new system written by Vadim Zeitlin, that
	317	generates the makefiles from templates using tmake.<P>
	318
	319	Here are Vadim's notes:<P>
	320
	321	<blockquote>
	322	To use these new makefiles, you don't need anything (but see below).
	323	However, you should NOT modify them because these files will be
	324	rewritten when I regenerate them using tmake the next time. So, if
	325	you find a problem with any of these makefiles (say, makefile.b32)
	326	you'll need to modify the corresponding template (b32.t in this
	327	example) and regenerate the makefile using tmake.<P>
	328
	329	tmake can be found at
	330	<a href="http://www.troll.no/freebies/tmake.html" target=_new>www.troll.no/freebies/tmake.html</a>.
	331	It's a Perl5 program and so it needs Perl (doh). There is a binary for
	332	Windows (available from the same page), but I haven't used it, so
	333	I don't know if it works as flawlessly as "perl tmake" does (note
	334	for people knowing Perl: don't try to run tmake with -w, it won't
	335	do you any good). Using it extremely simple: to regenerate makefile.b32
	336	just go to distrib/msw/tmake and type<P>
	337
	338	<pre>tmake -t b32 wxwin.pro -o ../../src/msw/makefile.b32</pre><P>
	339
	340	The makefiles are untested - I don't have any of Borland, Watcom or
	341	Symantec and I don't have enough diskspace to recompile even with
	342	VC6 using makefiles. The new makefiles are as close as possible to the
	343	old ones, but not closer: in fact, there has been many strange things
	344	(should I say bugs?) in some of makefiles, some files were not compiled
	345	without any reason etc. Please test them and notify me about any problems.
	346	Better yet, modify the template files to generate the correct makefiles
	347	and check them in.<P>
	348
	349	The templates are described in tmake ref manual (1-2 pages of text)
	350	and are quite simple. They do contain some Perl code, but my Perl is
	351	primitive (very C like) so it should be possible for anybody to make
	352	trivial modifications to it (I hope that only trivial modifications
	353	will be needed). I've tagged the ol makefiles as MAKEFILES_WITHOUT_TMAKE
	354	in the cvs, so you can always retrieve them and compare the new ones,
	355	this will make it easier to solve the problems you might have.<P>
	356
	357	Another important file is filelist.txt: it contains the list of all
	358	files to be compiled. Some of them are only compiled in 16/32 bit mode.
	359	Some other are only compiled with some compilers (others can't compile
	360	them) - all this info is contained in this file.<P>
	361
	362	So now adding a new file to wxWindows is as easy as modifying filelist.txt
	363	(and Makefile.ams for Unix ports) and regenerating the makefiles - no
	364	need to modify all files manually any more.<P>
	365
	366	Finally, there is also a file vc6.t which I use myself: this one
	367	generates a project file for VC++ 6.0 (I didn't create vc5.t because
	368	I don't need it and can't test it, but it should be trivial to create
	369	one from vc6.t - probably the only things to change would be the
	370	version number in the very beginning and the /Z option - VC5 doesn't
	371	support edit-and=continue). This is not an officially supported way
	372	of building wxWindows (that is, nobody guarantees that it will work),
	373	but it has been very useful to me and I hope it will be also for
	374	others. To generate wxWindows.dsp run<P>
	375
	376	<pre>tmake -t vc6 wxwin.pro -o ../../wxWindows.dsp</pre><P>
	377
	378	Then just include this project in any workspace or open it from VC IDE
	379	and it will create a new workspace for you.<P>
	380
	381	If all goes well, I'm planning to create a template file for Makefile.ams
	382	under src/gtk and src/motif and also replace all makefiles in the samples
	383	subdirectories with the project files from which all the others will be
	384	generated. At least it will divide the number of files in samples
	385	directory by 10 (and the number of files to be maintained too).
	386	</blockquote>
	387
	388	<P>
	389
	390	<H3><a name="vcdebug">How do you use VC++'s memory leak checking instead of that in wxWindows?</a></H3>
	391
	392	Vadim Zeitlin:
	393
	394	<pre>
	395	On the VC++ level, it's just the matter of calling _CrtSetDbgFlag() in the very
	396	beginning of the program. In wxWindows, this is done automatically when
	397	compiling with VC++ in debug mode unless wxUSE_GLOBAL_MEMORY_OPERATORS or
	398	__NO_VC_CRTDBG__ are defined - this check is done in wx/msw/msvcrt.h which
	399	is included from app.cpp which then calls wxCrtSetDbgFlag() without any
	400	ifdefs.
	401
	402	This works quite well: at the end of the program, all leaked blocks with their
	403	malloc count are shown. This number (malloc count) can be used to determine
	404	where exactly the object was allocated: for this it's enough to set the variable
	405	_crtBreakAlloc (look in VC98\crt\srs\dbgheap.c line 326) to this number and
	406	a breakpoint will be triggered when the block with this number is allocated.
	407
	408	For simple situations it works like a charm. For something more complicated
	409	like reading uninitialized memory a specialized tool is probably better...
	410
	411	Regards,
	412	VZ
	413	</pre>
	414
	415	<P>
	416
	417	<H3><a name="shortcutproblem">Why are menu hotkeys or shortcuts not working in my application?</a></H3>
	418
	419	This can happen if you have a child window intercepting EVT_CHAR events and swallowing
	420	all keyboard input. You should ensure that event.Skip() is called for all input that
	421	isn'used by the event handler.<P>
	422
	423	It can also happen if you append the submenu to the parent
	424	menu {\it before} you have added your menu items. Do the append {\it after} adding
	425	your items, or accelerators may not be registered properly.<P>
	426
	427	<H3><a name="#regconfig">Why can I not write to the HKLM part of the registry with wxRegConfig?</a></H3>
	428
	429	Currently this is not possible because the wxConfig family of classes is
	430	supposed to deal with per-user application configuration data, and HKLM is
	431	only supposed to be writeable by a user with Administrator privileges. In theory,
	432	only installers should write to HKLM. This is still a point debated by the
	433	wxWindows developers. There are at least two ways to work around it if you really
	434	need to write to HKLM.<P>
	435
	436	First, you can use wxRegKey directly, for example:
	437
	438	<pre>
	439	wxRegKey regKey;
	440
	441	wxString idName(wxT("HKEY_LOCAL_MACHINE\\SOFTWARE\\My Company\\My Product\\Stuff\\"));
	442	idName += packid;
	443
	444	regKey.SetName(idName);
	445
	446	{
	447	wxLogNull dummy;
	448	if (!regKey.Create())
	449	{
	450	idName = wxT("HKEY_CURRENT_USER\\SOFTWARE\\My Company\\My Product\\Stuff\\");
	451	idName += packid;
	452	regKey.SetName(idName);
	453	if (!regKey.Create())
	454	return FALSE;
	455	}
	456	}
	457
	458	if (!regKey.SetValue(wxT("THING"), (long) thing)) err += 1;
	459
	460	regKey.Close();
	461
	462	</pre>
	463
	464	Or, you can employ this trick suggested by Istvan Kovacs:
	465
	466	<pre>
	467	class myGlobalConfig : public wxConfig
	468	{
	469	myGlobalConfig() :
	470	wxConfig ("myApp", "myCompany", "", "", wxCONFIG_USE_GLOBAL_FILE)
	471	{};
	472	bool Write(const wxString& key, const wxString& value);
	473	}
	474
	475	bool myGlobalConfig::Write (const wxString& key, const wxString& value)
	476	{
	477	wxString path = wxString ("SOFTWARE\\myCompany\\myApp\\") + wxPathOnly(key);
	478	wxString new_path = path.Replace ("/", "\\", true);
	479	wxString new_key = wxFileNameFromPath (key);
	480	LocalKey().SetName (wxRegKey::HKLM, path);
	481	return wxConfig::Write (new_key, value);
	482	}
	483	</pre>
	484
	485	<H3><a name="#access">Is MS Active Accessibility supported?</a></H3>
	486
	487	This is being worked on. Please see <a href="http://www.wxwindows.org/access.htm">this page</a>
	488	for the current status.
	489
	490	<P>
	491
	492	</font>
	493
	494	</BODY>
	495
	496	</HTML>