STR #3292

GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

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:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size top right image
 
#1 greg.ercolano
11:40 Mar 07, 2016
browser.cxx
5k
 
bottom left image   bottom right image

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
 
#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.  
bottom left image   bottom right image

Return to Bugs & Features | Post Text | Post File ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2021 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.