> 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?
Turns out you were right, the bug seems to be in IsWindowUnicode. It
only ever looks at the winproc, but dialogs (for some reason) seem to
use their own, in the extra window bytes. Adding in a check for that,
fixed WinAmp. I think this is definately a more correct fix than my last
one.
ChangeLog:
- Make IsWindowUnicode correct for dialogs
thanks to dante and dimi for this patch,
-mike
Index: windows/win.c
===================================================================
RCS file: /home/wine/wine/windows/win.c,v
retrieving revision 1.216
diff -u -r1.216 win.c
--- windows/win.c 14 Mar 2003 04:11:17 -0000 1.216
+++ windows/win.c 19 Mar 2003 11:28:17 -0000
@@ -1742,9 +1752,17 @@
{
WND * wndPtr;
BOOL retvalue;
-
+ LONG *dlgWndProc;
+
if (!(wndPtr = WIN_FindWndPtr(hwnd))) return FALSE;
- retvalue = (WINPROC_GetProcType( wndPtr->winproc ) == WIN_PROC_32W);
+ /* dialog boxes store their window proc in a different location, so check where we should look here */
+ dlgWndProc = (LONG *)(((char *)wndPtr->wExtra) + DWL_DLGPROC);
+
+ if (wndPtr->flags & WIN_ISDIALOG)
+ retvalue = (WINPROC_GetProcType( (WNDPROC)*dlgWndProc ) == WIN_PROC_32W);
+ else
+ retvalue = (WINPROC_GetProcType( wndPtr->winproc ) == WIN_PROC_32W);
+ TRACE("hwnd=%p, proc=%p, retvalue=%d\n", hwnd, wndPtr->winproc, retvalue);
WIN_ReleaseWndPtr(wndPtr);
return retvalue;
}
