gtkDialogRun {RGtk2} | R Documentation |
Blocks in a recursive main loop until the dialog
either emits the
response signal, or is destroyed. If the dialog is destroyed during the call
to gtkDialogRun
, gtk_dialog_returns GTK_RESPONSE_NONE
.
Otherwise, it returns the response ID from the "response" signal emission.
Before entering the recursive main loop, gtkDialogRun
calls
gtkWidgetShow
on the dialog for you. Note that you still
need to show any children of the dialog yourself.
gtkDialogRun(object)
|
[GtkDialog ] a GtkDialog |
During gtkDialogRun
, the default behavior of "delete_event" is
disabled; if the dialog receives "delete_event", it will not be
destroyed as windows usually are, and gtkDialogRun
will return
GTK_RESPONSE_DELETE_EVENT
. Also, during gtkDialogRun
the dialog will be
modal. You can force gtkDialogRun
to return at any time by
calling gtkDialogResponse
to emit the "response"
signal. Destroying the dialog during gtkDialogRun
is a very bad
idea, because your post-run code won't know whether the dialog was
destroyed or not.
After gtkDialogRun
returns, you are responsible for hiding or
destroying the dialog if you wish to do so.
Typical usage of this function might be:
result <- dialog$run() if (result == "accept") do_application_specific_something() else do_nothing_since_dialog_was_cancelled() dialog$destroy()
Note that even though the recursive main loop gives the effect of a
modal dialog (it prevents the user from interacting with other
windows in the same window group while the dialog is run), callbacks
such as timeouts, IO channel watches, DND drops, etc, will
be triggered during a gtkDialogRun
call.
[integer] response ID
Derived by RGtkGen from GTK+ documentation