Root Window -> Tivoli Desktop -> Region -> Profile Manager -> Profile ->  User  Admin  Categories ->  User  Admin  Subcategories Dialogs you create for use with the Application Management Toolkit probably will be installed as  User Admin subcategories. The actual component that manages your dialog is internal, so this hierarchy example should not be taken literally. It is for conceptual purposes only. Individual components of a dialog are also managed in a hierarchal manner. In this case, the dialog is the  parent  that manages each component. The components are grouped together in blocks in the DSL source file. Another DSL feature is that like other GUI development environments, it is event driven. The Tivoli desktop reacts to events such as mouse clicks or keystrokes by invoking  callbacks  registered with the specified component. A callback is a mechanism that ties an action to an event. In most GUI applications, this means that when an action (such as clicking a button) is detected, an action (such as a C function) is invoked. DSL Dialog Descriptors DSL is composed of blocks that describe the dialog or one of its aspects. The main block always begins with the keywords Command Dialog.” This is implemented, typically, when you develop the entire dialog using DSL. However, for a  User Admin subcategory, you would implement partial dialogs. The DSL is the same for a partial dialog, except that it does not have a main block; instead, it begins with the keywords  “Partial Dialog.”  For more information on partial dialogs, see the  “TME 10 Dialogs”  chapter in the  TME 10 AEF Users Guide. When using partial dialogs, the main block is actually in another DSL source file. The partial dialog is loaded and managed by another dialog, in this case the  User Properties  dialog. Overview of AEF Dialogs 104 User Administration Version 3.8