1. General Characteristics and Properties

The property sheets of controller objects are not quite as uniform as those of monitors. Therefore, there are only a few characteristics and properties general enough to be discussed in this section. For characteristics and properties common to all objects, see Property Sheets in Chapter 4 .

1.1. Creating Controllers

All controllers are found in the same submenu of the Create menu. Figure 7-1 shows this submenu with options for the eleven types of controllers:

: 1. Valuators
: 2. Text-entry objects
: 3. Choice buttons
: 4. Message buttons
: 5. Menus
: 6. File-selection menus
: 7. Related display callups
: 8. Execute script objects
: 9. Kill display objects
: 10. Toggle button
: 11. Print display
: 12. Print options

Controller Submenu

To create a controller:

: 1. Bring up the controller submenu and choose the option for the type of controller you want to create.
: 2. The same thing occurs as when you create any other type of object: the mouse's pointer appears as a tiny box with a dot in the middle and as you move the mouse, a rectangular outline consisting of dashes appears and expands as you move the mouse.
: 3. Move the mouse until the object takes on the desired shape and form.

As with all other objects, you can change the size and position more precisely by changing the size and position properties in the controllers's property sheet.

Controller objects inherit the following defaults from the Display Attributes window:

Controllers inherit both the 'background and foreground color' attributes from the attributes window, and they have 'foreground and background color' properties with which you can override these defaults.

Controllers inherit the 'default color modifier' attribute, so their color modifier properties will be set to static if the default attribute is set to static, and rule if the attribute is set to rule.

Controllers inherit the color rule in the 'default color rule' attribute, regardless of whether the default color modifier is set to static or rule.

Controllers inherit the 'default channel name' attribute, just as any other type of object does.

Controllers have no 'edge and fill style' properties, so they cannot inherit these from the attributes window. At run-time, controllers, like monitors and plots, always have a solid border and are always filled solidly. Controllers do not take on their full appearance until they are connected to channels at run-time.

1.2. Property Sheets

Each controller has several properties in their property sheets that are common to all objects, properties like 'horizontal and vertical size,' 'horizontal and vertical position,' 'color modifier,' and 'color rule' arguments. See Chapter 4, Creating and Manipulating Objects, for more information on how to configure these properties. This section instead covers the general properties unique to controllers. The section on each controller discusses any properties unique to it.

There are nine properties we will discuss here:

: 1. channel to control or monitor
: 2. foreground color
: 3. background color
: 4. label type
: 5. high display limit
: 6. low display limit
: 7. precision
: 8. specify new units
: 9. units modifier
: 10. 3-D Border
: 11. conversion
: 12. conversion params

The 'specify new units', 'conversion' and 'conversion params' properties have not yet been implemented, so they have no significance for any controller. As for the rest of these properties, not all are significant for every type.

Figure 7-3 shows the property sheet for a valuator.

1.2.1. Channel To Control or Monitor

Some controllers that don't actually connect to channels such as execute script and kill display objects lack this property. The other controllers (valuators, text entry objects, choice and message buttons, and menus) all have this property, and a channel name must be specified in it.

Remember from the introduction that the term channel can refer to any record or any record's field in an EPICS database that is accessible via Channel Access. However, since Channel Access was untied from the EPICS database, DM can now monitor and control non-EPICS process variables. Therefore, how you specify a channel name depends on the context you are working. The main thing to remember is that channel names are case sensitive. Also, remember that DM passes to Channel Access the entire name string, including spaces.

Below follows a description of EPICS record names. Though EPICS-specific, it should help even those working with non-EPICS process variables.

Basically, the format for a channel name is the record's name in the database and then the field name. These elements are separated by a period. In addition, the record name may consist of several elements, identifying which database or subsystem it belongs to, as well as the record's particular name within that subsystem or database. However, record naming conventions vary from project to project and from site to site. An example of a channel name might resemble the following:

demo:ao1.SEVR

Demo:ao1 is a record's name in a database. Demo is an element of a record name that identifies it as a record in a certain database, in this case the demo database. Ao1 is the record's unique name. Record names must be unique for the same TCP/IP subnet. SEVR, on the other hand, refers to a field name in an EPICS record.

Any channel name must consist of at least a record name. A field name is optional because DM will automatically connect to the VAL field of a channel when no field name is specified as part of the channel name. This goes for channel names with macros. If you do specify the VAL field in a channel name, DM will still connect to the VAL field.

In EDD you can use macros that you can replace at run-time by a real channel name when you run DM. You would do this when you want to use one or more objects in a display to connect to different channels. Instead of specifying specific names of records in specific databases, you can use macros. Thus, the following channel name in the 'channel to control or monitor' property,

$(chan).SEVR

could be used to monitor or control the SEVR field for any EPICS record that contains such a field. All you have to do is expand the macro into a real channel name. The dollar sign and parentheses are characters that DM recognizes as containing a macro, the macro string being any string of characters. For example, chan in the above example could be channel or name or channame1 or whatever.

Macros can also be nested; that is, a macro can be placed within another macro. So, for instance, you could use two macros, one within the other, in place of two elements in a record name. An example of nested macros would be:

$(system_name$(subsystem_name).OMSL

See Chapter 9, DM: Run-time Operation, for information about replacing macros at run-time.

1.2.2. Foreground and Background Colors

Like monitors, controllers have two color properties that they inherit from the Display Attributes window: 'foreground color and background color.' You can override these inherited colors simply by changing them in the controller's property sheet. Simply hold down the right mouse button on the color property to bring up the color menu. Then choose the color you want.

The background color is the static part of the monitor; that is, it is the color of the object's background. All values and text are in the foreground color, so anything in the foreground color displays the actual values and text that are meaningful at run-time.

Keep in mind that the colors of these properties may be overridden at run-time when the object's 'color modifier' property is set to rule. When a color rule modifies an controller's color, if the conditions in the expressions of the color rule exist, the foreground color of the controller will turn to the color specified by the color rule. See Color Rules in Chapter 3 for more about color rules and how they affect objects.

When a dynamic object fails to connect to a channel at run-time, for whatever reason, the object will be white and will show an error message.

1.2.3. Precision

The 'precision' property is only available as of EDD/DM version 2.3 and only applies to valuators. Prior versions have this property, but it has no effect on the run-time behavior of the object. For versions 2.3 and later, when a number from 0 through 20 is entered in this field, the valuator will use this number at run-time to determine the decimal precision with which to display the value of the channel. If 0, only the integral part of the channel's value is displayed.

When a number less than zero is entered into this property, the precision will be determined by the database. Often, the precision is retrieved from the PREC field, or else a global record support routine returns the value for the precision. The precision may be different for different fields in the same record. For versions of EDD/DM prior to 2.3, this is always how the precision is determined. Be aware that the precision affects all numerical values that the object displays, even the display limits.

1.2.4. Specify New Units

Not yet implemented.

1.2.5. Units Modifier

This property applies to text update monitor objects, not to text entry objects or any other controller objects.

1.2.6. 3-D Borders

This property is available as of EDD version 2.2. It contains three options: none, outward, and inward. With the outward and inward options you can configure the controller to appear with a border at run-time that gives the it a three-dimensional appearance. The outward option makes the controller to appear as if it were raised up from the display while the inward option makes it appear as if it were sunken into the display. The none object makes the it appear without any 3-D border.

Note that related display callup objects, execute script objects, and kill display objects do not have a '3-D Borders' property.

Figure 7-2 shows three different objects, one without a 3-D border and the other two with each type of 3-D border.

3-D Borders, Run-Time Appearance.