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?

[Alexandre Julliard]

Nikolay Sivov  writes:
> 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?

Standard messages like CB_GETLBTEXT should be translated automatically,
you should be able to always handle them as Unicode.

[Nikolay Sivov]

Alexandre Julliard wrote:
> Nikolay Sivov  writes:
> > 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?
>
> Standard messages like CB_GETLBTEXT should be translated automatically,
> you should be able to always handle them as Unicode.

Ah thanks, so whar<->char is done automatically depending on 
SendMessageA or SendMessageW used?

Next question if you don't mind: IsWindowUnicode() for Wine created 
common controls window handles
will always return TRUE, so I could easily drop such checks?

[Dmitry Timoshkov]

"Nikolay Sivov"  wrote:
> Next question if you don't mind: IsWindowUnicode() for Wine created 
> common controls window handles
> will always return TRUE, so I could easily drop such checks?

Subclassing a window may change that.

There is a bunch of IsWindowUnicode() tests in dlls/user32/tests/win.c,
test_IsWindowUnicode() and dlls/user32/tests/class.c,test_builtinproc().

[Alexandre Julliard]

Nikolay Sivov  writes:
> Ah thanks, so whar<->char is done automatically depending on
> SendMessageA or SendMessageW used?
>
> Next question if you don't mind: IsWindowUnicode() for Wine created
> common controls window handles
> will always return TRUE, so I could easily drop such checks?

I expect you could, but I have no idea what things like
CBEM_SETUNICODEFORMAT are really supposed to do. Some tests are
probably in order.