X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/b8c631bb299230a18a9d2bbb26d28a426c161a8f..9146872cb5243c629dfb0afc51fd5d8d8ca22826:/docs/msw/issues.txt diff --git a/docs/msw/issues.txt b/docs/msw/issues.txt index d8df16c583..be643eac48 100644 --- 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 wxWidgets 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