|
#1 | kdiman 10:34 Jul 18, 2011 |
| When I'm setting cursor to end position in test/editor (after loading of some file not big size) (and when line has minimum one symbol in that position) and/or:
1) doing to wheel mouse to up a bit and back to down - the vertical scrollbar (rather will be to say: handler of scrollbar) don't arrive into his ending state;
2) doing move to previous position (to back per one symbol) (via FL_Left and back to FL_Right) don't move to previous line - the handler of scrollbar slid in this moment, but it must not be; | |
|
#2 | ianmacarthur 01:52 Jul 20, 2011 |
| can you bring this discussion onto fltk.geneal for now? To try and clarify the issue you are seeing.
I can't see the fualt trying to reproduce the description given here... | |
|
#3 | kdiman 21:31 Sep 27, 2011 |
| for addition information: this behaviour can be seen with flag is WORDWRAP... | |
|
#4 | ianmacarthur 13:40 Sep 28, 2011 |
| Sorry - but I still can't figure out how to reproduce this bug, based on your description.
Can you post a step-by-step description (maybe even in fltk.general) that is simple enough for me to follow and see if we can reproduce this for investigations... | |
|
#5 | corvid 13:48 Sep 28, 2011 |
| We've seen this reasonably frequently in Dillo since setting WRAP_AT_BOUNDS. I suspect it helps to have words (e.g., URLs) wider than the Fl_Text_Editor. Dragging the slider thing (whatever it's called) of the scrollbar reaches the bottom of the text, but the slider doesn't touch the bottom. Using the arrow keys to move around in the text, the text will sometimes change how it wraps for no obvious reason. If I go to the bottom and keep pressing down, I've seen it bounce between two different states of how it thinks it should wrap, and the slider will bounce a little.
I'll try to come up with a reproducible case for you guys... | |
|
#6 | matt 13:53 Sep 28, 2011 |
| Ah, wordwrap mode, um, yeah, how shall I say? I will need a week of paid vacation before and after I touch that code ;-)
Seriously though, word-wrap is somewhat broken. Not entirely, but a little bit. I will need some time to fix this. | |
|
#7 | corvid 14:07 Sep 28, 2011 |
| Here's one that suffices to make the scrollbar not drag all the way down. It doesn't show any words-jumping oddness because they're all short. | |
|
#8 | matt 14:08 Sep 28, 2011 |
| PS: the sliding part in a scrollbar is called a thumb by Microsoft. Java calls it the scroll box in the scroll channel. In Flash it's called the slider of the scroll bar. Apple calls them Scroll bars. Go figure. | |
|
#9 | AlbrechtS 01:27 Sep 29, 2011 |
| In Corvid's example the last (only?) line of text doesn't have a terminating \n. This is probably what's causing the slider's misbehavior, because the line count is not consistent with the display. I remember that there was a comment (maybe in FLTK 2) that this was an unresolved problem. Maybe it's something similar here...
HTH. | |
|
#10 | AlbrechtS 03:13 Oct 20, 2012 |
| Changed priority to 3: Moderate. | |
|
#11 | ianmacarthur 15:55 Mar 11, 2014 |
| Status on this? DO we know if this is still "the same"..?
Or should we close, or...? | |
|
#12 | kdiman 05:22 Mar 13, 2014 |
| That is still "the same", I have checked it right before. | |
|
#13 | AlbrechtS 04:21 Dec 03, 2014 |
| Now that we have "word wrap" mode in our test/editor demo program, we can use this directly for testing. I tested a little bit, and I've got some news...
AFAICT the issue depends on the last line in the editor and exists only if this line does not have a terminating "new line" character (LF). There's no need to have long lines that do actually wrap, but wrap mode must be activated to see the effect.
Test procedure:
(1) Open the attached file wrap_test.txt or add some lines (about 10-20) to an empty editor window, but don't press Enter after the last line.
(2) Shrink the window height, if necessary, until both scrollbars appear (not yet in wrap mode). Scrolling with the vertical scrollbar works as expected.
(3) Use the menu (Edit/Preferences/Word Wrap) to activate word wrapping - the horizontal scrollbar disappears. The vertical scrollbar can't be moved down with the mouse, there is always a small gap. This is the effect the STR is about.
Note 1: You can click at the end of the buffer or you can move the cursor to the end of the buffer, and the scrollbar will be moved all the way down as expected.
Note: if you press Enter at the end of the buffer (add the termination LF character) everything seems okay. | |
|
#14 | AlbrechtS 04:32 Dec 03, 2014 |
| Starting with the test scenario in comment #13 I found a way to improve the scrollbar movement - see attached file test_01.diff.
With this patch the scrolling is improved, but now you can scroll the display so that the cursor is hidden below the last line IF the buffer contains a terminating LF. So this patch is not really a full fix, but a start...
---
Note to devs and others: I didn't assign this STR to me, and I don't intend to work on this in the near future, so if anybody feels inclined to work on it, please feel free to do it. Patches and other improvements welcome! | |
|
#15 | greg.ercolano 03:01 Oct 08, 2017 |
| See possibly related bug STR #3412 http://www.fltk.org/str.php?L3412 | |
|
#16 | greg.ercolano 16:47 Oct 25, 2017 |
| All folks interested in this problem; please try svn r12526 or later and report if it fixes your issue. | |
|
#17 | kdiman 11:30 Oct 26, 2017 |
| Greg, I've tested current svn (12529) for 1.3 branch - all works ok ! | |
|
#18 | greg.ercolano 12:24 Oct 26, 2017 |
| Thanks Kdiman!
Sounds like your problem is solved, but the one Albrecht describes in comment #13 is not yet resolved.. keeping this open for that issue. | |
|
#19 | chris 00:37 Oct 28, 2017 |
| Attaching a patch 'test_02.diff' for issue in #13. | |
|
#20 | greg.ercolano 15:17 Oct 28, 2017 |
| Fixed in Subversion repository.
@chris -- wow, awesome -- works beautifully.
Committed as r12532.
I know what you had with !mContinuousWrap is legal and concise C/C++, but because it's used in a math formula, I opted to convert it to an int explicitly with a tertiary conditional: (mContinuousWrap?0:1) ..just to keep the logic positive, and be clear on the possible values, as I'm not sure everyone would get that !1 == 0 and !0 == 1.
However, if you were a dev and had committed that, I wouldn't have questioned it.
Speaking of which, you found that pretty quick.. wanna be a dev? ;) We may need to see a few more patches, but your suggs so far have all seemed pretty reasonable and clean over the years. | |
|
#21 | AlbrechtS 10:40 Apr 19, 2018 |
| This STR seems to be resolved. Can we close it? | |
|
#22 | kdiman 15:10 Apr 19, 2018 |
| Thanks a lot ! Yes, of course to close, if that fixed. | |
|
#23 | AlbrechtS 02:31 Apr 20, 2018 |
| Fixed in Subversion repository.
Thanks, closed. | |
|
#24 | AlbrechtS 04:20 Mar 07, 2020 |
| FTR: Git commit = a035d10d37d195ba0164ee551c7aa618c6772a2b | |