CallWindowProcW When to use

[whatsupcb]

hey everyone

i have difficulties in understanding what's going on with UNICODE.

example1:
I create a listbox with createwindow (not the UNICODE)
i subclass it with the unicode version
SetWindowLongPtrW
in the subclassed procedure i use ANSI CallWindowProc

I use UNICODE SendMessageW to send UNICODE strings
and I Use ANSI SendMessage to send ANSI strings

everything seems to be OK

the subclassed listbox control got the UNICODE strings
and the ANSI string with no problem..


example2:
the same thing as example1
except that the control is EDIT

whether i send ANSI whether UNICODE strings
at the end i get a truncated string
that means there was a mismatch between ANSI and UNICODE

to fix this, in the subclassed procedure I use the UNICODE CallWindowProcW
now the UNICODE strings arrive correctly to the control.


my question is:
is there some constant rule when to use CallWindowProcW/CallWindowProc

why with listbox i DONT need the UNICODE
and with EDIT I MUST use the UNICODE CallWindowProcW

I really need to know what's going on so I can use ANSI/UNICODE correctly.

third question is
i create custom control
and i want it to optionally handle UNICODE strings via sendmessageW sent to it.
when I create it, do i MUST use CreateWindowExW or it's OK to use CreateWindowEx ?

some details:
I use GPP.
I use ONLY Windows API, no framework
when i compile i DONT use #define UNICODE (and I DONT want to use it)
so my app is actually ANSI
and when i need UNICODE i use it as described above

[George P]

I Use ANSI SendMessage to send ANSI strings

Since you are using select Unicode versions of Windows functions consider using the explicit ANSI versions, SendMessageA for example when you want to use ANSI WinAPI functions.

What is the compiler/IDE you are using? Visual Studio since the 2015 version defaults to using Unicode encoding unless you manually select otherwise in the project's property pages.

One thing to note about CallWindowProc:

Microsoft Docs wrote:

The CallWindowProc function handles Unicode-to-ANSI conversion. You cannot take advantage of this conversion if you call the window procedure directly.

https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-callwindowprocw

[George P]

Something else to consider about ANSI vs. Unicode versions of WinAPI functions, structs and data-types.....what version(s) of Windows are you targeting?

Win XP, x86 or x64, and later is pure Unicode character set operations. Win9X/Me had hybrid ANSI/Unicode functions. Win9X is officially DEAD!

Targeting Win XP or later using predominate ANSI character set encoding is likely to have serious performance impacts on your app. Windows has to translate the ANSI calls to Unicode and back to ANSI.

Calling a WinAPI function that can be either ANSI or Unicode without explicitly using the A or W version depends on the compiler. Change/update the compiler and it can change the default character set encoding. If you don't explicitly use the A or W version suddenly your code could fail to compile.

I personally use when writing WinAPI apps using Visual Studio (2015, 2017, 2019 and now 2022) I use Unicode character encoding (A or W) for everything. VS defaults to Unicode encoding.

One minor exception, reading/writing plain Jane text files. Then I read/write using the explicitly designated ANSI versions of the WinAPI functions.