JanE wrote:
> greetings,
>
> i have just found that the Fl_Button handle() enables
> dragging on buttons. if when() matches FL_WHEN_CHANGED it
> even triggers the callback, so that when you drag on it, it
> constantly switches on and off.
>
> why is this behaviour wanted? enlighten me please? :)
I'm not sure, but I think that a part of the problem is that
Fl_Button::handle()
handles all kinds of buttons, including radio buttons, and this might be part
of
the problem. The code is at least difficult to understand, and IIRC there is no
complete documentation of what is intended and what not.
That said, there may be unintended behavior as well.
> anyway, this behaviour is annyoing in the following
> example:
> a Mute button in a mixer. it should trigger the callback
> instantly, otherwise you cant precisely mute (think drum
> track muting), so we set it to call the callback on
> FL_WHEN_CHANGED. now, if you accidently drag slightly
> instead of just pushing the button (may happen right?), it
> could be that the callback is triggered twice and, oh no,
> the drumtrack moves on!
I can't reproduce this. IIRC you're using 1.1.9? Is this behavior different on
different platforms (what are you using?).
I tried it with test/button.cxx and the following patch:
$ svn diff
Index: test/button.cxx
===================================================================
--- test/button.cxx (revision 6805)
+++ test/button.cxx (working copy)
@@ -31,8 +31,10 @@
#include <FL/Fl_Window.H>
#include <FL/Fl_Button.H>
-void beepcb(Fl_Widget *, void *) {
+void beepcb(Fl_Widget *w, void *) {
printf("\007"); fflush(stdout);
+ Fl_Button *b = (Fl_Button*)w;
+ //b->value(b->value());
}
void exitcb(Fl_Widget *, void *) {
@@ -52,6 +54,7 @@
Fl_Window *window = new Fl_Window(320,65);
Fl_Button *b1 = new Fl_Button(20, 20, 80, 25, "&Beep");
b1->callback(beepcb,0);
+ b1->when(FL_WHEN_CHANGED);
/*Fl_Button *b2 =*/ new Fl_Button(120,20, 80, 25, "&no op");
Fl_Button *b3 = new Fl_Button(220,20, 80, 25, "E&xit");
b3->callback(exitcb,0);
This is fltk 1.3 code, but I also tried it with 1.1 (and even 2.0 - there's
also
an open STR about different behavior with 2.0, but I don't remember the number).
The significant part in this patch is "b1->when(FL_WHEN_CHANGED);". I can only
see that the button triggers the callback while dragging when the mouse pointer
leaves the button area (and when it enters again). While the latter is (IMHO)
somewhat unexpected behavior, this is not what you described.
It's a completely different story, if you uncomment the statement in beep_cb:
"b->value(b->value());". Do you by any chance use value(int) inside your
callback?
To find out what's happening, can you produce a small example like this, maybe
starting with test/button.cxx, that reproduces your described behavior?
I'm interested to find bugs, if there are any.
> i fixed this by overwriting the handler in a derived class,
> but like to discuss this anyway.
Yep, this the way to go if you need "special" behavior. FLTK can only give you
some standard behavior with its callbacks. You can tune it by setting when(),
and if you need more fine tuning, you can even access any event related info
(like mouse cursor position while dragging [HINT]) in your callback - but if
this is not enough, subclassing is the way to go.
Albrecht
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
