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:
- 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)
- 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&... 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/pla...)
It's important to figure this one once and for all, so that we can fix all the controls properly.
Rob