PRB: Controls Do Not Receive Expected Messages

• Microsoft Win32s, versions 1.1, 1.15, and 1.2

SYMPTOMS

A Win32-based application works as expected under Windows NT, but under Win32s, control messages are not received by the application as expected.

Here are some possible scenarios symptomatic of this problem:

• Sending LB_GETSELITEMS to a superclassed list box does not work.
• The custom control procedure does not receive messages such as CB_ADDSTRING, CB_INSERTSTRING, or CB_SHOWDROPDOWN.
• The wrong control message is received.

CAUSE

This is a Win32s limitation. When a Win32-based application sends a message, Win32s processes the message and passes it to Windows. Windows is responsible for delivering the message. Win32s truncates wParam from a DWORD to a WORD. Most messages do not use the high word of wParam, however, if you do use the high word of wParam, be aware that it will be lost under Win32s.

In the course of processing known messages (messages that are not user- defined), Win32s translates any pointers in lParam. In addition, if a message is new to Win32, the corresponding Windows message is used instead. For example, the Windows WM_CTLCOLOR was replaced in Win32 with WM_CTLCOLORBTN, WM_CTRLCOLORDLG, WM_CTLCOLOREDIT, and so on. Therefore, if a Win32-based application uses WM_CTRLCOLORBTN, Win32s passes WM_CTLCOLOR to Windows with a type of CTLCOLOR_BTN.

Control messages are not unique on Windows version 3.1 as they are on Windows NT. Control messages on Windows have values above WM_USER, however, messages for one control may share the same number as a message of another control. For example, both CB_ADDSTRING and LB_DELETESTRING are defined as WM_USER+3. Therefore, when Win32s receives the WM_USER+3 message, it needs to determine the correct control message. Win32s looks at the window class of the window that will receive the message and maps the message accordingly. If the window class is not a recognized control class, as in the case of a superclassed control, the message is not mapped, which results in unexpected behavior.

RESOLUTION

In order to get the desired behavior under Win32s, make the custom control use a recognized control class (such as "combobox") and subclass the window procedure instead of superclassing. If you need to subclass before the WM_CREATE/WM_NCCREATE messages, use a CBT hook. You will not be able to change the class icon and cursor, but the messages will be handled correctly.

If you need to use a custom control, create and use user-defined messages instead of the control messages.

STATUS

This behavior is by design.