STR #2682

GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 1.3 ]

STR #2682

Application:FLTK Library
Status:1 - Closed w/Resolution
Priority:3 - Moderate, e.g. unable to compile the software
Scope:3 - Applies to all machines and operating systems
Subsystem:Core Library
Summary:Vertical scrollbar of Fl_Text_Editor have a strange behavior. Or is bug?
Version:1.3-current
Created By:kdiman
Assigned To:AlbrechtS
Fix Version:1.4.0 (SVN: v12532)
Fix Commit:a035d10d37d195ba0164ee551c7aa618c6772a2b
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size top right image
 
#1 corvid
14:05 Sep 28, 2011
scrollbar_editor.diff
1k
 
 
#2 AlbrechtS
04:21 Dec 03, 2014
wrap_test.txt
0k
 
 
#3 AlbrechtS
04:32 Dec 03, 2014
test_01.diff
1k
 
 
#4 chris
00:37 Oct 28, 2017
test_02.diff
1k
 
bottom left image   bottom right image

Trouble Report Comments:


Name/Time/Date Text top right image
 
#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  
bottom left image   bottom right image

Return to Bugs & Features ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2021 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.