DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L1895 Version: 1.1-current First off, I marked this STR as LOW only because I believe this is a undocumented side-effect. Fl_Scroll only updates the state of its scrollbars in its draw() function. Though this seems to be fine for Fl_Scroll, it does cause some headaches when deriving a new widget based on Fl_Scroll. For example, I was writing a scroll widget that centres its children within the viewable area. To do this, I override resize() and used Fl_Scroll::bbox() to obtain the new viewable area (after calling Fl_Scroll::resize()). I then use the viewable area to calculate where to reposition each child. This mostly worked but would often break. The problem was that Fl_Scroll::bbox() uses the state of the scrollbars to calculate and return the viewable bounding box. However, Fl_Scroll only updates its scrollbars during a redraw(). Therefore, it is impossible for a derived class to know the true viewable area during a call to resize(). The workaround is instead, to override the draw() method and do the widget centring after calling the parent Fl_Scroll::draw(). I believe this to be counter-intuitive mostly because, AFAICT, this behaviour is not mentioned in the docs. One possible solution is to refactor Fl_Scroll::draw() into a (1) drawing component and (2) scrollbar managing component. The scrollbar managing code could then be placed into its own protected function. This would allow derived classes the ability to force Fl_Scroll to manage its scrollbars when it desires. In my example, the widget centring logic could be placed in the overridden resize() method rather than having it executed each time the widget is redrawn. Link: http://www.fltk.org/str.php?L1895 Version: 1.1-current _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
