]> git.saurik.com Git - wxWidgets.git/blobdiff - docs/html/faqmsw.htm
Added possibility of 2-step initialisation, and wxWIZARD_EX_HELPBUTTON style.
[wxWidgets.git] / docs / html / faqmsw.htm
index b373e725def41cfe85abbf089e3cb05ea0163b12..be0f8d909149dbb1fbeda5712b782a9832cbbe66 100644 (file)
@@ -8,10 +8,10 @@
 
 <font face="Arial, Lucida Sans, Helvetica">
 
-<table width=100% border=4 cellpadding=5 cellspacing=0>
+<table width=100% border=0 cellpadding=5 cellspacing=0>
 <tr>
-<td bgcolor="#660000">
-<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
+<td bgcolor="#C4ECF9">
+<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#000000">
 wxWindows 2 for Windows FAQ
 </font>
 </td>
@@ -146,6 +146,127 @@ There is a sample which demonstrates MFC and wxWindows code co-existing in the s
 application. However, don't expect to be able to enable wxWindows windows with OLE-2
 functionality using MFC.<P>
 
+<H3>Why do I sometimes get bizarre crash problems using VC++ 5/6?</H3>
+
+Some crash problems can be due to inconsistent compiler
+options (and of course this isn'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'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 'Minimum
+Size'. In Dialog Editor project, set to 'Customize: Favor Small
+Code' (and no others). This will then work.<P>
+
+<H3>How are the wxWindows makefiles edited under Windows?</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's notes:<P>
+
+<blockquote>
+To use these new makefiles, you don'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'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'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
+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'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
+(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'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'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't create vc5.t because
+I don't need it and can'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'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'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>How do you use VC++'s memory leak checking instead of that in wxWindows?</H3>
+
+Vadim Zeitlin:
+
+<pre>
+On the VC++ level, it'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'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>
+
 
 </font>