| | [ Return to Bugs & Features | Post Text | Post File | SVN ⇄ GIT | Prev | Next ]
STR #3412
| Application: | FLTK Library |
|---|
| Status: | 5 - New |
|---|
| Priority: | 3 - Moderate, e.g. unable to compile the software |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | Fl_Text_Display scroll bug (style table with font != textsize() + wrap) |
|---|
| Version: | 1.4-current |
|---|
| Created By: | greg.ercolano |
|---|
| Assigned To: | Unassigned |
|---|
| Fix Version: | 1.4.0 (SVN: v12526) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]
Trouble Report Comments:
[ Post 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 ]
|
| |
