docs/msw/issues.txt

   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
  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