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