| | 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 | Config/registry classes |
| | 36 | ----------------------- |
| | 37 | |
| | 38 | Problems with Karsten's/Vadim's existing AppConfig classes: |
| | 39 | |
| | 40 | - use char* a lot instead of wxString |
| | 41 | - rather hard to understand |
| | 42 | - will need fairly substantial rewrite |
| | 43 | - no native .ini functions (?) for guaranteed Windows |
| | 44 | compatibility |
| | 45 | - new wxWin docs required |
| | 46 | |
| | 47 | Good things: |
| | 48 | |
| | 49 | - exists! |
| | 50 | - FileConfig independent of OS |
| | 51 | - specifying a base class that will meet nearly all needs for |
| | 52 | derived classes |
| | 53 | - enumerator |
| | 54 | |
| | 55 | Other features we should probably have: |
| | 56 | |
| | 57 | - ability to specify vendor name/app name in constructor |
| | 58 | - under Windows, ability to read/write all areas of registry |
| | 59 | as an option |
| | 60 | |
| | 61 | Options: |
| | 62 | |
| | 63 | - rewrite AppConfig |
| | 64 | - start from own CRegistry class |
| | 65 | - take elements from both |
| | 66 | - do the Windows stuff, let someone else write/adapt the |
| | 67 | non-Windows classes |
| | 68 | |
| | 69 | Owner-draw menus |
| | 70 | ---------------- |
| | 71 | |
| | 72 | If USE_OWNER_DRAWN = 1 and you create a wxMenu, you get 'all bets |
| | 73 | are off' memory checking warnings from wxWindows. |
| | 74 | |
projects / wxWidgets.git / blame_incremental