IsWindowUnicode() is always true after RegisterClassW

[Nikolay Sivov]

Is it ok that IsWindowUnicode() returns 1 for windows created with -A calls?

I've just another unrelated issue for Comboex and spotted then I'm 
apparently using
unicode window (as reported by this call). But it was created with
---
CreateWindowExA and class WC_COMBOBOXEXA
---

Currently comboex code depends on being unicode window or not, so it 
could cause problems.

Looking at user32 code:
---
BOOL WINPROC_IsUnicode( WNDPROC proc, BOOL def_val )
{
    WINDOWPROC *ptr = handle_to_proc( proc );

    if (!ptr) return def_val;
    if (ptr->procA && ptr->procW) return def_val;  /* can be both */
    return (ptr->procW != NULL);
}
---
If I'm creating with -A call def_val = = FALSE and the only reason why I 
got 1 from IsWindowUnicode is
that ptr->procA is null.

Further WINPROC_AllocProc() with both not null parameters is used for 
"builtin" user32 classes and default procedure.

Since we're registering comctl32 classes as unicode with RegisterClassW, 
IsWindowUnicode() becomes noop for that,
cause it's always unicode.

This matches windows behavior actually (at least for ComboEx on XP SP2) 
and that's how it works.

The question is how could I handle CB_GETLBTEXT properly for ComboEx? 
For Combobox it's obvious cause
we know is it unicode or not, for Comboex caller should rely on 
IsWindowUnicode() for this control for buffer format or what?

Any thoughts how to deal with this or am I missing something?