Re: A signal for Gtk::MessageDialog

[pks timing com]

Jamiil Abduqadir writes:
 > Thanks again Chris,
 > I did some more research, but I cannot see how that
 > Gtk::Dialog::signal_response() can help me

signal_response() is described a bit in the Gtk::Dialog
(Gtk::MessageDialog's superclass) class description.

When the dialog creates buttons, it attaches an internal
signal handler to their click event.  This internal
signal handler turns around and emits the signal that is
accessed via the proxy returned signal_response().

Note the signal_response() declaration:

Glib::SignalProxy1<void, int> signal_response();

Pay attention to second template parameter in particular.
This is the type of the only parameter the signal_response()
handler will receive.  This integer identifies the dialog
button which was clicked.

If you create a message dialog with "yes" and "no" buttons,
both buttons (through the internal handler mentioned above)
will trigger signal_response().  In the handler you can use
the integer value to determine which of the buttons called
the handler.

Since you're only providing an "ok" button, you'll be able
to ignore the value (it will always identify the "ok" button).
Your signal handler will have to accept it nonetheless.

1) ----------------------------

 >    //Signal handlers:
 >    virtual void on_button_clicked();

change your signal handler to accept the integer parameter
which identifies the button (making the private function
virtual, only incurs overhead when calling it, if anything):

void on_button_clicked(int buttonid);

2) ----------------------------

 > UnknownButtonVariableName.connect( sigc::mem_fun(*this,
 > &GtkmmException::on_button_clicked) );

connect to signal_response() instead:

signal_response().connect(sigc::mem_fun(*this,
    &GtkmmException::on_button_clicked) );

3) ----------------------------

 > void jme::GtkmmException::on_button_clicked(){ destroy_(); /*??*/}

accept the buttonid integer parameter in the event handler
implementation as well:

void
jme::GtkmmException::on_button_clicked(int buttonid)
{
    std::cerr << "BUTTONS WAS: " << buttonid << '\n';
    destroy_();
}

4) ---------------------------

change the constructor to provide Gtk::BUTTONS_YES_NO instead of
just Gtk::BUTTONS_OK, and destroy the dialog with each button.
observe the std::cerr << "BUTTON WAS: " output for each button
to understand what's going on.

5) ---------------------------

note that there's a protected virtual on_response(int buttonid)
in the dialog class (inherited by your class from Gtk::Dialog,
through Gtk::MessageDialog).  You can probably just override that
function and avoid going through the signal ...



finally, I'm not sure that destroy_() is really what you're after.
Others will be qualified to discredit or verify this concern, but:

I assume calling destroy_() alone introduces a resource leak if the
jme::GtkmmException objects don't go out scope or aren't whacked with
c++ delete operator.  That is I doubt that a destroy_() call will
actually destruct the object.

Verify this by adding some debug output to the destructor.
If the destroy_() call actually causes destruction (of the object,
not just the window resources), great!

If you know the exception objects will go out of scope or be
deleted explicitly, just hide the dialog instead - the destructor
will do the job.