On 04.01.2013 03:12, Denton Thomas wrote: > Albrecht wrote: >> It's not perfect, and maybe some of the changes would turn out >> to be useless... just take it as a base for more own experiments. >> > > Thanks for all this, Albrecht. I'll certainly use those immediately. I > appreciate it, as this is part of a current project. > > I'll keep testing re the style/redraw problem. I'm not sure what I'm doing > wrong there - the box style changes just didn't appear on screen ... which > was odd. I'll check out your patch to see how you've done it.
You'll see that I did it by explicitly calling redraw() on the scroll widget (see the notes and the callback). You may need to call the parent's redraw method as well, if you have a frame box time somewhere, so that the redraw doesn't draw the background. > As well, I caught a more glaring problem: if Fl::focus() is in a group inside > of the Fl_Scroll, then it seems the Fl_Scroll::handle() method is not ever > run ... so the focus tracking code can't run. I'll write a general test to > make sure it's not my own Fl_Group subclass that's hogging the event chain, > though. Oh, yes, that's certainly true. If navigation happens to succeed in a subgroup, then this subgroup does it all. No parent group will notice. You could maybe derive an own Fl_Group class to do this in conjunction with its parent YourScroll class, but this could be a never ending story, unless you know exactly what groups and widgets you need in your special case. In my case I'm using only simple widgets within the scroll and I handle it all in the child widgets, but this is a special case, since all /my/ child widgets are own classes anyway (and inherit from another common class as well - which is not generally recommended to do, but I did ...). Another issue I observed in your test case that I couldn't fix in my tests is this: click on the input field, then use SHIFT/TAB to go backwards into your group. This is not handled by the scroll widget. Go one more back with SHIFT/TAB, then forwards with TAB, and you'll see. Try also to move the scrollbar to scroll the last widget out of the visible area while the focus is on it or on the input widget, then use TAB and/or SHIFT/TAB. That's what I meant when I wrote that there's a problem when the focus leaves the scroll widget and comes back to it. Another small point: you tested that the same widget doesn't scroll if it gets the focus again, e.g. by mouse clicking. So, if you move the scroll area while one widget has the focus to move it partly out of the scroll area, then click on it again, it will stay where it is and doesn't scroll to be fully visible. This could be called a feature though... One last point: in your original test program I could sometimes make the input widget to get a red background. I hope this is fixed with my 2nd patch, but you should check this, if you intend to do something with the "previous focus widget" to make sure you don't modify a widget outside your scroll group. Albrecht _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
