[Bug 14350] SetClassLongW() to subclass window EDIT control Problem
wine-bugs at winehq.org
wine-bugs at winehq.org
Tue Jul 8 07:39:42 CDT 2008
http://bugs.winehq.org/show_bug.cgi?id=14350
--- Comment #2 from Hongbo Ni <hongbo at njstar.com> 2008-07-08 07:39:42 ---
UNICODE is not defined because it's a ANSI (non-unicode) MFC application.
So all Edit windows (include on About dialog) are created by CreateWindowExA.
The problem is after subclassing the Edit class with a Unicode ProcW, any
window created by CreateWindowExA will become a Unicode window on Wine, not on
windowz.
I checked wine souce, when built-in Edit control class is registered, it has
ProcA and ProcW, so if you create a Edit window with CreateWindowExA, it will
be ANSI, if you create a Edit window with CreateWindowExW, it will be Unicode.
This behaviour is same on wine and windows.
But in WINE, after we subclass Edit class with
SetClassLongW(hEditWnd1, GCL_WNDPROC,(DWORD)EditWndProcW);
The Edit Control only have one ProcW, ProcA is set to NULL.
------class.c line 908 --------------------------------
case GCLP_WNDPROC:
retval = (ULONG_PTR)WINPROC_GetProc( class->winproc, unicode );
class->winproc = WINPROC_AllocProc( unicode ? NULL : (WNDPROC)newval,
unicode ? (WNDPROC)newval : NULL );
break;
-------------------------------------------------------
Now regardless you call CreateWindowExA or CreateWindowExW, the created window
will be Unicode.
This wine behaviour is different from Windows, where even after Edit class is
subclass with SetClassLongW(hEditWnd1, GCL_WNDPROC,(DWORD)EditWndProcW);
CreateWindowExA still create ANSI window, CreateWindowExW creates Unciode
Windows. (EditWndProcW needs to handle both message from Ansi and Unicode edit
windows).
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.
More information about the wine-bugs
mailing list