The most common reason to show an additional window during application flow is to ask the user for additional input or confirmation, or to alert them of (typically unexpected) events. These are standard interactions and so it's usually most effective to use, where possible, the provided dialog windows defined by the toolkit being used. Using the provided APIs will generally provide the most consistent user experience and will almost certainly lead to less code in your application as well.

The types of standard dialogs provided by a toolkit will normally include file handling (open and save), progress (when the user must wait), message (to show warnings or errors), and a confirmation dialog (to ask an immediate question). On more advanced toolkits, you can also expect to find dialog APIs to help with color selection, font selection, document printing, and even a standardized About window. The following APIs are great places to get started with some of the toolkits we covered earlier in this book (with namespace included if it's not the default):

	walk	andlabs UI	GoGTK	qt	Fyne
open	`ShowOpen`	`OpenFile`	`NewFileChooserDialog`	`widgets.NewQFileDialog`
save	`ShowSave`	`SaveFile`	`NewFileChooserDialog`	`widgets.NewQFileDialog`
progress				`widgets.NewQProgressDialog`	`dialog.NewProgress`
message		`MsgBox` `MsgBoxError`	`NewMessageDialog`	`widgets.NewQMessageBox` `widgets.NewErrorMessage`	`dialog.ShowInformation` `dialog.ShowError`
confirm				`widgets.NewQMessageBox`	`dialog.ShowConfirmation`
input				`widgets.NewQInputDialog`
color				`widgets.NewQColorDialog`
font			`FontSelection`	`widgets.NewQFontDialog`
print				`printsupport.NewQPrintDialog`
about			`NewAboutDialog`
custom	`NewDialog`		`NewDialog`	`widgets.NewQDialog`	`dialog.ShowCustom`

It's often useful to show a small selection or confirmation window that isn't in the preceding list (either because your requirements are different or the toolkit hasn't implemented that feature). This can be achieved by creating a new window, packing the content, and showing it, but the recommended method is to use the custom dialog API instead. Showing a dialog instead of a standard window allows the toolkit to configure the window to best effect. This typically involves setting it to be a non-resizable, topmost window that's modal (meaning the user can't interact with the window underneath until the dialog is dismissed).