Community
Participate
Working Groups
Build Identifier: Helios Service Release 1 This is preety simple Bug, but for people, who are using primarly mouse, can be a problem. Every time, when a line gets shorter by moving part of the text to next line horizontal scrollbar vanishes. The problem is, when scrollbar is scrolled even a little bit right. Then your view presents only part of the text. If doesn't scrollback or leave scrollbar to correct horizontal scrolling of the text. Reproducible: Always Steps to Reproduce: 1. Write line of text, which is longer than a view. So long that horizontal scrollbar shows. 2. Scroll right. 3. Pick up randomly position in this long line and move part of the line to next one. 4. Horizontal scrollbar disappears. 5. Only by pressing HOME or left cursor full text can once again be seen.
At text least the editor only removes the thumb of the scroll bar when all lines fit. Can you please provide a concrete example (including the view or editor that you are using).
Created attachment 193463 [details] Example file
(In reply to comment #1) > At text least the editor only removes the thumb of the scroll bar when all > lines fit. Can you please provide a concrete example (including the view or > editor that you are using). Sure. I added a file for you. Open it with 'Open file...'. Than adjust editor to see only maximal right position of the text (so horizontal scrollbar is maximal right). As well adjust width of the view to see only "|start" (this is part of the string). Than place cursor after "|", which is somewhere between "|start" and end of the string. And voila, scrollbar should be gone and text is not seen from first column. Try it. If it's not enought I'll try to come up with something better.
(In reply to comment #3) > (In reply to comment #1) > > At text least the editor only removes the thumb of the scroll bar when all > > lines fit. Can you please provide a concrete example (including the view or > > editor that you are using). > > Sure. I added a file for you. Open it with 'Open file...'. Than adjust editor > to see only maximal right position of the text (so horizontal scrollbar is > maximal right). As well adjust width of the view to see only "|start" (this is > part of the string). Than place cursor after "|", which is somewhere between > "|start" and end of the string. And voila, scrollbar should be gone and text is > not seen from first column. > > Try it. If it's not enought I'll try to come up with something better. Naturally after placing cursor you should press enter key.
Created attachment 193465 [details] Picture of Java editor with scrollbar That's what I see. Maybe you can add some screenshots too.
Created attachment 193466 [details] Step 1
Created attachment 193467 [details] Step 2
Created attachment 193468 [details] Step 3
Step 1: Open file and scroll right. Adjust your view to see exactly what is shown on picture step1. Step 2: Place cursor, where arrow on step2 picture is. Step 3: Press enter. That should work.
StyledText removes the scroll bar even though not all text is visible. 1. start fresh workspace 2. paste into Package Explorer: public class C { void fooLoooooooooooooooooooooooooooooooooooooooooooooooooong() { } } 3. press 'End' on second line 4. set caret after "foo" 5. press 'Enter'
I can't reproduce the problem with the steps in comment 10, but I could following the steps in comments 6,7,8. The problem happens to the JavaEditor but does not happen with org.eclipse.swt.examples.texteditor.TextEditor ? It seems that the JavaEditor is doing something when breaking a string in multiple lines (and auto-indent it) that StyledText does not expect.
(In reply to comment #11) > I can't reproduce the problem with the steps in comment 10, but I could > following the steps in comments 6,7,8. Could be if the editor width out of the box is different on your machine or you didn't start a fresh workspace. > The problem happens to the JavaEditor but does not happen with > org.eclipse.swt.examples.texteditor.TextEditor ? > It seems that the JavaEditor is doing something when breaking a string in > multiple lines (and auto-indent it) that StyledText does not expect. Textual editors indent (align to previous line) the wrapped string. Given the text is not scrolled entirely to the left StyledText should not remove the scroll bar. You can easily reproduce it in the SWT Text Editor example by adding the following code to it: styledText.addVerifyListener(new VerifyListener() { public void verifyText(VerifyEvent e) { e.text= e.text.replaceAll("\n", "\n\t\t"); } });
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
Still the same and imo something that should be fixed.
New Gerrit change created: https://git.eclipse.org/r/153248
Gerrit change https://git.eclipse.org/r/153248 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=218f92e3b9fda0f48cc2d06401f180d5098121e3
Finally merged. The related 'wrong width' bug became quite nasty. Note for verification: comment 10 is still usable to trigger the bug (of cause before it was just fixed). The editor must be small enough to show a scrollbar and you should not scroll over the void (the position where caret will land after enter). Also the long line should be splitted (only press enter; no selection) around the center. It works not reliable for me when splitting after foo. In this case the StyledText had removed the scrollbar but did not scrolled the text to the beginning.
Reopened because required fix was reverted.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
