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
