Product
Support
Everything Else
Technote R6153: Button Naming Precedence in Helix 6.2
Introduction

In Classic Helix a rather convoluted route taken to determine the name (and name-related attributes) of a button, resulted in seemingly logical choices not working as expected. In Helix 6.2 the naming order is streamlined and open for more useful features in the future.

This technote details the rules that govern the naming of buttons (aka: command rectangles) in Helix 6.2 and later.

Order of Precedence

In Helix, a button’s name is taken from one of five places. In order of precedence:

  1. The text typed into the when invalid, dim with name field when an abacus controls the button enabling and the abacus returns undefined.
  2. The text returned from the controlling abacus when Use Abacus Output is selected.
  3. The text typed directly into the command rectangle on the template, or into the Button Name field in the command rectangle attributes dialog box.
  4. The primary sequence’s custom name.
  5. The primary sequence’s icon name.

In Helix 6.2, this naming hierarchy is always traversed until a name is found or the options are exhausted. In Classic Helix it is possible to have a situation where a button name was blank. Helix avoids this by following a simple rule: if no name is found at the first level, the next level is checked. This checking now walks the entire hierarchy until a name is found.

If you actually want a button displayed with no name, name it with two or more spaces. (See Special Case Attributes below.)

Special Case Attributes

Special case attributes are available to command rectangles containing plain text. They are not applied when the label is styled text or a graphic.

The special cases are:

  1. The name is a single space: This creates a transparent button
  2. The abacus or field specified in conjunction with the Use Abacus Output attribute returns undefined: The button is disabled (dimmed) and the name is taken from the when invalid, dim with name field.

Helix is now completely consistent in the application of these rules. Unlike Classic Helix, the special cases apply regardless of how the button name is acquired. For example, in Classic Helix , the “single space” rule was only applied if the space was typed into the command rectangle; None of the other rules was considered.

Specific Changes

Because Classic Helix is not being modified to follow the new naming rules, there are specific cases where button names differ between Classic and macOS versions of Helix. Some situations where this may be seen are:

The first command in the primary sequence is not enabled (i.e.: Find First on a list) and the When Invalid attribute is Make Button Invisible or Dim Button With Name text is specified.
In Classic Helix the button is diabled and contains the name of the sequence. In macOS, the button is disabled and, following the order of precedence, is named (or hidden) according to the When Invalid specification.
Use Abacus Output is selected, the abacus returns undefined, and the When Invalid, Dim Button With Name text is empty.
In Classic Helix the button is disabled and has no name. In macOS, the button is disabled and the name is taken from options 3–5 (above).
The output of Use Abacus Output or When Invalid, Dim Button With Name is a single space. Or the button rectangle has no name and the primary sequence’s name is a single space.
In Classic Helix the button name is a single space, appearing empty. In macOS, the button becomes transparent, as per the single space specification.

There may also be other situations where the results differ, but all should follow the naming precedence rules outlined above.

Classic Bugs Not Fixed

With few exceptions, bugs that were discovered in Classic Helix have not been addressed. We do not plan on addressing subtle Classic bugs such as these.

For example: when setting up button naming and enabling in RADE, you can specify whether the name and enabling info comes from a field or an abacus. There is a subtle bug in Classic Helix when a field is specified: the value typed into the field does not pass through to the button until the record is actually entered. This is fixed in macOS: the field value passes through to the button as soon as you de-focus (tab or click out of) the field.

Future Direction

The macOS code has been written specfically to allow us to extend these new conventions to buttons containing styled text and graphics, to add greater control to the naming of the disabled button, and more.