On 2009-06-30, Albrecht Schlosser <[email protected]> wrote:
> 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?
yeah i do. why is this calling the callback when i drag?
look, the callback is pd->mute(o->value(), 0);
now in mute(); i call value(1) but only if o->value() above was 1 too (and
vice versa, if called with a 0 i call value(0) on it). makes no sense,
yeah, but only if you don't know the rest. :)
anyway, why does this retrigger the callback when i drag *inside* of the
button, so that mute(0, 0); is being called... then mute(1, 0) again and so
forth....as long as i dra??
a simple example that kind of does what my callback does, is when you
change the callback in button.cxx like this:
void beepcb(Fl_Widget *p, void *) {
((Fl_Button*) p)->value() ?
((Fl_Button*) p)->value(1) : ((Fl_Button*) p)->value(0);
printf("cb"); fflush(stdout);
}
>
> 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
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
