at onceas shown in figure - figure - modal custom dialog at work in factthe call to the dialog function in this script doesn' return until the dialog window on the left is dismissed by pressing its ok button the net effect is that modal dialogs impose function call-like model on an otherwise event-driven programming modeluser inputs can be processed right awaynot in callback handler triggered at some arbitrary point in the future forcing such linear control flow on gui takes bit of extra workthough the secret to locking other windows and waiting for reply boils down to three lines of codewhich are general pattern repeated in most custom modal dialogs win focus_set(makes the window take over the application' input focusas if it had been clicked with the mouse to make it the active window this method is also known by the synonym focusand it' also common to set the focus on an input widget within the dialog ( an entryrather than on the entire window win grab_set(disables all other windows in the application until this one is destroyed the user cannot interact with other windows in the program while grab is set win wait_window(pauses the caller until the win widget is destroyedbut keeps the main eventprocessing loop (mainloopactive during the pause that means that the gui at large remains active during the waitits windows redraw themselves if covered and uncoveredfor example when the window is destroyed with the destroy methodit is erased from the screenthe application grab is automatically releasedand this method call finally returns because the script waits for window destroy eventit must also arrange for callback handler to destroy the window in response to interaction with widgets in the dialog window (the only window activethis example' dialog is simply informationalso its ok button calls the window' destroy method in user-input dialogswe might instead install an enter key-press callback handler that fetches data typed into an entry widget and then calls destroy (see later in this dialogs