Re: menus whose contents change

[Steve & Patti Getzinger <steveandpatti wubs org>]

Without more info I would define what causes the change to happen and
key if's around that occurance. Defining labels as vars would also help
a great deal and if you know in advance all possible vars you can write
your funcs (callbacks) with the same names so that you could insert the
var for the label as the var for the func called also. I am working on a
file selection box using this mentality. It is used for file open, save
and save as. Naturally what triggered the creation of the dialog will
determine the labels used and the funcs called.

Steve

Deborah Swayne wrote:
> I have some menus whose contents are not static -- cascading menus
> may be needed sometimes but not always, for instance, and the state
> of checkboxes may change.
>
> If there's only one source of change, then I can call a routine that
> destroys and rebuilds a menu, and that works reasonably well.
> Sometimes, though, it seems preferable to build the menu on the fly.
> I can do that by making some menus popup menus, and it works
> wonderfully -- but they no longer behave like other menus.
>
> I understand that they can't open when the mouse floats over, but I
> don't like it that they trigger on a mouse-up instead of a
> mouse-down, or that they position themselves at the center of the
> menu item from which they're triggered.
>
> Maybe this just isn't the best way to deal with menus whose contents
> change -- does someone else have a better approach?
>
> Debby
>
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list