TreeView notifications fix

[Mike Hearn]

> This sounds fairly simple, and it's exactly what our controls do.
> Until sometimes in Nov 2002, when Aric Stewart posted this:
>     http://www.winehq.com/hypermail/wine-devel/2002/11/1167.html
> That is, it seems like the listview always sends notifications
> in ANSI, no matter what you do! This obviously doesn't make much
> sense, but Aric said he tested it, and that's how it works. As
> a result he posted this patch, which latter got into the tree:
>     http://www.winehq.com/hypermail/wine-patches/2002/11/0276.html

Right, I found that this morning.

> At the time I was trying to figure out a similar problem in the
> Treeview, whereas putty broke when we did the 'right' thing and
> started sending Unicode notifications. It seemed then obvious to
> me that the fix would be to translate all notifications back to
> ANSI, as in the listview case, but for some unknown reason that
> did not fix Putty on my box, so I never sent the patch.
> (BTW, if you want to play with this idea, the thing to do is
>  to modify the get_notifycode() function, not the callers).

And yes, I found that this morning as well :) At least in WinAmp,
changing it to ansi seems to fix it....

> In Feb 2003, Drew "DanteAliegri" Ogle <dantealiegri at umbc.edu>
> started looking into this problem, and I told him the story.

Which he repeated to me on IRC on sunday (so big thanks to dante)

> He wasn't too impressed (and rightfully so!), and he maintained
> that the Unicode notifications are actually sent. I asked him
> if he can run some tests, and he did. Here is what he found:

This bit confuses me... what do you mean by actually sent? As in,
actually sent on Windows?

At least one issue seems to be that the NOTIFYFORMAT message returns
different results under Wine and Win2K, on Windows the WinAmp prefs
dialog wants ANSI, on Wine it wants Unicode. So perhaps the bug is
actually in the way Wine determines whether a dialog is ansi/unicode,
and the treeview (and winamp) are both correct?

I couldn't figure out how to tell for sure what type a given window is
under Windows (in wine you can watch the traces). Is there a way, using
a spy tool or something?

>   So, this rather simple testcase shows that at least in XP..
>   The executables are at  http://open-socket.dyndns.org/~dante/execs.tar.bz2
>   atest recieves TVN_SELCHANGEDA
>   and wtest recieves TVN_SELCHANGEDW
> 
>   Also ,
>   http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/CommCtls/Common/Messages/WM_NOTIFYFORMAT.asp
>   may be useful.
> 
>   In the remarks section it addresses this problem.
> 
> I've attached the test program to this message, in case anyone
> wants to play with it. It would be very interesing if people
> ran the two executables that Drew provided on different versions
> of Windows, and see what we get. Also, it would be more than
> interesting if we could modify the tests to create a listview
> instead, and see if the listview never sends a Unicode notification.

Well, I changed treeview.c to use get_notifycode (ie it's doing the
right thing). That breaks WinAmp, probably trillian and putty too.

The test cases now work OK, and give expected results. They give
expected results on Win2K Terminal Server edition as well.

So it looks like the treeview component isn't buggy on Windows, it does
send Unicode when it's asked to.

That just makes me even more suspicious of the strangely morphing
WM_NOTIFYFORMAT result. I tried finding which API call created the prefs
dialog in WinAmp in a logger trace on XP, but couldn't, which confused
the hell out of me, in Wine it appears as a CreateWindowExW (strangely,
the others are CreateWindowExA) - BUT it doesn't appear in a relay trace
and it doesn't seem to be loaded via GetProcAddress :(

So I think IsWindowUnicode is giving a "wrong" result on Wine. But I
don't know where to look next.

-- 
Mike Hearn <m.hearn at signal.qinetiq.com>
QinetiQ - Malvern Technology Center