Dialog Box Components

AutoCAD AutoLISP & Visual LISP

 
Dialog Box Components
 
 
 

The following figure shows a standard AutoCAD® dialog box, with some of its components labeled. In dialog box creation and customization these components are known as tiles.

A dialog box consists of the box and the tiles within it. The basic tile types are predefined by the programmable dialog box (PDB) facility.

You can create complex tiles, called subassemblies, by grouping tiles into rows and columns, with or without an enclosing box or border. A row or column of tiles is referred to as a cluster. Subassemblies define groups of tiles or clusters that can be used in many dialog boxes. For example, the OK, Cancel, and Help buttons are grouped into a subassembly, defined as a row (cluster) of three button tiles and some spacing separating the buttons.

Subassemblies are treated as single tiles. The tiles within a subassembly are called children. DCL files are organized in a tree structure. At the top of the tree is a (dialog) tile that defines the dialog box itself. The following diagram shows a DCL file structure:

The layout, appearance, and behavior of a tile or subassembly are specified in DCL by the tile's attributes. For example, the dialog itself, and most predefined tile types, has a label attribute that specifies the text associated with the tile. The label of a dialog box defines the caption at the top of the dialog box, the label of a button specifies the text inside the button, and so on.

DCL also enables you to define new tiles, called prototypes, that are not necessarily associated with a specific dialog box. This is useful when you want to use the same component in several dialog boxes. You can reference prototype tiles from other DCL files and change their attributes the same way you change predefined tiles.

Before you program a dialog box, plan both the dialog box and the application in detail before you code and debug. The sequence in which the data is entered will vary with each user. The need to anticipate a variety of user actions imposes a program structure that is less linear than conventional programming, but is more reflective of the way users work.