fix for bug in wxEditableListBox in connection with new wxListCtrl

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

diff --git a/docs/msw/issues.txt b/docs/msw/issues.txt
index d8df16c5833c955d08f73b2db7a25edf57848e06..2f245e467b6783134c94004f7e1af31497ed7d89 100644 (file)
--- a/docs/msw/issues.txt
+++ b/docs/msw/issues.txt
@@ -1,40 +1,29 @@
 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.
+Memory-checking subsystem
+-------------------------
+
+This conflicts with wxUSE_IOSTREAMSH = 0 using MS VC++ 5.0
+(crashes the template code). It should be switched off if you
+wish to use wxUSE_IOSTREAMSH = 0.
+
+BC++ in 16-bit mode
+-------------------
+
+resource.cpp has to be split into two to compile (hence
+resourc2.cpp). Unfortunately we still get the error:
+
+        Segment TEXT_RESOURCE exceeds 64K.
+
+The solution is probably to load wxResourceBitListTable
+dynamically using LoadString to load the names, and initialize the table
+at wxWindows start-up.
+
+Meanwhile the work-around is to switch wxUSE_WX_RESOURCES to 0
+(done in setup.h if BC++/16-bit mode is detected).
+
+See also:
+ http://www.inprise.com/devsupport/borlandcpp/ti_list/TI703.html
+ http://www.inprise.com/devsupport/borlandcpp/ti/TI1007.html