| [ Return to Bugs & Features | Post Text | Post File | Prev | Next ]
STR #1742
Application: | FLTK Library |
Status: | 5 - New |
Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Core Library |
Summary: | Fl_Browser: Inconsistent behavior of value() |
Version: | 1.4-feature |
Created By: | vedran |
Assigned To: | matt |
Fix Version: | Unassigned (SVN: v5952) |
Update Notification: | |
Trouble Report Files:
[ Post File ]No files
Trouble Report Comments:
[ Post Text ]
|
#1 | vedran 04:53 Jul 18, 2007 |
| The method int value() returns the row that has keyboard focus. This is inconsistent with void value(int) which selects the row (nothing to do with keyboard focus).
Looking at int value() implementation one can see this: int Fl_Icon_Browser::value() const { return lineno(selection()); } It seems ok, but actually the Fl_Browser_::selection() method in context of Fl_Browser returns the line with focus, not the selected line.
One suggestion is to fix Fl_Browser_::selection() to work as advertised, but then there would be no way to detect which line has focus, not to mention the many people that subclassed Fl_Browser_ in their projects that would now have problems.
IMHO it is much better to just fix int Fl_Browser::value() to something like this: int Fl_Icon_Browser::value() const { for (int i=1; i<=size(); i++) if (selected(i)==1) return i; return -1; } And also update documentation for Fl_Browser_::selection().
This is related to my STR #1740 which propose adding separate methods for focus handling. | |
|
#2 | matt 11:43 Oct 07, 2007 |
| I updated the documentation accordingly. I am more than hesitant to change the actual behavior at this point, but I understand that the return values are useless and unexpected. Unfortunatly, the strive for binary compatibility does not allow for a new pointer in Fl_Browser_ which would hold the *focused* item as opposed to the *selected* item.
Then again, returning a single value from a browser that allows an arbitrary number of selections would be wrong anyways. Even return the first selected value would be wrong - that would be like claiming that a broken watch is right twice a day is a feature.
Anyway, I upped this to 1.2 in the hope of finding a good API there. | |
|
#3 | matt 15:09 Dec 28, 2008 |
| upped to 1.3 | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |