Hello friends, I would like to talk a bit about a (probable) limitation with unicode names when they are used for creating embedded controls in resource files. Let's take for example this piece of code from richedit.h:
#if defined(__GNUC__) # define RICHEDIT_CLASS20W (const WCHAR []){ 'R','i','c','h','E','d','i','t','2','0','W',0 } #elif defined(_MSC_VER) # define RICHEDIT_CLASS20W L"RichEdit20W" #else static const WCHAR RICHEDIT_CLASS20W[] = { 'R','i','c','h','E','d','i','t','2','0','W',0 }; #endif
Because the famous UCS-4 "issue", the control name is splitted in its single letters. While this can work in almost all situations with C/C++ sources, it is absolutely not possible to put a richedit control in RC files. For example, if I put a Richedit control into a dialog box, it will crash since the letter by letter format won't be recognized by the resource compiler.
From the above example, I was wondering what you think about doing a change
like this one:
#if defined _MSC_VER || defined RC_INVOKED || sizeof(wchar_t) == 2 # define RICHEDIT_CLASS20W L"RichEdit20W" #elif defined(__GNUC__) # define RICHEDIT_CLASS20W (const WCHAR []){ 'R','i','c','h','E','d','i','t','2','0','W',0 } #else static const WCHAR RICHEDIT_CLASS20W[] = { 'R','i','c','h','E','d','i','t','2','0','W',0 }; #endif
We will fall in the first case when the name expressed as string is currently recognized: 1) because we are running under Microsoft Visual C++ 2) because it is used by resource compiler 3) because the string format is currently safe since we are under UCS-2 instead of UCS-4. Perhaps this point is not written as good as you want... I do not know if you prefer to use some informations emitted by configure script or you will prefer to simply check the size of wchar_t.
The second case is the specific hack normally used until now with GCC.
The third case is the last chance solution, as it was before.
I moved the __GNUC__ case after the one used by _MSC_VER because __GNUC__ and RC_INVOKED are both declared in windres. Now I took this fragment from richedit.h as example, but perhaps I have also seen other places where the resource compiler could be "rejected". I believe that this fix actually seems to be very helpful for porting some win32 apps.
What do you think?
Sincerely,
Carlo Bramini.