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.


fltk mailing list

Reply via email to