more wxListCtrl drawing fixes - scrolling still doesn't work under wxGTK

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

diff --git a/docs/msw/issues.txt b/docs/msw/issues.txt
index 080459bb80b9aebbf79a9baf005ec45c39f08342..2f245e467b6783134c94004f7e1af31497ed7d89 100644 (file)
--- a/docs/msw/issues.txt
+++ b/docs/msw/issues.txt
@@ -1,74 +1,29 @@
 Current issues and bugs
 -----------------------
 
 Current issues and bugs
 -----------------------
 

-Debugging code
---------------
+Memory-checking subsystem
+-------------------------

 
 

-wxDebugContext and global memory operators doesn't work correctly,
-for different (unresolved) reasons on different compilers.
+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.

 
 

-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).
+BC++ in 16-bit mode
+-------------------

 
 

-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.
+resource.cpp has to be split into two to compile (hence
+resourc2.cpp). Unfortunately we still get the error:

 
 

-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).
+        Segment TEXT_RESOURCE exceeds 64K.

 
 

-Config/registry classes
------------------------
-
-Problems with Karsten's/Vadim's existing AppConfig classes:
-
-- use char* a lot instead of wxString
-- rather hard to understand
-- will need fairly substantial rewrite
-- no native .ini functions (?) for guaranteed Windows
-  compatibility
-- new wxWin docs required
-
-Good things:
-
-- exists!
-- FileConfig independent of OS
-- specifying a base class that will meet nearly all needs for
-  derived classes
-- enumerator
-
-Other features we should probably have:
-
-- ability to specify vendor name/app name in constructor
-- under Windows, ability to read/write all areas of registry
-  as an option
-
-Options:
-
-- rewrite AppConfig
-- start from own CRegistry class
-- take elements from both
-- do the Windows stuff, let someone else write/adapt the
-  non-Windows classes
+The solution is probably to load wxResourceBitListTable
+dynamically using LoadString to load the names, and initialize the table
+at wxWindows start-up.

 
 

-Owner-draw menus
-----------------
+Meanwhile the work-around is to switch wxUSE_WX_RESOURCES to 0
+(done in setup.h if BC++/16-bit mode is detected).

 
 

-If USE_OWNER_DRAWN = 1 and you create a wxMenu, you get 'all bets
-are off' memory checking warnings from wxWindows.
+See also:
+ http://www.inprise.com/devsupport/borlandcpp/ti_list/TI703.html
+ http://www.inprise.com/devsupport/borlandcpp/ti/TI1007.html