[ Return to Bugs & Features | Post Text | Post File | Prev | Next ]

STR #3412

Trouble Report Files:

	Name/Time/Date	Filename/Size
	#1  greg.ercolano 14:51 Oct 07, 2017	display-bug.cxx 1k
	#2  greg.ercolano 15:05 Oct 07, 2017	quickfix.patch 1k

Trouble Report Comments:

	Name/Time/Date	Text
	#1  greg.ercolano 14:51 Oct 07, 2017	Attached program demonstrates the vertical scrollbar isn't calculated properly when the Fl_Text_Display has wrap_mode() set to WRAP_AT_BOUNDS with a style table whose font text size != textsize(). To replicate:     1) Run the app, and do not change the size of the window     2) Scroll to the bottom of the buffer What you SHOULD see is line 0199, which is the real "last line". What you ACTUALLY see is a partial line (in my case, line 0109) as being the bottom line. There's obviously more in the buffer, but you can't reach it with the scrollbar. Resizing the window vertically does not help. But resizing horizontally by just a few pixels fixes the problem, causing the scrollbar to re-calculate properly, so that one can scroll to the real bottom of the buffer. Seems to be a bug in Fl_Text_Display's calculations of the vertical scrollbar values that isn't getting triggered until an actual resize() of the horizontal size is changed.
	#2  greg.ercolano 15:05 Oct 07, 2017	Attaching a small patch (quickfix.patch) that solves the immediate problem I'm having. I did not dig in deep, but given the horiz vs. vert resize behavior described in comment #1, this seemed the obvious place to suspect, Not sure if it's the right solution. If it is, then likely 'oldTAWidth' and related code should be removed. Albrecht, I think this involves your mods introduced in r11208. Perhaps you can weigh in.
	#3  AlbrechtS 02:30 Oct 12, 2017	@Greg: I saw your comment and I'll take a look at it later. As far as I can remember I was not really happy with 'oldTAWidth' and its calculation or whatever, but I didn't want to change more than necessary. As you know, Fl_Text_Display is a beast ;-)
	#4  AlbrechtS 03:40 Oct 21, 2017	@Greg: I found that your "quickfix.patch" was (obviously unintentionally) committed in r12511 that fixes STR #2788. I reverted that part of r12511 in svn r12518. I'm trying to figure out what oldTAWidth is (or was) good for and I'm working on a patch. I'm not sure if we should remove it entirely or maybe only initialize it with another value (maybe 0).
	#5  greg.ercolano 03:43 Oct 21, 2017	Ew, good catch, thanks.. I assume you caught it pulling 1.4 current and then noticing it had already been applied..!
	#6  AlbrechtS 04:07 Oct 21, 2017	Actually I found it because I got a compiler warning (unused variable).
	#7  AlbrechtS 04:05 Oct 25, 2017	Fixed in Subversion repository. The fix in svn r12526 disables a part of the optimization introduced in svn r11208 (STR #3272). The problem with the optimization was the (false) assumption that the resize() method is called only when a real resize of the widget happened. However resize() is also called when the data buffer was changed. Hence, the initial display width can be unchanged. The test program display-bug.cxx works for me correctly with this commit. Please try svn r12526 or later and report if it fixes your issues.
	#8  greg.ercolano 09:54 Oct 25, 2017	Looks good to me; checked with the app I was having trouble with and I can now scroll to the bottom without trouble.
	#9  greg.ercolano 10:06 Oct 25, 2017	I believe STR #3361 is related. I'll make a note there to see if r12526 solves their issue.
	#10  greg.ercolano 16:49 Oct 25, 2017	STR #2682 also related.
	#11  greg.ercolano 09:16 Oct 26, 2017	By the way, I just made a change to Fl_Text_Display::resize() to split out the recalc code from the resize() method so that it can be called directly (r12529), needed to fix STR #3395. This allows recalc'ing the display without having to round trip through the FLTK resize() hierarchy when dimensions haven't changed.
	#12  AlbrechtS 07:23 Nov 06, 2017	Re #9 - #11: I'll take a look at the mentioned STR's when time permits. WRT splitting recalc code from the resize(): I'll take a look at this as well. It's a good move, but using the new feature [1] may change the behavior of Fl_Text_Display, so this needs thorough investigation. Maybe worth another STR? [1] What I mean is: calling one OR the other OR both whatever is necessary where currently resize() is called. I know that resize() is called in the modify-callback (i.e. when the text buffer is/was modified), but there are supposedly other places...
	#13  AlbrechtS 09:30 Dec 02, 2021	See also related issue #300: "test/tree: hitting 'select all' hangs the application" https://github.com/fltk/fltk/issues/300
	#14  AlbrechtS 14:15 Jan 16, 2023	Unassigning myself.

[ Return to Bugs & Features | Post Text | Post File ]