After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 580219 - delete_event on a dialog returns Gtk::RESPONSE_DELETE_EVENT
delete_event on a dialog returns Gtk::RESPONSE_DELETE_EVENT
Status: RESOLVED FIXED
Product: gtkmm
Classification: Bindings
Component: reference documentation
2.12.x
Other All
: Normal minor
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2009-04-25 14:24 UTC by Federico Poloni
Modified: 2010-04-03 14:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Federico Poloni 2009-04-25 14:24:10 UTC 
Documentation 
Section: Gtk::Dialog Class Reference
"If a dialog receives a delete event, the "response" signal will be emitted with a response id of Gtk::RESPONSE_NONE."

Correct version:
"If a dialog receives a delete event, the "response" signal will be emitted with a response id of Gtk::RESPONSE_DELETE_EVENT."

Other information:
Comment 1 Johannes Schmid 2009-10-28 15:31:52 UTC 
Hmm, seems to be fixed in master:

"During gtk_dialog_run(), the default behavior of #GtkWidget::delete-event
is disabled; if the dialog receives ::delete_event, it will not be
destroyed as windows usually are, and gtk_dialog_run() will return
#GTK_RESPONSE_DELETE_EVENT. Also, during gtk_dialog_run() the dialog
will be modal. You can force gtk_dialog_run() to return at any time by
calling gtk_dialog_response() to emit the ::response signal. Destroying
the dialog during gtk_dialog_run() is a very bad idea, because your
post-run code won't know whether the dialog was destroyed or not."

Can you confirm this?
Comment 2 Tobias Mueller 2010-04-03 14:07:16 UTC 
Closing as FIXED as per last comment. Frederico, please reopen if this is still an issue, or set to VERIFIED if it is indeed fixed. Thanks in advance!