[Bug 17627] New: winhlp32: clickable area out of sync with hyperlink text
http://bugs.winehq.org/show_bug.cgi?id=17627 Summary: winhlp32: clickable area out of sync with hyperlink text Product: Wine Version: 1.1.13 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: richedit AssignedTo: wine-bugs(a)winehq.org ReportedBy: hoehle(a)users.sourceforge.net [The following cannot be observed since wine-1.1.14 because of bug #17601. I believe this makes #17601 a blocker for the present issue.] Between wine-1.1.0 and 1.1.13, after scrolling with keyboard, the mouse sensitive clickable areas stay at their old position, while all text has scrolled! Also, the bottommost line of text may not be refreshed when scrolling upwards. Similar results with PgUp and PgDn, where sometimes half the screen is not refreshed. OTOH, scrolling via the mouse with the wheel, the scrollbar or the 2 scrollbar arrow buttons works. It looks like the situation degraded over time -- perhaps several bugs are involved -- however one issue is older than 1.0.1: In 1.1.0, as well as 1.0.1, the synchronisation between link text and sensitive area is mostly fine -- except when using the cursor keys on a page where all text fits on the page. There, using the up arrow key causes scrolling up, while the clickable areas don't move. If you click inside the window, a cursor appears and the up/down keys cease scrolling and move this cursor instead. To reproduce, go to a page with links that fits the window (I used winace.hlp). The cursor shall not be visible. Hit the down cursor key. The text scrolls up, while the mouse sensitive areas remain in place (and are functional). Click into the window and the cursor appears. If you move up now, some text scrolls down, but the refresh is very incomplete. To observe the effect in 1.0.1, you need to scroll up with the down key until after the scrollbar reaches the bottommost position: i.e. you're scrolling farther than would be possible with only the mouse. Obviously, the fact that 1.0.1 displays scrollbars immediately while 1.1.0 lacks them (cf. bug #14293) does not matter. So this is not the same as bug #14293 which only appeared in 1.1.0. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=17627 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |17601 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=17627 --- Comment #1 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2009-03-06 03:18:09 --- What I mean with the degradation of the situation is that it may not make sense to perform regression testing between 1.1.0 and 1.1.13 to discover when any keyboard scrolling caused loss of synchronisation, given that some loss of synchronisation can be observed in even older releases. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=17627 Dylan Smith <dylan.ah.smith(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dylan.ah.smith(a)gmail.com Status|UNCONFIRMED |NEW Component|richedit |programs Ever Confirmed|0 |1 --- Comment #2 from Dylan Smith <dylan.ah.smith(a)gmail.com> 2009-03-07 00:45:22 --- It seems like the problem involves pressing up/down keys without first giving focus to the richedit control. It seems as if the builtin winhlp32 is scrolling the contents of the window, without actually sending messages to the richedit controls to have it do this scrolling. Using native richedit dlls (msftedit, riched20, riched32) seems to have no effect on the bug, so it doesn't no seem to be a richedit bug. Using native winhlp32.exe doesn't have the same bug. Either way, it is still a valid bug. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=17627 Dylan Smith <dylan.ah.smith(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #3 from Dylan Smith <dylan.ah.smith(a)gmail.com> 2009-03-07 01:11:25 --- I found what I expected in winhlp32, calls to ScrollWindow where EM_SCROLL messages should be sent to the richedit control. I created a patch and sent it to wine-patches: winhlp32: Use EM_SCROLL to scroll richedit control. http://www.winehq.org/pipermail/wine-patches/2009-March/070389.html -- 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.
http://bugs.winehq.org/show_bug.cgi?id=17627 Bug 17627 depends on bug 17601, which changed state. Bug 17601 Summary: winhlp32: links ceased working http://bugs.winehq.org/show_bug.cgi?id=17601 What |Old Value |New Value ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED -- 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.
http://bugs.winehq.org/show_bug.cgi?id=17627 --- Comment #4 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2009-03-07 12:07:11 --- I applied your patch to 1.1.16 and it fixed the issue. Thank you again for the ultra fast response. All links are clickable where the text is and the window is now always refreshed properly when scrolling (not considering bug #14293). Can be marked fixed as soon as it appears in git. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=17627 Dylan Smith <dylan.ah.smith(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #5 from Dylan Smith <dylan.ah.smith(a)gmail.com> 2009-03-09 10:47:58 --- (In reply to comment #3)
winhlp32: Use EM_SCROLL to scroll richedit control. http://www.winehq.org/pipermail/wine-patches/2009-March/070389.html
In git as commit fb63cd0c87e6db85bc4ebc31931f0eba8975a0c8. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=17627 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #6 from Alexandre Julliard <julliard(a)winehq.org> 2009-03-13 11:15:49 --- Closing bugs fixed in 1.1.17. -- 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.
participants (1)
-
wine-bugs＠winehq.org