TOC PREV NEXT INDEX DOC LIST MASTER INDEX



Menu Files

The menus that appear on and pop up from Apex windows are the result of processing a sequence of menu files. Menu files are text files that define the layout of menus. Apex allows you to customize them.

The following topics are covered in this chapter:


How Apex Looks for Menu Files

Apex looks for menu files in the colon-separated sequence of directories specified by the APEX_MENUS_PATH session switch. By default, apexinit initializes it to:

The first directory —— usually $APEX_HOME/editor_files —— contains the standard menu files. Succeeding directories, if present, can contain menu files that incrementally change the standard menus. $HOME/.Rational is the directory in which individual users can make personal changes.

For additional information on the apexinit command, open an Apex shell (Tools > Shell) and enter:

Changing Menus for Personal Use

To make personal changes, create customized menu files in the .Rational subdirectory under your home directory. (Menu files are described in more detail in the remainder of this chapter.) Your changes will appear the next time you start Apex.

Note: The APEX_MENUS_PATH environment variable is automatically initialized to include $HOME/.Rational, so you do not need reset it unless you want to place menu files somewhere else.

Changing Menus for All Users

To make local changes for all users at your site:

1 . If you do not already have one, create a local customization directory referred to as local_dir, which is visible to all users at your site.

2 . Create the subdirectory local_dir/editor_files.

3 . Create customized menu files in local_dir/editor_files.

4 . Have each user set the APEX_LOCAL_DIR session switch to local_dir. Then, because local_dir contains an editor_files subdirectory, apexinit will initialize APEX_MENUS_PATH to:


Menu Filenames

Menus are associated with a particular Apex server. Thus, menu filenames are of the form server_menus, where server is one of: ada (Ada only), debugger, directory, output, or text. The C/C++ editor uses the text menus (C/C++ only).

The standard menu file associated with each server in the $APEX_HOME/editor_files directory:

Directories such as local_dir/editor_files and $HOME/.Rational can contain menu files with any or all of these names, depending on which sets of menus you want to customize.

The last directory listed on APEX_MENUS_PATH —— usually $HOME/.Rational —— can also contain a file named menus. If it is present, every server reads it. Thus, the menus file can contain commands that change the menus for all servers.

Note: A menus file in a directory that is listed anywhere other than last on APEX_MENUS_PATH is ignored by all servers.

Restarting Apex Servers

Changes to menu files take effect the next time you start the Apex servers with which they are associated. Exiting Apex quits all of your Apex servers, and starting Apex restarts all of your Apex servers.

You can also quit individual Apex servers without exiting Apex. To kill a server:

1 . Bring up the Servers window:

a . Display the Jobs window by executing the Navigate > Jobs command from most windows.

b . Display the Servers window by executing the Navigate > Servers command from the Jobs window.

2 . Select the server that you want to kill in the Servers window as illustrated in Figure 35.

Figure 35 Server Window

3 . Execute the File > Kill command.

The server that you killed restarts automatically when it is needed. Activities that restart servers are described in Table 14.

Table 14 Activities that Restart Apex Servers
Doing this:
Restarts this:
Visiting a directory
Directory server
Editing a text file
Text server
Editing a C/C++ file (C/C++ only)
Text server
Editing an Ada unit (Ada only)
Ada server
Debugging a program
Debugger server


Menu File Syntax

The standard menu files in $APEX_HOME/editor_files are written in a hierarchical nested syntax used for defining entire menus. Customized menu files that you create are written in an incremental modification syntax used for defining changes that you want to make relative to the standard menus.

In menu files, a number sign (#) begins a comment; the comment continues to the end of the line. A backslash (\) is used to continue a command on the next line. You can include commands from other menu files by inserting #include commands in your menu file:

The included filename can be the simple name of another menu file in the same directory as your menu file, or it can be the fully qualified name of another menu file in an arbitrary location. The filename can contain UNIX environment variables.


Menu Components

Menu files deal with the following basic controls: cascade buttons, push buttons, toggle buttons, and separators. Their names, shown in Table 15, appear in the standard menu files and in menu-manipulation commands in customized menu files.

Table 15 Menu Control Names
Control name
Description
cascade
A button used to display a pull-down menu
pushbutton
A button used to activate an operation (any menu command)
togglebutton
A button with two states: on and off
separator
A dividing line between menu items


Menu Item Names

Menu components are grouped or nested to form menu items. The items that make up menus have unique, fully qualified names. A fully qualified menu item name consists of the following, separated by periods (.):

For example:

The window kind can be represented by an asterisk (*), which is a wildcard for "any window." For example, you could put *.file.new in your $HOME/.Rational/menus file to represent File > New on any window.

These menu item names are internal names; you do not see them on the screen. Each menu item also has a label string and a mnemonic associated with it. The label string is the text that appears on the screen, for example, as the user-visible name of a menu button. The mnemonic is the underlined letter in the label string that can be used as a keyboard shortcut.

Note: Accelerators are not mentioned here because they are specified by X Window System resources, not menu files. See Mnemonics and Accelerator Keys for more details.

Internal names are usually derived from the label string by:

For example, the label string Check In... is reduced to the internal name checkIn. To find the name of any existing menu item, consult the menu files in $APEX_HOME/editor_files.


Commands

Commands to manipulate existing menus consist of a keyword that starts on a new line followed by arguments on the same line. The following sections describe commands for:

Changing a Label String

The command to change a label string is:

where:

For example, to change the label string of the directory viewer's Navigate menu from "Navigate" to "Browse," place the following command in your directory_menus file:

The label string of a menu button also appears in the button bar when that menu button is placed in the button bar (as described in Button Bars). To fit more buttons into a single row on the button bar, shorten their label strings.

For example, to change "Check In..." and "Check Out..." to "In..." and "Out..." on all Control menus, you could place the following commands in your menus file:

If a button on a menu or button bar also appears on a pop-up menu, you need to change the label string on the pop-up menu separately. For example:

Deleting a Menu Item

The command to delete a menu item is:

where:

For example, users who are never responsible for controlling or uncontrolling objects could place the following commands in their menus files:

Positional Deletions

Items can also be deleted positionally:

where:

Appending a Menu Item

The command to append a menu item is:

where:

For example, to add your own tool to the bottom of all Tools menus:

Inserting a Menu Item

The command to insert a menu item is:

where:

  • component is cascade, pushbutton, or togglebutton.
  • name is a menu-item name of the form described in Menu Item Names.
  • new_label_string is any string. It must have double quotes if it is not a single word —— that is, if it contains white space.
  • mnemonic is a single character that occurs in the new label string. It is optional, as indicated by the brackets, which do not appear in the command.

    For example, to add your own tool to the top of all Tools menus:

    To create a submenu containing several of your own tools:

    The resulting submenu is shown in Figure 36.

    Figure 36 Tools Menu with Additional Submenu

    Replacing a Menu Item

    The command to replace a menu item is:

    where:

    For example, to replace the directory viewer's Tools > Shell menu item with your own tool:

    Moving a Menu

    The command to move a menu is:

    where:

    For example, if you frequently use the Ada editor's Control > Show menu, you could move it to the menu bar for easier access:

    Alternatively, you could move all Show submenus so that they were the first entry on all Control menus:

    Copying a Menu

    The command to copy a menu is:

    where:

    For example:

    Suppressing a Dialog Box

    Apex commands that ordinarily display a dialog box can be changed to execute directly. The command to suppress the dialog box is:

    where name is the name, in the form described in Menu Item Names, of the pushbutton item to be changed. For example, you could add the following command to your text_menus file to make Control > Check Out check out the file you were editing without displaying a dialog box:

    Replicating a Menu Bar or Pop-Up Menu

    The command to replicate an entire menu bar is:

    Similarly, the command to replicate an entire pop-up menu is:

    where from_window_kind and to_window_kind are the server name and, if the server creates more than one kind of window, a period followed by the kind of window.

    These commands are used in the standard menu files as convenient steps in creating new menu bars or pop-up menus that are identical to or slight variants of some previously defined menu bars or pop-up menus. Note that for a given kind of window, its menu bar must be defined before its pop-up menu. For example:

    Defining a Buttonbar

    The buttonbar for a given window kind can be defined in the menus file.

    The command to define a buttonbar is:

    where:

    For example:

    There can be multiple buttonbars for a given window kind. They are assigned a number starting with 1. When more than one buttonbar is specified, menu items are added to the Tools > Button_Bar menu to switch between them. The label strings on those menu items can be specified here. The widget name of the menu item to switch to buttonbar N is buttonBarN.

    For example:

    Creating a Goto Menu

    You can create a goto menu to navigate through the directory system. Clicking on a button in a goto menu visits the associated object.

    To create a custom goto menu that lists your most commonly visited directories and files, place a navigate clause in your menus file. A navigate clause has the following form:

    where the brackets and ellipses do not actually appear in the action clause, but rather represent optional items and the possible repetition of preceding items, respectively.

    You can tailor your navigate clause to place the buttons for each object to be visited:

    Placing Buttons on a New Navigate Submenu

    For example, this navigate clause creates a Go To submenu at the top of the Navigate menu:

    The position —— 0 in the example —— is a nonnegative integer representing the new submenu's place on the Navigate menu. The first menu item is numbered 0, the second menu item is numbered 1, and so on. Omit the position to place the new submenu in the last place on the menu.

    The menu_name —— Goto in the example —— is the simple name of the new goto submenu.

    The menu_label —— "Go To" in the example —— and path_label can be any strings. They must have double quotes if not single words —— that is, if they contain white space. If the menu_label is omitted, the menu_name is used. If a path_label is omitted (as in the example), it is derived from the pathname as shown in Figure 37.

    Figure 37 Go To Submenu

    The optional mnemonic —— The G in Go To in the example —— is a single character that occurs in the menu label string. Each mnemonic on a given menu must be unique —— do not specify a mnemonic that already appears on the menus.

    Each pathname is the full pathname to a directory or file that you commonly visit. Table 16 described the mouse operations defined for each pathname —— that is, each button —— on a goto menu.

    Table 16 Mouse Operations for Pathnames
    Mouse operation
    Result
    Left-click
    Visit pathname
    Shift-left-click
    Visit pathname in place
    Control-left-click
    Visit the directory that encloses pathname
    Shift-Control-left-click
    Visit the directory that encloses pathname in place

    Placing Buttons on a New Menu-Bar Menu

    To place the new goto menu directly on the menu bar, prepend an exclamation mark (!) to the menu_name. For example:

    This adds a Go menu as the fifth item on the menu bar as illustrated in Figure 38.

    Figure 38 Go Menu

    Placing Buttons Directly on the Navigate Menu

    To place the buttons directly on the Navigate menu instead of on a submenu, omit the position, menu_name, menu_label, and mnemonic from the navigate clause.

    For example:

    This places the buttons at the bottom of the Navigate menu as illustrated in Figure 39.

    Figure 39 Updated Navigate Menu


    Aliases

    Another mechanism for facilitating directory traversal is aliases. This mechanism allows you to specify short names which map to full pathnames. These short names can be used in the Open dialog box and in visit commands from the shell. Aliases are placed in the $HOME/.Rational/direcotry_rules file.

    An aliases clause is:

    where:

    For example:

    You can use the short_name (that is, tut) in the Open dialog box or in an Apex xterm, you can enter visit tut.


    Action Clauses

    The commands that create new menu items —— append, insert, replace_all —— cause the new menu items to appear on your Apex windows. To associate an action with each new menu item, place action clauses anywhere after the definitions of menu items in your menu files. You can also use action clauses to override the default semantics for predefined menu items.

    Note: Some of the predefined menu items on the editor windows —— for example, those for Apex/Summit commands —— actually call the directory server to display a dialog box. Changing those items in the directory server changes them for all windows.

    An action clause has the following form:

    where the brackets and ellipses do not actually appear in the action clause, but rather represent optional items and the possible repetition of preceding items, respectively. For example:

    Action Clause Files

    The action clauses can also be placed in a separate file from the menu items. This file is called server_name_rules", for example, directory_rules, and would be placed in the $HOME/.Rational directory As with the menu files, there can be a sequence of these files which are found using the APEX_RULES_PATH session switch.If this is not set, then the APEX_MENUS_PATH session switch is used.

    The rules files can be reread while the server is running, allowing testing and modification of actions without killing the server. To change the structure of menus it is still necessary to restart the server.

    In the Rational local directory menus there is a menu item called Navigate > rules > Reread_Rules which rereads the "directory_rules" files. The Navigate > rules > User_Rules command will visit the user's directory_rules file.

    The rule's files for servers can be reread by the shell command

    If the editor option is not given, the directory editor is used.

    In addition to being used for new menu items, action clauses can also be given to override the default semantics for predefined menu items.

    Action Names and Modifiers

    The action_name can be either a simple menu item name (for example, checkOut) or a simple menu item name qualified by the window kind (for example, directory.imports.checkOut).

    The action name can be preceded by one or more of these modifiers: shift, control, and mod1. If modifiers are specified, the action clause is run only when those modifiers are pressed on the keyboard while clicking on the menu item. Thus, you can specify different semantics for menuItem, Shift-menuItem, Control-menuItem, Meta-menuItem, Shift-Control-menuItem, and so on.

    You can specify more than one action name in an action clause, and the action clause will apply to each of them. For example:

    In this case, modifiers apply only to the immediately following action name. For example, shift applies to myCommand5 but not myCommand6 above.

    You can use a special action name, doubleClick, to change the semantics associated with double-clicking the mouse in directory windows.

    The action:

    can be given to define an action which will be invoked just before a window of the given kind is closed.

    Object Kinds

    You can further qualify actions in directory windows that redefine built-in operations by an object_kind clause, which restricts the action clause to run only when objects of the specified kind are selected in the window. An object_kind clause has the following form:

    where:

    Object kind clauses are described in Table 17.

    Table 17 Object Kind Clauses
    Object-kind clause
    Interpretation
    file *.cfg
    Any configuration file
    file %~X *
    Any file that is not executable
    file %RW *
    Any readable and writable file
    directory *.wrk *.rel
    Any view (Apex/Summit)
    directory not *.rss
    Any directory that is not a Rational subsystem (Apex/ClearCase)
    directory not *.ss
    Any directory that is not a subsystem (Apex/Summit)

    For example, if there is a local convention that all FrameMaker documents have the .doc extension, then a special visit action for them could be defined as:

    Option Names and Values

    If the second line of an action clause begins with the keyword options, the rest of the items on that line are taken as option specifications. An option_specification has the following form:

    Table 18 lists supported options. Note that case (upper versus lower) is not significant in option names.

    Table 18 Menu Options
    Option specification
    Interpretation
    Message_Window
    Redirect output to the Apex message window.
    Output_Window
    Redirect output to an Apex output window.
    Title string
    Redirect output to an Apex output window with the given title. This title will also be used when the action appears in the Apex Jobs window. This option must be the last option in the option specification.
    Xterm
    Redirect input and output from/to an xterm window.
    File_Input filename
    Redirects input of the action from a file
    File_Output filename
    Redirect output of the action to a file
    Null_Input
    Redirect input from /dev/null.
    Null_Output
    Redirect output to /dev/null.
    Machine
    Names the machine or architecture kind on which to run this action
    Context
    Specifies the directory context in which this action should run
    Shell
    Names the shell to use for this action
    No_Register
    Do not list this action in the Jobs window.
    No_Shell
    For scripts that consist of a single line containing no special shell metacharacters, this option will cause the script to be directly forked and executed without first forking a shell to do the execution. This is purely a performance option.
    Retain_Busy
    Display the watch cursor in the window from which the action was started. The script in the action must turn off the watch cursor before the action terminates. The command to turn off the watch cursor is:
    No_Command_Server
    Specifies that this action is not to be in a command_server
    No_Interpret
    Specifies that the apex_display actions are not to be interpreted.

    If no output option is specified, any output produced by the action will go to the standard output of the server that started the action. This usually means that you will not see the output; it is effectively lost.

    Scripts

    The script in an action can be any shell script, and it can span multiple lines. By default, the C shell (csh) is used to execute the script. You can specify a different shell by inserting this command in your file:

    This command changes the default shell for all succeeding actions in your file to shell_name. For example, you might specify the Bourne shell with:

    You can put more than one shell shell_name command in your file, allowing you to use different shells for different actions.

    If the script is a single line beginning with either visit or apex_display, the script will not be run as a separate job, but will instead be executed directly by the server. This can lead to significant performance improvements for such scripts. These scripts should not have any shell metacharacters in them.

    The script can begin with one (or more) lines which start with the keyword, perform, followed by an operation name, and optionally arguments.

    These perform commands will be directly interpreted by the server before the rest of the action (if any) is executed.

    For example, we have a local code item on text file menus which looks like:

    The perform save line causes the file to be saved before the code action starts.

    Another example is:

    This redefines the double click operation in directory windows when done on subdirectory lines to expand them in place rather than creating a new window.

    Prompts

    The script in an action can contain prompts to refer to the objects on which the script operates. Before the script is executed, the prompts are textually replaced with filenames, and so on, depending on the particular prompt. For prompts that refer to a set of objects, the replacement string consists of a sequence of tokens, each separated by one space. The Title option can also contain prompts.

    For example, an action clause for a menu item defined in directory-viewer windows could be similar to:

    The <SELECTION> prompt is replaced by the full pathnames of all objects that are selected in the given window.

    As another example:

    All occurrences of the <FILES> prompt are replaced by the full pathnames of any files that are selected in the given window.

    Table 19 alphabetically lists supported prompts and the kinds of windows in which they can be used.

    Table 19 Menu Customization Prompts
    Prompt
    Description
    In
    windows

    <ACTION>
    Name of the action.
    Directory
    <ADA_NAME>
    Full Ada name of the Ada item at the current cursor position —— for example: PKG.PROC.VAR.
    Ada
    <ALIAS_KEY>
    Unique handle that identifies this window; for a file or directory, its full pathname.
    All
    <ALL_DIRECTORIES>
    Full pathnames of the directories (and views, but not files) selected in all directory windows.
    Directory
    <ALL_FILES>
    Full pathnames of the files (not directories or views) selected in all directory windows.
    Directory
    <ALL_JOB_HANDLES>
    List of machine name and process ID pairs for all jobs in this window.
    Jobs, Servers
    <ALL_SELECTED_OBJECTS>
    Like <SELECTED_OBJECTS> but in all directory type windows
    Directory
    <ALL_SELECTIONS>
    Full pathnames of the objects —— both files and directories (and views) —— selected in all directory windows.
    Directory
    <ALL_VIEWS>
    Full pathnames of the views selected in all directory windows.
    Directory
    <ARCHITECTURE>
    Architecture of the machine the server is running on
    All
    <ASSOCIATED_PATHNAMES>
    For a non-filesystem object, the filesystem object associated with it (if any). For a filesystem object, its pathname.
    Directory
    <BASENAME>
    Simple name of the current object.
    Ada (Ada only), Text
    <BASENAMES>
    Basenames of the objects selected in this window.
    Directory
    <COMPILER_KEY>
    Compiler key of the context of this window
    All
    <CONTEXT>
    Full pathname of the directory context associated with this window.
    All
    <CONTEXT_ARCHITECTURE>
    Architecture of the context of this window or server architecture if no architecture is implied by the context.
    All
    <CONTEXT_RELATIVE_NAMES>
    Context-relative pathnames of the objects selected in this window.
    Directory
    <DIRECTORIES>
    Full pathnames of the directories (and views, but not files) selected in this window.
    Directory
    <EDITOR_NAME>
    Name of the editor.
    All
    <ENCLOSING>
    Full pathname of the directory that encloses <CONTEXT>.
    All
    <ENCLOSING_PATHNAME>
    Full pathname of the file to which the Enclosing command, invoked at the current cursor location, would go.
    Ada
    <ENCLOSING_PART_NODE>
    number of the node which the enclosing operation at the current cursor would go to.
    Ada
    <ENCLOSING_SUBSYSTEM>
    Full pathname of the subsystem that encloses <CONTEXT>, or <CONTEXT> if <CONTEXT> is a subsystem.
    All
    <ENCLOSING_VIEW> (Apex/Summit)
    Full pathname of the view that encloses <CONTEXT>, or <CONTEXT> if <CONTEXT> is a view.
    All
    <ENCLOSING_VIEW_NAMES> (Apex/Summit)
    The enclosing view of the selected object. If the object is a view, it returns its path.
    Directory
    <ENCLOSING_VIEW_OR_CONTEXT> (Apex/Summit)
    If this window is a view or is in a view, then <ENCLOSING_VIEW>; otherwise <CONTEXT>.
    Directory
    <FILES>
    Full pathnames of the files (not directories or views) selected in this window.
    Directory
    <GEOMETRY>
    X geometry string of this window (wxh+x+y)
    All
    <GEOMETRY_X_Y>
    Position of this window (+x+y)
    All
    <GEOMETRY_VALUES>
    Geometry values as (w h x y)
    All
    <HOLD_NAMES>
    Names of objects in the hold set.
    All
    <HOLD_SET>
    Archive representation of the hold set.
    All
    <HOLD_SET_FULL>
    Tuples of the items in the hold_set: kind_value value_image associated_pathname
    All
    <HOST_ARCHITECTURE>
    Host architecture of the context of this window.
    All
    <IMAGE>
    Text of the image in this window.
    Ada (Ada only), Output, Text
    <ITEM_NAME>
    For the Ada item at the current cursor position, a pair of strings containing the library context name and the full Ada name. The library context is a view for Apex/Summit or a Rational subsystem for Apex/ClearCase. An example for Apex/Summit is: /foo/bar.ss/mum.wrk PKG.PRoC.VAR An example for Apex/ClearCase is: /foo/bar.rss PKG.PROC.VAR
    Ada
    <JOB_HANDLES>
    List of machine name and process ID pairs for all selected jobs or for all jobs if none are selected.
    Jobs, Servers
    <LANGUAGE>
    Language of the context of this window
    All
    <LATEST>
    Full pathname of the last file visited.
    Ada (Ada only), Text
    <LINE_NUMBER>
    Line number of the cursor within the text.
    Ada (Ada only), Output, Text
    <MACHINE_NAME>
    Name of the machine on which the directory server is running.
    Directory
    <MODEL>
    Model of the context of this window
    All
    <MODIFIER_MASK>
    Integer image of the keyboard modifiers.
    Directory
    <MODIFIERS>
    String image of the keyboard modifiers.
    Directory
    <NODE_NUMBER>
    diana node item number of the tree at the current cursor position
    Ada (Ada only)
    <OBJECT>
    Full pathname of the current object.
    Ada (Ada only), Directory, Text
    <OFFSET>
    Character offset of the cursor within the text; the first value is 0.
    Ada (Ada only),Output, Text
    <OTHER_DIRECTORIES>
    Full pathnames of the directories (and views, but not files) selected in all other directory windows.
    Directory
    <OTHER_FILES>
    Full pathnames of the files (not directories or views) selected in all other directory windows.
    Directory
    <OTHER_PART_BODY_PATHNAME>
    Full pathname of the file to which the Other Part command, invoked at the current cursor location, would go.
    Ada (Ada only)
    <OTHER_PART_NODE>
    number of the node which the other_part operation at the current cursor would go to.
    Ada (Ada only)
    <OTHER_SELECTED_OBJECTS>
    Like <SELECTED_OBJECTS> but in other directory type windows
    Directory
    <OTHER_SELECTIONS>
    Full pathnames of the objects —— both files and directories (and views) —— selected in all other directory windows.
    Directory
    <OTHER_VIEWS>
    Full pathnames of the views selected in all other directory windows.
    Directory
    <POSITION>
    Line number and column number of the cursor within the text.
    Ada (Ada only), Output, Text
    <PREVIOUS>
    Full pathname of the next to last file visited.
    Ada (Ada only) Text
    <PRIMARY_SELECTION>
    Text of the Motif selection in this window.
    Ada (Ada only), Output, Text
    <SELECTED_JOB_HANDLES>
    List of machine name and process ID pairs for all selected jobs.
    Jobs, Servers
    <SELECTED_LINES>
    Line numbers of the selected lines separated by spaces.
    Directory
    <SELECTED_OBJECTS>
    Selected items including non filesystem objects in this window. For filesystem objects the full pathname will be given. For other objects, an n-tuple consisting of a qualifying word and a sequence of tokens, for example, "history /foo/bar.ss history_name", "element /foo/bar.ss element_name history_name", "version /foo/bar.ss element_name history_name 17", "export_set /foo/bar.ss/view.wrk eset_name"
    Directory
    <SELECTED_SERVER_HANDLES
    List of server handles for all selected servers.
    Jobs, Servers
    <SELECTED_TEXT>
    Text of the selected lines with embedded new lines.
    Directory
    <SELECTION>
    Full pathnames of the objects —— both files and directories (and views) —— selected in this window.
    Directory
    <SELECTION_OR_ALL>
    If a selection is present then that, otherwise all object
    Directory
    <SELECTION_OR_CONTEXT>
    If a selection is present in this window, then <SELECTION>; otherwise <CONTEXT>.
    Directory
    <SELECTION_OR_CONTEXT_ARCHITECTURE
    Architecture of the first selected item or of the <CONTEXT> if no selection
    Directory
    <SERVER_NAME>
    Simple name of the server running this action
    All
    <SERVER_PATHNAME>
    Pathname of the server running this action
    All
    <STORAGE>
    Storage of the context of this window
    All
    <TARGET_ARCHITECTURE>
    Target architecture of the context of this window
    All
    <VIEW_KIND> (Apex/Summit)
    View kind of the context of this window
    All
    <VIEW_RELATIVE_NAMES> (Apex/Summit)
    View-relative pathnames of the objects selected in this window.
    Directory
    <VIEWS> (Apex/Summit)
    Full pathnames of the views selected in this window.
    Directory
    <VISIT_BODY_PATHNAME>
    Full pathname of the file to which the Visit Body command, invoked at the current cursor location, would go.
    Ada (Ada only)
    <VISIT_BODY_NODE>
    The number of the node which the visit body operation at the current cursor would go to.
    Ada (Ada only)
    <VISIT_NODE>
    The number of the node which the visit operation at the current cursor would go to.
    Ada (Ada only)
    <VISIT_PATHNAME>
    Full pathname of the file to which the Visit command, invoked at the current cursor location, would go.
    Ada (Ada only)
    <WINDOW_KIND>
    Window kind of this window.
    All


    Creating a Graphical Menu Item

    A graphical menu item only shows its graphical form when it is placed on the button bar. The menu item uses the label string provided when it is displayed a pulldown or popup menu.

    The command to create a graphical menu item is:

    where

    action
    Append, replace, or insert position (see previous sections)
    name
    Menu item name of the form described in Menu Item Names
    label
    Label string which will appear when the menu item is displayed in the menu bar
    mnemonic
    Single character that occurs in the label. It is optional. If it is not desired, define this character as `-'.
    pixmap
    Name of the pixmap file which will be used when the menu item is displayed on the button bar. The only format currently supported for this file is xwd.

    Assigning a Pixmap to an Existing Menu Item

    You can assign a pixmap to an existing menu item with the syntax:

    where

    name
    Menu item name of the form described in Menu Item Names
    pixmap
    Name of the pixmap file which will be used when the menu item is displayed on the button bar. The only format currently supported for this file is xwd.

    Note: If a menu item occurs on a popup menu, you need to assign the pixmap to the popup menu item to get the pixmap to take effect. For example, if you want to change the menu item name expand in the jobs window using

    This does not work, because the expand name also occurs on a popup menu as the name "jobs.popupmenu.expand". What you need to do for the pixmap to take effect is the following:


  • Rational Software Corporation 
    http://www.rational.com
    support@rational.com
    techpubs@rational.com
    Copyright © 1993-2002, Rational Software Corporation. All rights reserved.
    TOC PREV NEXT INDEX DOC LIST MASTER INDEX TECHNOTES APEX TIPS