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.


fltk mailing list

Reply via email to