| | [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #1724
| 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: | Bug: Fl_Browser: content/scrollbar wrong after hide() changes |
|---|
| Version: | 1.1.7 |
|---|
| Created By: | xurux |
|---|
| Assigned To: | mike |
|---|
| Fix Version: | 1.1-current (SVN: v5987) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | xurux
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.
notes:
* i am also calling middleline(~4500) after the hide()/show() changes.
* calling both:
topline(1);
middleline(4500);
... 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) | |
| |
| #2 | xurux
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:
browser->topline(1);
browser->middleline(700);
(the bug exists also without them) | |
| |
| #3 | xurux
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) | |
| |
| #4 | matt
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. | |
| |
| #5 | xurux
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
(unintentionally) modified. | |
| |
| #6 | ianmacarthur
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.
--
Ian | |
| |
| #7 | mike
08:46 Nov 20, 2007 |
| We'll just flag redraw() on hide/show. | |
| |
| #8 | mike
13:57 Nov 20, 2007 |
| Fixed in Subversion repository. | |
[ Return to Bugs & Features ]
|
| |
