Alvin wrote:
> I am deriving a widget from Fl_Scroll. The problem I am having is detecting
> when the user has used Fl_Scroll's scrollbars. My widget receives the
> FL_PUSH but does not receive the FL_RELEASE.
Ya, I can replicate this with the following code on linux
with 1.1.x-svn:
#include <stdio.h>
#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Scroll.H>
#include <FL/Fl_Box.H>
class Scroller : public Fl_Scroll {
public:
Scroller(int X,int Y,int W,int H,const char *L=0) : Fl_Scroll(X,Y,W,H,L) {
}
int handle(int e) {
int ret = Fl_Scroll::handle(e);
switch (e)
{
case FL_FOCUS:
case FL_ENTER:
case FL_LEAVE:
ret = 1;
break;
case FL_PUSH:
fprintf(stderr, "PUSH\n");
ret = 1;
break;
case FL_RELEASE:
fprintf(stderr, "RELEASE\n");
ret = 1;
break;
}
return(ret);
}
};
int main() {
Fl_Window *win = new Fl_Window(200,200,"Test");
Scroller *scr = new Scroller(10,10,200-20,200-20);
Fl_Box *box = new Fl_Box(10,10,500,500);
scr->end();
win->end();
win->resizable(win);
win->show();
return(Fl::run());
}
> I believe that the scrollbars returning 1 for the FL_PUSH. Then the fltk
> event mechanism is sending the FL_RELEASE directly to them (rather than via
> the parent hierarchy)? Am I right?
An interesting question about event delivery. I'm not sure I know
the answer either.. we might both be missing something.
With stuff like this, I usually go code diving as you have,
first in Fl_Scroll.cxx, then the widgets it derives from (Fl_Group.cxx,
sliders..), then try to trace the event delivery mechanism within fltk
to see how it might be short circuiting. I usually learn a lot doing
this.
Your followups..
> My solution is to hooking my own scrollbar callback into
> Fl_Scroll::hscrollbar and Fl_Scroll::scrollbar.
Seems like a decent solution, given what you're trying to do.
I can see where you'd be concerned though, since Fl_Scroll
could change its internals and affect your app's behavior.
Seems unlikely though, at least for FLTK 1.x.
> From what I can tell by reading Fl_Scroll.cxx, Fl_Scroll does not call its
> callback (ever??).
Sounds like you might be asking if Fl_Scroll's callback could be
called whenever any of the scrollers are changed, so that your
deriving class could do special child management.
Normally this kind of thing is done by having your child widget
(the one to be INSIDE the scroller) override its resize(),
since IIRC, scrolling is implemented by changing the child
widget's position(), which is essentially a resize() on x/y only,
leaving w/h alone.
I believe this is what Duncan and Albrecht are getting at
with their replies regarding resize(), which at first seems
unrelated from an 'event delivery' point of view, but might
actually be another way to do what you want, where the child
manages itself, rather than your class deriving from Fl_Scroll.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
