On 08.04.2013 11:58, Albrecht Schlosser wrote: > There are two ways to overcome this:
.. at least .. > (1) I recommend not to use Fl_Pack, ... > > (2) I don't recommend this one, but it should give you a clue > ... (3) You might also recalculate the button positions in your callbacks/functions to modify the group, i.e. clearto() and/or onMenu(), but you would have to do it in the same way as Fl_Pack would do it later in its draw() method. This way, you'd have the popup() work depending on the new positions, as you expect. The point why I don't recommend this either is because you'd have to *know* how Fl_Pack calculates the positions. However, this is not trivial, but could work with your simple buttons. But if you do this anyway, why not create an own group class? You could also overwrite the resize() method and rearrange your buttons while the window/group is being resized. Then you would be able to call resize() after you rearranged the group's buttons, and that's it. I like this more than recalculating positions in draw(), because (a) it's less overhead, and (b) you avoid the problems you see in your program. So I still recommend (1). Here's a small amendment to my previous posting. I wrote: > Here the menu pops up, but Fl_Pack still "knows" of the old > button position(s), hence the unexpected position. In fact, Fl_Pack is not involved here. It's the button widget that still "knows" its old position, because Fl_Pack didn't rearrange the children yet. Albrecht _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
