X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/884360bc11fe926bf91b23215bae719b562df91b..9df06f5b696cde13b1220ae6ec60dc6f32d2ab6f:/docs/msw/issues.txt diff --git a/docs/msw/issues.txt b/docs/msw/issues.txt index 080459bb80..2f245e467b 100644 --- a/docs/msw/issues.txt +++ b/docs/msw/issues.txt @@ -1,74 +1,29 @@ 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