Ian, I agree with you 100%, but want to add one comment. On 08.04.2013 12:28, MacArthur, Ian (Selex ES, UK) wrote:
> Albrecht also suggests a workaround based on timers. I think this might work > out pretty well, though I'd consider having my own derived Fl_Pack (or > similar container widget) that, in its derived draw() method, sets a flag to > tell whether the draw has actually been enacted (and hence the sizes properly > recalculated) and have that flag cleared down by the callback that triggers > the timer. > > The timer can then "poll" until it sees that the widget has been drawn (the > flag is re-set) and thence that the sizes ought to be correct, for popping up > the menus now... > > Well, something like that... Yep, this was suggested as a workaround only, either to see how it can be done (just for learning), or if one really wants to use Fl_Pack. Deriving from Fl_Pack (as I assume you meant above) for another container widget and do the polling makes things even worse, but I assume that you only wrote it for the same reasons as I did. My personal opinion is that users should NOT try to resize widgets in their draw methods, since this will lead to problems earlier or later. The problems with Fl_Pack result just from the fact that it tries to "allow" its children to resize in their respective draw() methods, and hence it *must* recalculate positions after calling the children's draw() methods - thus the only way to do it is in its own draw() method. My suggestion in my other posting about resizing/rearranging children in resize() seems to be much better for user code, and I'm using it in my apps successfully. Albrecht _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
