[wxWidgets.git] / docs / msw / issues.txt

Current issues and bugs
-----------------------

Debugging code
--------------

wxDebugContext and global memory operators doesn't work correctly,
for different (unresolved) reasons on different compilers.

1) In VC++ 5.0, if you use wxDebugAlloc for new and wxDebugFree
for delete, you get a crash to do with deallocating the debug
buffer in wxDebugContext. So although the global operators are
defined, they are #ifdefed to just call malloc and free to avoid
the problem. This means that non-object memory checking doesn't work.
The problem does seem to be something to do with a pointer
mysteriously changing its address, very similar to 2).

2) In BC++ 4.5, there isn't a crash, but instead the ofstream
pointer passed to SetStream from SetFile (which is called in
memcheck.cpp) gets mysteriously changed as it's passed to SetStream.
This means that when counting the number of outstanding memory
blocks, we can't compare the allocated block with m_debugStream
to say 'ignore this block because we can't free it before the
very end of the application'. Therefore it always looks like
there's a memory leak of one object, in memory.cpp, unless you
don't call wxDebugContext::SetFile.

The fact that pointers appear to change in both cases must
indicate a common problem and solution. If we could use the
standard global memory operators for ofstream and
wxDebugStreamBuf it might help, but I don't know how to do that -
I've redefined 'new' throughout as WXDEBUG_NEW (which is itself
defined as the 3-argument operator).

Owner-draw menus
----------------

If USE_OWNER_DRAWN = 1 and you create a wxMenu, you get 'all bets
are off' memory checking warnings from wxWindows.
Commit	Line	Data
2bda0e17 KB	1	Current issues and bugs
	2	-----------------------
	3
	4	Debugging code
	5	--------------
	6
	7	wxDebugContext and global memory operators doesn't work correctly,
	8	for different (unresolved) reasons on different compilers.
	9
	10	1) In VC++ 5.0, if you use wxDebugAlloc for new and wxDebugFree
	11	for delete, you get a crash to do with deallocating the debug
	12	buffer in wxDebugContext. So although the global operators are
	13	defined, they are #ifdefed to just call malloc and free to avoid
	14	the problem. This means that non-object memory checking doesn't work.
	15	The problem does seem to be something to do with a pointer
	16	mysteriously changing its address, very similar to 2).
	17
	18	2) In BC++ 4.5, there isn't a crash, but instead the ofstream
	19	pointer passed to SetStream from SetFile (which is called in
	20	memcheck.cpp) gets mysteriously changed as it's passed to SetStream.
	21	This means that when counting the number of outstanding memory
	22	blocks, we can't compare the allocated block with m_debugStream
	23	to say 'ignore this block because we can't free it before the
	24	very end of the application'. Therefore it always looks like
	25	there's a memory leak of one object, in memory.cpp, unless you
	26	don't call wxDebugContext::SetFile.
	27
	28	The fact that pointers appear to change in both cases must
	29	indicate a common problem and solution. If we could use the
	30	standard global memory operators for ofstream and
	31	wxDebugStreamBuf it might help, but I don't know how to do that -
	32	I've redefined 'new' throughout as WXDEBUG_NEW (which is itself
	33	defined as the 3-argument operator).
	34
884360bc JS	35	Owner-draw menus
	36	----------------
	37
	38	If USE_OWNER_DRAWN = 1 and you create a wxMenu, you get 'all bets
	39	are off' memory checking warnings from wxWindows.
	40