On 1 Jan 2013, at 21:44, Denton Thomas wrote:
>> My thinking is that this *should* work and would mean that only one >> "special" derived widget is needed, rather than having to make every >> contained widget be a "special" widget. >> > > Yep, I agree. I've just made a template to add the handlers to any old > widget, but it seems like a kludge. > >> From what I can tell, an Fl_Group does not parse events if they are already >> within the group. If I tab from one widget to another, within the group, the >> event never goes through Fl_Scroll:handle(). So the group never knows to >> check whether focus has changed hands/positions. > > At least I don't -think- it does ... I'll test some more. Ah... that was what I was worried about, perhaps... (Paraphrasing somewhat...) Normally, events in fltk get propagated from the container widget (e.g. group or scroll) down to its children, until one of them takes it. But I suspect that keyboard events get routed *first* to the widget with focus, and only if it doesn't want them, do they get passed to the container widget to be distributed. And so I guess it is possible that keyboard nav events would go to the focus widget without necessarily passing through the parent container at all. And thereby rendering my cunning scheme useless. Oh well. If you look into this further, be handy to know for sure if this is the way things are! _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
