Bill, did you miss this? I posted it in a message to Kirill. It's in one of my workspaces. DEFUN ("popup-dialog-box", Fpopup_dialog_box, 1, 1, 0, /* Pop up a dialog box. There are numerous ways to specify how a dialog box will look. They are indicated by symbols, which are: 'built-in' Indicates a window-system-specific, built-in fully-formed dialog box (such as the "common dialog boxes" under MS Windows, which include file dialog boxes, print setup boxes, etc.). 'standard' Indicates that XEmacs creates the dialog box by making a frame and populating it with a single layout glyph, containing subglyphs, etc. and the result looks like a dialog box. 'peer' Indicates that XEmacs creates the dialog box on the "peer" side, i.e. using the standard widgets/controls and layout mechanisms available in the graphics API's we're dealing with. `peer' support and `built-in' support is obviously highly window-system and window-toolkit dependent. `standard' support is less dependent; although it does make use of basic controls/widgets supplied by the window system and window toolkit, the layout and all higher-level input and output is controlled by XEmacs in an architecture-independent fashion. NOTE: Standard support is not implemented yet (the glyphs that correspond to controls/widgets have been implemented), we just haven't yet gotten them to go into a frame by themselves. Normally, a dialog box description is a cons of a symbol indicating the format of the dialog box description, which is followed by the description itself. For backward compatibility: If the first element of the dialog box description is a string, then it is assumed that this is the start of a `peer'-type description. For a built-in type description: -------------------------------- The description is a list. The first element is the particular dialog box to be displayed; this can be one of color find font open A file dialog box. print page-setup replace save-as The rest of the description becomes the descriptor for the particular type of built-in dialog box. They are: open and save-as: (INITIAL-FILENAME CALLBACK :keyword value ...) INITIAL-FILENAME holds the initial filename to be placed in the dialog box. CALLBACK is code that will be called when the dialog box is closed down normally; it is called with one argument, the filename selected by the user. The keywords are :initial-directory dir :filter-list (filter-desc filter ...) :title string :allow-multi-select t or nil :create-prompt-on-nonexistent t or nil :overwrite-prompt t or nil :file-must-exist t or nil :no-network-button t or nil :no-read-only-return t or nil #### unfinished For a peer type description: ---------------------------- The first element of a description must be a string, which is the title or question. The rest of the elements are descriptions of the dialog box's buttons. Each of these is a vector, the syntax of which is essentially the same as that of popup menu items. They may have any of the following forms: [ "name" callback <active-p> ] [ "name" callback <active-p> "suffix" ] [ "name" callback :<keyword> <value> :<keyword> <value> ... ] The name is the string to display on the button; it is filtered through the resource database, so it is possible for resources to override what string is actually displayed. Accelerators can be indicated in the string by putting the sequence "%_" before the character corresponding to the key that will invoke the button. Uppercase and lowercase accelerators are equivalent. The sequence "%%" is also special, and is translated into a single %. If the `callback' of a button is a symbol, then it must name a command. It will be invoked with `call-interactively'. If it is a list, then it is evaluated with `eval'. One (and only one) of the buttons may be `nil'. This marker means that all following buttons should be flushright instead of flushleft. Though the keyword/value syntax is supported for dialog boxes just as in popup menus, the only keyword which is both meaningful and fully implemented for dialog box buttons is `:active'. */ (dbox_desc)) "William M. Perry" wrote: -- Ben In order to save my hands, I am cutting back on my mail. I also write as succinctly as possible -- please don't be offended. If you send me mail, you _will_ get a response, but please be patient, especially for XEmacs-related mail. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding. See also http://www.666.com/ben/typing.html.