Re: dialog close signal and hiding dialog...

On Tue, 2003-08-12 at 19:48, Matthew Weier OPhinney wrote:
Okay, I figured out what I needed to do. The dialog is actually being
called as part of another class, something like this:

    package ROX;
    sub edit_options {
        my $dialog = ROX::OptionsBox->new(...some options);
        $dialog->show; # where show is a routine in ROX::OptionsBox

    package ROX::OptionsBox;
    do a bunch of stuff related to creating and manipulating dialog

The solution I discovered was to add the following to the ROX package:

        destroy => sub {
            ... some cleanup ...
            undef $dialog;

($dialog->dialog is the actual GtkDialog object). As you can see, I'm
destroying the entire object I've created; it then gets recreated next
time I need the dialog. I'd _prefer_ to be able to keep it around for
later (as I'm able to do when I click the 'Ok' button and do a
$dialog->hide); however, this works, and I no longer get the
segmentation faults.

according to this:

the default behavior (destroying) of the delete event is blocked while
in a gtk_dialog_run call. instead the response GTK_RESPONSE_DELETE_EVENT
(delete-event) is returned and it is up to the programmer to destroy or
(in your case) hide the widget. it would then exist the next time you
come around to run it as you want. i'm pretty sure that i've relied on
that behavior in the past. 

i see you have $dialog->show that is a method of ROX, but in that show
do you call run. what you are describing sounds like you're calling show
and trying to handle the signals yourself. with a Gtk2::Dialog you
should do something like the following

my $dialog = new Gtk2::Dialog(...);

# blocks until the button is clicked
# returns which one
$resp = $dialog->run; 
if( $resp eq 'ok' )
        # save the settings
else # ( $resp eq 'revert' ) 
        # revert to old settings

        # notice that delete-event would have fallen in here too
        # thus given the expected behavior that if they click the 
        # X to close the window they probably didn't want to
        # save the changes.

in most cases you should not have any signals connected to your dialog.
that's the beauty and purpose of it. if you're connecting your own
signals then you're probably not using it as it was intended.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]