Listview notify_dispinfoT Messageformat
Robert Shearman
rob at codeweavers.com
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
overridden by CCM_SETUNICODEFORMAT.
> 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)
becomes:
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
value.
> 3. When sending notifications, convert to ASCII iff infoPtr->notifyFormat == NFR_ANSI
>
>
> If so, this is what we had before Aric did this change:
> http://cvs.winehq.org/cvsweb/wine/dlls/comctl32/listview.c.diff?r1=1.330&r2=1.331&f=h
> 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.
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/common/messages/ccm_setunicodeformat.asp)
>It's important to figure this one once and for all, so that we can fix all the
>controls properly.
>
>
Rob
More information about the wine-devel
mailing list