| | [ Return to Bugs & Features | Roadmap 1.3 | Post Text | Post File | Prev | Next ]
STR #3292
| 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: trouble pre-selecting item #1 with type() HOLD or SELECT |
|---|
| Version: | 1.3.3 |
|---|
| Created By: | greg.ercolano |
|---|
| Assigned To: | Unassigned |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]
Trouble Report Comments:
[ Post Text ]
| |
| #1 | greg.ercolano
11:40 Mar 07, 2016 |
| It seems selecting specifically item #1 has a problem.
If one switches the type() to FL_HOLD_BROWSER or FL_SELECT_BROWSER
and then tries to use select(1), item #1 doesn't show as selected.
Attaching a modified version of browser.cxx that includes three
new buttons along the bottom; "Select 1", "Select 2", "Select 10".
Replication:
1. Change the type from MULTI -> HOLD (or SELECT)
2. Hit "Select 1"
3. Item does not show as being selected
However, if in step #2 you use "Select 2" or "Select 10" it works fine.
Also, if after step #2 you use the other buttons, then the "Select 1"
button works.
So there's some kind of initial program state where that first select
of item #1 doesn't work, but subsequent selections works OK.
This *doesn't* seem to be a simple refresh issue; after step #2,
if you e.g. resize the screen, the item still doesn't show as selected. | |
| |
| #2 | greg.ercolano
15:13 Jul 13, 2016 |
| Investigated further; apparently has nothing to do with item #1 specifically,
it can happen with any item. It just happens that in the example program
item#1 is set by one of the callbacks that triggers the following problem.
Seems if Fl_Browser_'s internal variable 'selection_' is set by the item
it's pointing to isn't selected, this is an unexpected state for the class
when in e.g. FL_HOLD_BROWSER mode.
Once selection_ is set, if the item is unset, it's not possible to set
that item's state to 1 with select() until it is first cleared and reset.
Apparently this situation can happen if the browser's state is changed
with type(). I'd run into it under other circumstances.
Seems some code is needed to make sure this 'impossible state' doesn't
happen, but not sure exactly what.
Certainly type() could be overloaded to clear selection_ to NULL,
but not sure if that fully solves the problem, as there may be other
ways to end up in this state.
The following minimal code seems to be at least one way to cause the problem:
[..]
Fl_Browser *browser = new Fl_Multi_Browser(0,0,560,350,0);
browser->add("111");
browser->add("222");
browser->add("333");
browser->select(2,0); // leave focus box on this item (causes selection_ to point to item#2)
browser->type(FL_HOLD_BROWSER);
browser->select(2,1); // THIS IS IGNORED
[..]
When the above runs, item #2 is not selected.
It can be forced by deselecting the item with select(2,0), then re-selecting it with select(2,1) | |
| |
| #3 | greg.ercolano
20:47 Jul 22, 2016 |
| Lowering this to Priority 2. | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
FLTK Apps 
