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.