As I was working at enabling CodeBrowser for UTF-8, I meet a lot of trouble with memory management bug. The new application version was always hanging up at start up, what ever was the number of review I could do on memory allocation stuff.
I was noticing that something goes wrong with the Windows TabView, beceause tab labels were full of garbage (juste before the crash). I first though that a memory big caused to passe alterated strings to "send message".
But finaly, I has a doubt, and checked some structure, ... how lucky I was to do so, beceause there is indeed a bug lib/include/win32/commctrl.zc
The bug is in the wrong definition of a structure, and this structure is errosneously defined only for its UTF-16 version (the one posfixed with W). That's why the bug never expressed with the standard version.
Look at this excerpt from lib/include/win32/commctrl.zc
| struct LPTCITEMA
| mask: UINT
| dwState: DWORD
| dwStateMask: DWORD
| pszText: LPSTR
| cchTextMax: int
| iImage: int
| lParam: LPARAM
| end
| typedef TCITEMA = local LPTCITEMA
|
| struct LPTCITEMW
| mask: UINT
| dwState: DWORD
| dwStateMask: DWORD
| lpReserved1: UINT
| lpReserved2: UINT
| pszText: LPWSTR
| cchTextMax: int
| iImage: int
| lParam: LPARAM
| end
You sse that LPTCITEMW has two more fields than LPTCITEMA. lpReserved1 and lpReserved2 should not be there, beceause there are the olds names of these fields with Windows95/98.
Now look at the specification from the Microsoft SDK.
Well, beceause of that, all the fields after those two ones, were shifted two word to hight. I've just removed them, and now the UTF-16 version of CodeBrowser do not crash any more at startup.
Don't worry.... this annecdote made me to have a deep look at avoiding bug in memory management, so this story was not finally a bad thing.
Just remove the exceded fields from your source.
Will still have a bit of work at this adaptation of the application, so do not want to provide it right now... but probably soon or later... I hope
:)
I'm happy, I feel that it gonna work now
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I was working at enabling CodeBrowser for UTF-8, I meet a lot of trouble with memory management bug. The new application version was always hanging up at start up, what ever was the number of review I could do on memory allocation stuff.
I was noticing that something goes wrong with the Windows TabView, beceause tab labels were full of garbage (juste before the crash). I first though that a memory big caused to passe alterated strings to "send message".
But finaly, I has a doubt, and checked some structure, ... how lucky I was to do so, beceause there is indeed a bug lib/include/win32/commctrl.zc
The bug is in the wrong definition of a structure, and this structure is errosneously defined only for its UTF-16 version (the one posfixed with W). That's why the bug never expressed with the standard version.
Look at this excerpt from lib/include/win32/commctrl.zc
| struct LPTCITEMA
| mask: UINT
| dwState: DWORD
| dwStateMask: DWORD
| pszText: LPSTR
| cchTextMax: int
| iImage: int
| lParam: LPARAM
| end
| typedef TCITEMA = local LPTCITEMA
|
| struct LPTCITEMW
| mask: UINT
| dwState: DWORD
| dwStateMask: DWORD
| lpReserved1: UINT
| lpReserved2: UINT
| pszText: LPWSTR
| cchTextMax: int
| iImage: int
| lParam: LPARAM
| end
You sse that LPTCITEMW has two more fields than LPTCITEMA. lpReserved1 and lpReserved2 should not be there, beceause there are the olds names of these fields with Windows95/98.
Now look at the specification from the Microsoft SDK.
|typedef struct tagTCITEM {
| UINT mask;
|#if (_WIN32_IE >= 0x0300)
| DWORD dwState;
| DWORD dwStateMask;
|#else
| UINT lpReserved1;
| UINT lpReserved2;
|#endif
| LPTSTR pszText;
| int cchTextMax;
| int iImage;
| LPARAM lParam;
|} TCITEM, *LPTCITEM;
Well, beceause of that, all the fields after those two ones, were shifted two word to hight. I've just removed them, and now the UTF-16 version of CodeBrowser do not crash any more at startup.
Don't worry.... this annecdote made me to have a deep look at avoiding bug in memory management, so this story was not finally a bad thing.
Just remove the exceded fields from your source.
Will still have a bit of work at this adaptation of the application, so do not want to provide it right now... but probably soon or later... I hope
:)
I'm happy, I feel that it gonna work now
Sorry about that. I didn't even remember that I had added definitions for Windows unicode.
Marc