anguila <[EMAIL PROTECTED]> writes: > > I attach a example of the problem.
For the close button you might have to hook it up to emit the "close" signal on the dialog. An "Esc" keybinding is setup automatically to do that, but a button may have to do it explicitly (even if named "Close" etc). For the re-open the message Gtk-CRITICAL **: gtk_container_foreach: assertion `GTK_IS_CONTAINER (container)' failed at test.pl line 19. is the bit I wondered before. It means you've tried to show a dialog that's already destroyed, in this case by the default handler of delete-event. To keep it alive you can put a handler on the delete-event signal like gtk_widget_hide_on_delete(), except that's not wrapped I think, so the same in perl sub hide_on_delete { my ($widget) = @_; $widget->hide; return 1; # don't propagate event } I recently suffered through some similar bits. It's probably not meant to be quite so tedious. I submitted a gtk bug for the gtk_container_foreach message and apparently it's notabug to print something unhelpful and uninformative. (It arises of course in language bindings, where gtk_widget_destroy isn't necessarily the end, because variables and whatnot can be keeping the object alive past that. In a sense I guess language bindings end up with ->destroy being not much more than emitting the destroy signal, which is not really how it was originally conceived for C.) Incidentally, for $about->show() you might want to use ->present instead, to raise the window if it's already open but buried somewhere underneath other windows. _______________________________________________ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list