http://bugs.winehq.org/show_bug.cgi?id=13864
Alex Villacís Lasso a_villacis@palosanto.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|wine-bugs@winehq.org |a_villacis@palosanto.com
--- Comment #10 from Alex Villacís Lasso a_villacis@palosanto.com 2008-06-17 18:49:13 --- As I suspected, this is not actually a regression, but a exposure of a previously hidden bug. The installer uses EM_POSFROMCHAR to check on the textbox. Richedit 1.0 seems to return 0 (for normal cases) as LRESULT for EM_POSFROMCHAR, but builtin returns a composition of the client coordinates for the character, as per 2.0, and this returned 0 before the problematic patch just by accident. This needs a throughout test for EM_POSFROMCHAR (missing in both 1.0 and 2.0 testsets). MSDN also mentions a return value of -1 for characters beyond the last character in the control. This should be tested too.
--- Comment #11 from Alex Villacís Lasso a_villacis@palosanto.com 2008-06-19 12:19:32 --- Created an attachment (id=14183) --> (http://bugs.winehq.org/attachment.cgi?id=14183) richedit: Add tests for EM_POSFROMCHAR, make them pass under Wine
(In reply to comment #10)
As I suspected, this is not actually a regression, but a exposure of a previously hidden bug. The installer uses EM_POSFROMCHAR to check on the textbox. Richedit 1.0 seems to return 0 (for normal cases) as LRESULT for EM_POSFROMCHAR, but builtin returns a composition of the client coordinates for the character, as per 2.0, and this returned 0 before the problematic patch just by accident. This needs a throughout test for EM_POSFROMCHAR (missing in both 1.0 and 2.0 testsets). MSDN also mentions a return value of -1 for characters beyond the last character in the control. This should be tested too.
Scratch that, the behavior difference, while in need of correction, is not the actual cause of the regression. Patch attached for EM_POSFROMCHAR, but it does not actually fix the bug.
I have noticed that with native riched20, the radio button to accept the EULA does not get enabled until the EULA is scrolled to the very bottom. Before the problematic patch, it would get enabled as soon as the EULA is scrolled a bit. This difference might point to the true root cause of the bug.