TreeView notifications fix

[Dimitrie O. Paun]

On 17 Mar 2003, Mike Hearn wrote:

> > You mean just making the if() be trivially true?
> 
> As in always using the A version (not called get_notifycode)

Huh? What do you mean "not called get_notifycode"???

What I mean by makgin the if() trivially true is:

-    if (!infoPtr->bNtfUnicode)
+    if (TRUE)

That is, always translating to the A version.

> > What do you mean? It was already using get_notifycode, no changes
> > are needed, AFAIK. What exaclty did you change?
> 
> It wasn't using get_notifycode before (which is why I didn't see that
> function), it always returned the W version, regardless of what the
> query had returned. See the original patch:
> 
> -                                       TVN_SELCHANGINGW,
> +                                       infoPtr->bNtfUnicode ?
> TVN_SELCHANGINGA : TVN_SELCHANGINGW,

It was using it, just search for it in the code. For example, in the example
you give above, we have:

        if (TREEVIEW_SendTreeviewNotify(infoPtr,
                                        TVN_SELCHANGINGW,
                                        cause,
                                        TVIF_HANDLE | TVIF_STATE | TVIF_PARAM,
                                        prevSelect,
                                        newSelect))

And if you check the definition of TREEVIEW_SendTreeviewNotify, you see:

nmhdr.hdr.code = get_notifycode(infoPtr, code);

So no modifications are necessary, right?
 
> > Can you also look to duplicate the tests for the listview as well?
> > That stange behaviour for listview bothers me greatly.
> 
> I don't have VC++, so I'll look into getting mingw setup. I thought Aric
> did test cases and showed that Windows ignored the requested format? So
> it might be a different bug.

You don't need VC++, the Makefile that came with the test is for mingw.
 
> Well, the result of WM_NOTIFYFORMAT is determined by the default window
> procedure, which calls IsWindowUnicode.
> 
> IsWindowUnicode checks the type of the window procedure, which for
> Winamp prefs dialog is ANSI on W2K but Unicode on Wine. So,

And this is a bug, no?

> IsWindowUnicode() could well be correct and the bug lies elsewhere. But

How can that be, if we get different results than on Windows?

> WinAmp calls CreateWindowExW, which means a unicode winproc, so it
> should be correct. That means either the wrong CreateWindowEx is being
> called (is it possible?), or the logic for determining whether a window
> is unicode or not is more complex than just "what type is the wndproc?".

That seems to be the case, yes. Maybe they look somehow at the type of 
executable? Is there anything about Unicode in the executable?

-- 
Dimi.