TreeView notifications fix

[Mike Hearn]

On Mon, 2003-03-17 at 15:22, Dimitrie O. Paun wrote:
> On 17 Mar 2003, Mike Hearn wrote:
> 
> > And yes, I found that this morning as well :) At least in WinAmp,
> > changing it to ansi seems to fix it....
> 
> You mean just making the if() be trivially true?

As in always using the A version (not called get_notifycode)

> > Well, I changed treeview.c to use get_notifycode (ie it's doing the
> > right thing). That breaks WinAmp, probably trillian and putty too.
> 
> 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,

> > So it looks like the treeview component isn't buggy on Windows, it does
> > send Unicode when it's asked to.
> 
> 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.

> > 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.
> 
> Why "you think"? It seems you actually see it give the wrong result, no? 

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,
IsWindowUnicode() could well be correct and the bug lies elsewhere. But
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 is the point where I go "huh?!?" and get stuck.

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