Listview notify_dispinfoT Messageformat

Robert Shearman rob at
Sun Oct 31 04:50:33 CST 2004

Dimitrie O. Paun wrote:

>On Wed, Oct 27, 2004 at 09:28:33PM +0100, Robert Shearman wrote:
>>To summarise: *all* common control notifications should be sent in the 
>>same format (ANSI/Unicode) as their parent (except if overriden by the 
>>CCS_SETUNICODEFORMAT message). It should not be based on the message 
>>sent to the control.
>Just to be 100% clear:
>  -- what do you mean by "in the same format as their parent"?

The format is retrieved using the WM_NOTIFYFORMAT message, but can be 

>     From your patch, it seems that:
>	1. In WM_CREATE, we have to query the notify format as such:
>  infoPtr->hwndNotify = lpcs->hwndParent;
>  infoPtr->notifyFormat = SendMessageW(infoPtr->hwndNotify, WM_NOTIFYFORMAT,
>                                       (WPARAM)infoPtr->hwndSelf, (LPARAM)NF_QUERY);

Yes, that is correct. It would be a lot better to use a boolean flag 
rather than storing the actual format code so that:
if (infoPtr->notifyFormat == NFR_UNICODE)
if (infoPtr->bUnicode)

>	2. Handle WM_NOTIFYFORMAT, by querying the parent again:
>  infoPtr->notifyFormat = SendMessageW(hwndFrom, WM_NOTIFYFORMAT, (WPARAM)infoPtr->hwndSelf, NF_QUERY);

Yes. It should also handle the NF_QUERY case in the WM_NOTIFYFORMAT 
handler so that child windows, like the header control, will get a sane 

>        3. When sending notifications, convert to ASCII iff infoPtr->notifyFormat == NFR_ANSI
>     If so, this is what we had before Aric did this change:
>     What was wrong with the code before? It tried to send the notification
>     in the format specified by infoPtr->notifyFormat. The dependance on
>     the the type of message that was sent to the control is just to do
>     the conversion when we have to. That is:
>            fmt-of-msg-sent-to-ctrl     infoPtr->notifyFormat       conversion-required
>               !isW (ASCII)                    NFR_ANSI                   no
>                isW (Unicode)                  NFR_ANSI                   yes
>               !isW (ASCII)                    NFR_UNICODE                yes
>                isW (Unicode)                  NFR_UNICODE                no
>     The old code looked as isW only to determine if any conversion was required
>     (which I think you have to), but the format of the actual notification was
>     strictly determined by infoPtr->notifyFormat:
>     if (infoPtr->notifyFormat == NFR_ANSI)
>         realNotifCode = get_ansi_notification(notificationCode);
>     else
>         realNotifCode = notificationCode;
>     bResult = notify_hdr(infoPtr, realNotifCode, (LPNMHDR)pdi);
>     So, what was wrong with the original code?

The old code does indeed send the correct notifications. Maybe there was 
a bug in the function somewhere that prompted Aric to make his change.
However, the code could be a lot simpler by doing conversions from A to 
W on incoming messages and then only doing W to A conversions for the 
notifications, rather than the matrix of 4 cases you described above.

>  -- CCS_SETUNICODEFORMAT message: this is a flag, not a message, no? If so, what is
>     its semantics? If set, we have to ignore infoPtr->notifyFormat, and always send
>     notifications in Unicode format?

That was a mistake. I meant CCM_SETUNICODEFORMAT. 

>It's important to figure this one once and for all, so that we can fix all the
>controls properly.


More information about the wine-devel mailing list