Menus and Dialogs in Tk

A Tk application's menu bar is built from menu widgets: you create a top-level menu with menu .menubar, attach it to the window using . configure -menu .menubar, and then populate it with cascading submenus—menu .menubar.file followed by .menubar add cascade -label File -menu .menubar.file—so the menu bar itself contains only cascades, while each cascade menu holds the actual clickable entries. Entries within a menu are added with add command -label "Open..." -command openFile -accelerator "Ctrl+O", where -accelerator only displays the shortcut text next to the label and does not itself bind the key—you still need a separate bind . <Control-o> openFile for the shortcut to actually work—and add separator inserts a thin dividing line to visually group related entries, such as separating Save and Save As... from Exit.

Menu entries aren't limited to plain commands: add checkbutton -label "Word Wrap" -variable wrapVar -onvalue 1 -offvalue 0 puts a toggleable checkmark entry in the menu that stays synced to a Tcl variable exactly like a checkbutton widget does, and add radiobutton -label "12pt" -variable fontSizeVar -value 12 lets several radiobutton entries share one variable so only one can be checked at a time, useful for a font-size or view-mode submenu. Submenus are just cascades pointing at another menu widget, so a deeply nested structure like View > Zoom > 100% is built by creating .menubar.view, then .menubar.view.zoom, then adding add cascade -label Zoom -menu .menubar.view.zoom inside the view menu, and finally adding the individual zoom-level radiobutton entries inside the zoom menu itself.

Context menus—the menu that appears on a right-click—are built the same way as a menu bar's submenus, as a standalone menu widget that isn't attached to any cascade, and are shown on demand with tk_popup .contextMenu $x $y, which posts the menu at the given screen coordinates and handles all the platform-specific details of positioning and dismissing it. The typical pattern binds the right mouse button (<Button-3> on Windows/Linux, though it's <Button-2> on some older Mac configurations, which is why cross-platform code often binds both) to a small procedure that calls tk_popup .contextMenu %X %Y, using the uppercase %X/%Y substitutions for screen-relative coordinates rather than the lowercase %x/%y, which are relative to the widget instead and would position the popup incorrectly.

Tk ships several ready-made modal dialogs so you don't have to hand-build common interactions: tk_messageBox -message "Delete this file?" -type yesno -icon warning shows a message with standard buttons and returns which button was pressed (yes or no) as its result; tk_getOpenFile and tk_getSaveFile show the platform's native file-picker and return the chosen path (or an empty string if canceled); and tk_chooseColor shows a color picker and returns the selected color as a hex string like #3a7bd5. Because these are modal dialogs, the Tcl script calling them blocks at that line until the user responds—the dialog commands don't return until the dialog is dismissed—which is exactly the behavior you want for a confirmation prompt, since the calling code typically needs the user's answer immediately before deciding whether to proceed with deleting the file or discarding the changes.