STR #1719

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   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.1 ]

STR #1719

Application:FLTK Library
Status:1 - Closed w/Resolution
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_WHEN_NOT_CHANGED implemented inconsistently
Created By:StanS
Assigned To:matt
Fix Version:1.1-current (SVN: v6031)
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Name/Time/Date Filename/Size top right image
#1 wavexx
07:34 Feb 15, 2008
#2 wavexx
07:35 Feb 15, 2008
#3 wavexx
07:35 Feb 15, 2008
bottom left image   bottom right image

Trouble Report Comments:

Name/Time/Date Text top right image
#1 StanS
12:47 Jun 29, 2007
This may be partly a documentation issue.  The docs say this:
   FL_WHEN_NOT_CHANGED - Do the callback whenever the user
   interacts with the widget.
Perhaps it's not entirely clear what "interacts with the widget"

In any case, there seems to be little rhyme or reason to when which
widgets do their callback after having this bit set.  Here's a partial
test to fool around with:

void cb(Fl_Widget* w, void*)
int main()
        Fl_Double_Window win(300, 300);
        Fl_Input* inp = new Fl_Input(100, 20, 100, 20, "Input");
        Fl_Button* btn = new Fl_Button(100, 40, 100, 20, "Button");
        Fl_Choice* ch = new Fl_Choice(100, 60, 100, 20, "Choice");
        Fl_Input_Choice* ich = new Fl_Input_Choice(100, 80, 100, 20,
                 "Input Choice");
        Fl_Round_Button* rb = new Fl_Round_Button(100, 100, 100, 20,
                "Round Button");
        Fl_Counter* val = new Fl_Counter(100, 120, 100, 20, "Counter");


        return Fl::run();
#2 mike
08:45 Nov 20, 2007
Will update so that buttons that are pressed but not released (i.e. you drag the mouse off the button) get the "not changed" callback.

(however, the usefulness of this for buttons seems limited...)
#3 wavexx
07:33 Feb 15, 2008
There are some inconsistencies in the definition of the enumerations, IMHO. FL_WHEN_NOT_CHANGED is defined as if it should always be combined with another event. In fact, FL_WHEN_*_ALWAYS seem to (mostly) work. But I guess we can't change that as this point.

I'm attaching a fix which also fixes STR #1870, and two test cases.

- The first two Fl_Input boxes should not trigger events when clicked. The third should. Fixed for FL_WHEN_RELEASE_ALWAYS.

 - Input does not trigger FL_WHEN_NOT_CHANGED when losing focus[1]. Fixed.
 - Button: generates FL_WHEN_RELEASE and FL_WHEN_RELEASE_ALWAYS events correctly, but changed() property is incorrect. Fixed.
 - Button2: the same for FL_WHEN_NOT_CHANGED. Fixed.
 - Choice: It's not editable, so I'm unsure FL_WHEN_NOT_CHANGE makes any sense. Menus would need to be revisited to make the whole interface consistent. Seems the correct behavior to me: NOT fixed.
 - Input choice:
   - FL_WHEN_CHANGED inconsistent with Fl_Input. Ignores user-supplied when(). Fixed.
   - FL_WHEN_NOT_CHANGED not triggered[1]. Fixed.
   - Status of changed() when the pulldown is used: fixed.
   - FL_WHEN_CHANGED generated instead of FL_WHEN_NOT_CHANGED when
     selecting the same menu item. Fixed.
 - Round button: status of changed() reversed. Fixed.
 - Toggle button: status of changed() broken. Fixed.
 - Counter: you can't release a button without making any change due to the dragging behavior: NOT fixed.

[1]: FL_WHEN_NOT_CHANGED is always generated when losing focus, even if a character is actually typed in the control. Since FL_WHEN_CHANGED is generated for every keypress, I find it acceptable. Nonetheless I could use "erase_cursor_only" as a bitfield to track the change state without changing the ABI. It's a more invasive change, so please comment on this.
#4 matt
10:03 Feb 20, 2008
Fixed in Subversion repository.

Thanks again.

As for your additional changes, I suggest that you file an STR against FLTK 1.2, unless the current situation is grave ;-). Once we decide what will come after 1.1, we will either
- create a new 1.2, using this STR
- switch to 2.1, adding all 1.2 STR to 2.1 STRS
- or start 3.0, which cold be the more stable 1.1 cre with 2.0 API and additions
bottom left image   bottom right image

Return to Bugs & Features ]


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