http://bugs.winehq.org/show_bug.cgi?id=19396
Summary: Blitzin2: Auto-vscroll not working Product: Wine Version: 1.1.26 Platform: PC-x86-64 URL: http://www.chessclub.com/bits/interface/blitzin234.exe OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: richedit AssignedTo: wine-bugs@winehq.org ReportedBy: Andrew.Talbot@talbotville.com
In Blitzin2 (version 2.34, see URL), the main console window should auto-vscroll. Patch http://source.winehq.org/git/wine.git/?a=commit;h=140fee179040c68717f46bfd07... introduces a regression from this behavior.
http://bugs.winehq.org/show_bug.cgi?id=19396
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, regression CC| |dylan.ah.smith@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=19396
--- Comment #1 from Dylan Smith dylan.ah.smith@gmail.com 2009-07-20 23:20:09 --- Created an attachment (id=22492) --> (http://bugs.winehq.org/attachment.cgi?id=22492) Let WM_VSCROLL message be sent to scroll richedit control
The WM_VSCROLL message is documented as a notification sent when a scrolling event occurs, however, the application was using this to scroll the text in the richedit control. Apparently this works.
Previously this bug was not visible since ES_AUTOVSCROLL was always simulated without checking for the style flag. The application removes this style by using EM_SETOPTIONS, so the automatic scrolling wasn't being performed anymore after my recent patch.
The attached patch will fix the issue, but it isn't done right, so I am not submitting it.
First of all WM_HSCROLL and EM_SCROLL probably have the same behaviour, but this still needs to be tested to confirm.
Second of all WM_VSCROLL specifies the scroll position as a 16-bit value, so overflow needs to be avoided for large amounts of text. I did some testing, and it seems as if nMax for the scrollbar is capped at 0xFFFF for native richedit controls after a large amount of text has been loaded. Normally nMax corresponds to the height of the text in pixels, so I guess this is scaled after the text gets to large.
http://bugs.winehq.org/show_bug.cgi?id=19396
Dylan Smith dylan.ah.smith@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1
--- Comment #2 from Dylan Smith dylan.ah.smith@gmail.com 2009-07-21 18:54:13 --- I sent a patch to fix this bug to wine-patches (see description in the email): http://www.winehq.org/pipermail/wine-patches/2009-July/076233.html
http://bugs.winehq.org/show_bug.cgi?id=19396
--- Comment #3 from Dylan Smith dylan.ah.smith@gmail.com 2009-07-22 10:54:42 --- My patch that fixes the issue was accepted as commit 0deb3d04ede7ff1316b86c319ac0b8a6112e0a02
Please retest to see if this bug is fixed.
http://bugs.winehq.org/show_bug.cgi?id=19396
Andrew Talbot Andrew.Talbot@talbotville.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED
--- Comment #4 from Andrew Talbot Andrew.Talbot@talbotville.com 2009-07-22 13:38:22 --- Yes, your patch has fixed the bug. Thanks, Dylan.
http://bugs.winehq.org/show_bug.cgi?id=19396
Andrew Talbot Andrew.Talbot@talbotville.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |
--- Comment #5 from Andrew Talbot Andrew.Talbot@talbotville.com 2009-07-28 15:15:18 --- There is one subtle element I missed. Prior to the patch that caused the regression, if the vertical scroll thumb was placed away from the bottom of its range, each arrival of new text would cause it to be forced down to the bottom, thus the text that had just been rendered would be visible in the viewport. Whereas now, the thumb is not forced down whenever new text arrives, so the new text is rendered below and thus outside of the viewport.
http://bugs.winehq.org/show_bug.cgi?id=19396
--- Comment #6 from Dylan Smith dylan.ah.smith@gmail.com 2009-07-30 08:23:45 --- (In reply to comment #5)
There is one subtle element I missed. Prior to the patch that caused the regression, if the vertical scroll thumb was placed away from the bottom of its range, each arrival of new text would cause it to be forced down to the bottom, thus the text that had just been rendered would be visible in the viewport. Whereas now, the thumb is not forced down whenever new text arrives, so the new text is rendered below and thus outside of the viewport.
Just because it behaves differently doesn't mean it is a bug. I tested on Windows XP with the application, scrolled up using the scroll thumb, then pressed enter to append a new line to the text, and it didn't scroll down (neither did waiting for a message to appear). This is what wine now does, so it isn't a regression, it is a bug fix.
Let me know if I am not understanding the steps to reproduce this regression that you reopened this bug for. Otherwise please test against Windows or native richedit before reporting a non-obvious bug.
http://bugs.winehq.org/show_bug.cgi?id=19396
Andrew Talbot Andrew.Talbot@talbotville.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED
--- Comment #7 from Andrew Talbot Andrew.Talbot@talbotville.com 2009-07-30 13:38:04 --- Perhaps I went about it in the wrong way, but I just wanted to make sure that someone didn't close the bug report before I had had the chance to compare the different-from-previous behavior with what happens under Windows.
I confirm your findings and assertions to be correct. Thank you once again.
http://bugs.winehq.org/show_bug.cgi?id=19396
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Alexandre Julliard julliard@winehq.org 2009-08-07 12:58:22 --- Closing bugs fixed in 1.1.27.
https://bugs.winehq.org/show_bug.cgi?id=19396
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|http://www.chessclub.com/bi |https://web.archive.org/web |ts/interface/blitzin234.exe |/20051210060012/http://www. | |chessclub.com/bits/interfac | |e/blitzin234.exe CC| |focht@gmx.net Fixed by SHA1| |0deb3d04ede7ff1316b86c319ac | |0b8a6112e0a02
--- Comment #9 from Anastasius Focht focht@gmx.net --- Hello folks,
adding stable download link via Internet Archive for documentation.
https://web.archive.org/web/20051210060012/http://www.chessclub.com/bits/int...
https://www.virustotal.com/gui/file/fd8b7e02138b8634f7e43be20eb390c3f0ac8824...
$ sha1sum blitzin234.exe 99d324f38272a1c59ceec0d4e858256925f03835 blitzin234.exe
$ du -sh blitzin234.exe 1.9M blitzin234.exe
Regards