How Windows Handle ANSIUnicode Characters and Strings

[Previous] [Next]

Windows 98

---

Windows 98 only supports ANSI window classes and ANSI window procedures.

When you register a new window class, you must tell the system the address of the window procedure responsible for processing messages for this class. For certain messages (such as WM_SETTEXT), the lParam parameter for the message is a pointer to a string. The system needs to know whether the window procedure requires that the string be in ANSI or Unicode before dispatching the message so that the message will be processed correctly.

You tell the system whether a window procedure expects ANSI strings or Unicode strings depending on which function you use to register the window class. If you construct the WNDCLASS structure and call RegisterClassA, the system thinks that the window procedure expects all strings and characters to be ANSI. Registering the window class with RegisterClassW causes the system to dispatch only Unicode strings and characters to the window procedure. Of course, the macro RegisterClass expands to either RegisterClassA or RegisterClassW, depending on whether UNICODE is defined when you compile the source module.

If you have a handle to a window, you can determine what type of characters and strings the window procedure expects by calling

 BOOL IsWindowUnicode(HWND hwnd); 

If the window procedure for the specified window expects Unicode, the function returns TRUE; otherwise, FALSE is returned.

If you create an ANSI string and send a WM_SETTEXT message to a window whose window procedure expects Unicode strings, the system will automatically convert the string for you before sending the message. You ll rarely need to call the IsWindowUnicode function.

The system will also perform automatic translations if you subclass a window procedure. Let s say that the window procedure for an edit control expects its characters and strings to be in Unicode. Then somewhere in your program you create an edit control and subclass the window s procedure by calling

 LONG_PTR SetWindowLongPtrA( HWND hwnd, int nIndex, LONG_PTR dwNewLong); 

or

 LONG_PTR SetWindowLongPtrW( HWND hwnd, int nIndex, LONG_PTR dwNewLong); 

and passing GCLP_WNDPROC as the nIndex parameter and the address to your subclass procedure as the dwNewLong parameter. But what happens if your subclass procedure expects ANSI characters and strings? This could potentially create a big problem. The system determines how to convert the strings and characters depending on which of the two functions above you use to perform the subclassing. If you call SetWindowLongPtrA, you re telling the system that the new window procedure (your subclass procedure) is to receive ANSI characters and strings. In fact, if you were to call IsWindowUnicode after calling SetWindowLongPtrA, you would see that it would return FALSE, indicating that the subclassed edit window procedure no longer expects Unicode characters and strings.

But now we have a new problem: how do we ensure that the original window procedure gets the correct type of characters and strings? The system needs to have two pieces of information to correctly convert the characters and strings. The first is the form that the characters and strings are currently in. We inform the system by calling either CAllWindowsProcA or CallWindowProcW:

 LRESULT CallWindowProcA( WNDPROC wndprcPrev, HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam); LRESULT CallWindowProcW( WNDPROC wndprcPrev, HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam); 

If the subclass procedure has ANSI strings that it wants to pass to the original window procedure, the subclass procedure must call CallWindowProcA. If the subclass procedure has Unicode strings that it wants to pass to the original window procedure, the subclass procedure must call CallWindowProcW.

The second piece of information that the system needs is the type of characters and strings that the original window procedure expects. The system gets this information from the address of the original window procedure. When you call the SetWindowLongPtrA or the SetWindowLongPtrW function, the system checks to see whether you are subclassing a Unicode window procedure with an ANSI subclass procedure or vice versa. If you re not changing the type of strings expected, SetWindowLongPtr simply returns the address of the original window procedure. If you re changing the type of characters and strings that the window procedure expects, SetWindowLongPtr doesn t return the actual address of the original window procedure; instead, it returns a handle to an internal subsystem data structure.

This structure contains the address of the original window procedure and a value that indicates whether that procedure expects Unicode or ANSI strings. When you call CallWindowProc, the system checks whether you are passing a handle of one of the internal data structures or the address of a window procedure. If you re passing the address of a window procedure, the original window procedure is called and no character and string conversions need to be performed.

If, on the other hand, you re passing the handle of an internal data structure, the system converts the characters and strings to the appropriate type (Unicode or ANSI) and then calls the original window procedure.