[ Return to Bugs & Features | Roadmap 1.1 ]
|Status:||1 - Closed w/Resolution|
|Priority:||3 - Moderate, e.g. unable to compile the software|
|Scope:||3 - Applies to all machines and operating systems|
|Summary:||Bug: Fl_Browser: content/scrollbar wrong after hide() changes|
|Fix Version:||1.1-current (SVN: v5987)|
Trouble Report Files:
Trouble Report Comments:
15:15 Jul 02, 2007
|I have inserted 5000 lines, then when i hide() (OR show() again) the first 2/3 of these lines, while being scrolled down, _nothing_ is displayed at first. When i grab the scrollbar with the mouse to scroll up, then the last lines are displayed, and when scrolling up more everything pops back to normal. |
* i am also calling middleline(~4500) after the hide()/show() changes.
* calling both:
... does not help.
* middleline(...) etc. work _OK_ (when using hidden lines) after i have scrolled up to the begin of the list _once_ (until the next massive hide()-changes)
12:17 Jul 03, 2007
|Hi, i have added an example: |
* scroll to the end and then mark "[x] all" (which will display lines 1-1000 instead of only 667-1000)
(you can also play with "filter")
* in the source both these lines exist:
(the bug exists also without them)
12:38 Jul 16, 2007
|Another, related bug, is that, although the documentation says differently, hidden lines can be selected/unselected: this happens |
when you select a whole range of lines (with mouse) - then the hidden lines in this range are also selected !!
Correct Behaviour would be: selection status of hidden lines is not changed, unless a new selection is begun (selection of hidden lines is cleared then).
(maybe the 2 bugs can be fixed together)
09:46 Oct 06, 2007
|Top 1: at 5000 lines of text, each one being 10 or so pixels high, your pixel positions go beyond the limit of 32768 for coordinates. |
Top 2: when you find a second, different bug, please file a new bug report next time.
Thanks, I will try to fix both issues when I find the time.
11:58 Oct 06, 2007
|Bug 1 is not so severe, it is only an *optical* issue (actually i have found |
a workaround: after show()/hide() changes, i insert/delete a few lines, which
i have to do anyway, and then calling topline()/middleline() works correctly)
Note also, if you try to fix Bug 1, please try to not make show()/hide() slower
(i have now up to 50000 entries in the list, and i even made already a modification to
fltk-lib source code to *improve* the speed of hide()/show(); i'm adding that
patch for reference)
Bug 2 is not so good: you think invisible lines could not be marked, and then
when starting an action on the marked lines, these invisible entries are also
10:11 Oct 07, 2007
|Blimey - up to 50000 entries in the list! I am amazed. Mind you - I do wonder if the basic Fl_Browser widget is the correct thing to use? |
When I have been managing large lists, I always use a subclass and manage the lists myself - that way I can do a better job than the basic browser coded does. There are a great many optimisations you can make when managing very large lists yourself that Fl_Browser simply can not do.
I think you might get much better performance by making a subclass specifically tailored to manage your lists.
08:46 Nov 20, 2007
|We'll just flag redraw() on hide/show. ||
13:57 Nov 20, 2007
|Fixed in Subversion repository. ||
[ Return to Bugs & Features ]