gtkDialogRun {RGtk2} | R Documentation

## gtkDialogRun

### Description

Blocks in a recursive main loop until the `dialog` either emits the `gtkDialogResponse` signal, or is destroyed. If the dialog is destroyed during the call to `gtkDialogRun`, `gtkDialogRun` returns `GTK_RESPONSE_NONE`. Otherwise, it returns the response ID from the ::response signal emission.

### Usage

    gtkDialogRun(object)

### Arguments

``object`` | a `GtkDialog`

### Details

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.

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 == GtkResponseType["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.

### Value

[integer] response ID

### Author(s)

Derived by RGtkGen from GTK+ documentation

[Package RGtk2 version 2.20.40 Index]