Dear Reece,
Thanks for your comments.
I have write a patch for the problem, please comment.> > + if( unicode && class->winproc == EDIT_winproc_handle )> > Is it just the EDIT window procedure that is affected? I suspect that> this will apply to all classes that have A and W variants.
I encounter this problem with EDIT window. When I look at wine code, i thought the same. But it turn out this is needed only for EDIT, doing the same for other built-in control causing wine to behave different from window. The fact that someone added the var EDIT_winproc_handle is for hacking EDIT class for GetWindowLong. see
---/dlls/user32/win.c line 1911 in WIN_GetWindowLong()---------------------------------- case GWLP_WNDPROC: /* This looks like a hack only for the edit control (see tests). This makes these controls * more tolerant to A/W mismatches. The lack of W->A->W conversion for such a mismatch suggests * that the hack is in GetWindowLongPtr[AW], not in winprocs. */ if (wndPtr->winproc == EDIT_winproc_handle && (!unicode != !(wndPtr->flags & WIN_ISUNICODE))) retvalue = (ULONG_PTR)wndPtr->winproc; else retvalue = (ULONG_PTR)WINPROC_GetProc( wndPtr->winproc, unicode ); break;--------------------------------------------------------------------------------------------------
I also suspect that this is wrong. AFAICS, the class name Windows uses> is "EDIT", not "EDITA"/"EDITW"; the problem lies in SetWindowProc, so> it is likely you need to track both the A and W procs, selecting the> appropriate one depending on the variant of SetWindowProc is called.> CreateWindow would also need to select the correct one and> RegisterWindowClass would need to set the A and W variants initially.> However, I am not sure on this, so you need tests.
SetWindowProc is for subclass a windows that is already created. It only affects one window. WIN_SetWindowProc will call to WIN_GetWindowLong to return old WndProc. so SetWindowProc will use the same hack for return Edit window WndProc (handle to a struct of ProcA & ProcW). Normally it only return procA or ProcW.
SetClassLongW(hEDIT,GCLP_WNDPROC,proc) for global subclass, and will affect all EDIT windows created after.
for SetClassLong(Ptr), there must be similar hack. That is what I have done, but maybe not totally right.
One thing I am thinking is for Built-in control classes with procA and procW, (Set|Get)ClassLong(hEDIT,GCLP_WNDPROC,proc) should return class->wndproc, so it can be restored later. So similar hack is needed for CLASS_GetClassLong(h,GCLP_WNDPROC..)
But doing this only for EDIT
/* if subclassing Edit class, WndProc must handle both Ansi and Unicode Message*/ class->winproc = WINPROC_AllocProc( (WNDPROC)newval, (WNDPROC)newval );
Also, this patch (when sent to the wine-patches list) will stand a> better chance of getting in if there are some tests to verify the> behaviour on Windows and deficiency in Wine.
I have included a test application with source in bugzilla #14350, the EDIT window on the About dialogbox is non-unicode on Window but Unicode on Wine. My patch fixed that.
You need to check what procs are returned when. Use your original> email as the basis for the test.
(Set|Get)ClassLongW(hEDIT,GCLP_WNDPROC,proc) only retrun procW of the class, so for built-in class with both procA&W, procA is lost in those 2 line of code.
oldProc = SetClassLongW(hEDIT,GCLP_WNDPROC,NewProc); //only return procW. SetClassLong(hEDIT,GCLP_WNDPROC,oldProc); //suppose to restore proc for Edit, but only restored procW, procA lost
because now Edit class only have ProcW, if you call CreateWindowExA('EDIT',..). the created window is Unicode because it will find out it only have procW.
Regards Hongbo
_________________________________________________________________ Are you paid what you're worth? Find out: SEEK Salary Centre http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau%2F...