| | [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
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 |
|---|
| Version: | 1.1-current |
|---|
| Created By: | StanS |
|---|
| Assigned To: | matt |
|---|
| Fix Version: | 1.1-current (SVN: v6031) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #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"
means.
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*)
{
fl_alert(w->label());
}
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");
win.end();
ch->add("one");
ch->add("two");
ich->add("one");
ich->add("two");
inp->callback(cb);
inp->when(FL_WHEN_NOT_CHANGED);
btn->callback(cb);
btn->when(FL_WHEN_NOT_CHANGED);
ch->callback(cb);
ch->when(FL_WHEN_NOT_CHANGED);
ich->callback(cb);
ich->when(FL_WHEN_NOT_CHANGED);
rb->callback(cb);
rb->when(FL_WHEN_NOT_CHANGED);
val->callback(cb);
val->when(FL_WHEN_NOT_CHANGED);
win.show();
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.
- flo.cc: The first two Fl_Input boxes should not trigger events when clicked. The third should. Fixed for FL_WHEN_RELEASE_ALWAYS.
- input.cc:
- 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 | |
[ Return to Bugs & Features ]
|
| |
