macOS Compatibility Issue

R6903 refers to a bug that was found in Helix 6.1.6 and fixed in Helix 6.1.7. This technote addresses the underlying issue behind this problem.

Sequences that contain commands that “play the interface*” can behave unpredictably. The underlying cause of these issues is the ‘multi-threaded’ aspect of macOS, which does user interface actions (menu commands) on one thread, while doing others (e.g. sequence execution) on another. As such a sequence containing a command such as ‘Copy’ will sometimes attempt to execute that step before the user interface is ready, resulting in an error because the Copy command is not yet enabled in the menu.

These failures are often inconsistent and difficult to reproduce. This is most pronounced in Helix Client/Server, where delays introduced by network latency or processing backlog add complexity.

* By “play the interface,” we refer to commands that mimic the actions a user can do to manipulate data on the screen, particularly at the field level, but also at the record level.

In the macOS world, mimicking user actions via a sequence is, in general, a bad idea. Helix has historically supported (and continues to support) these user actions:

Field Level Actions:

• Clear
• Copy
• Cut
• Home Field
• Paste
• Tab Field
• Time Stamp

Record Level Actions:

• Clear Form
• Clear Selection
• Close
• Delete
• Enter (including Static Enter, Enter Override, Static Enter Override)
• Find {First, Next, Previous, Last}
• Keypress Enter
• Open (a view)
• Print

Sequences that use these commands have the potential for error. In macOS, Helix runs multiple processes concurrently (multithreading), and there are times when a field is not yet ready for an action that depends upon it. In situation such as these, a sequence that relies on direct field or record manipulation may report an error, or it may silently fail.

Although there is no perfect solution, the best approach is to insert a Draw Screen command after ‘interface’ steps in a sequence. Any step that can cause a screen redraw is a candidate. The Draw Screen command tells Helix to explicitly wait until every window has been completely drawn and is ‘quiescent’ (idle) before going on to the next step. This forced delay compensates for network latency before going on the next step. (An AppleScript that can insert/remove Draw Screen commands where needed is available on our free AppleScripts page.)

Another set of issues relates to enhanced OS-level capabilities — such as Full Keyboard Access — that are completely outside the control of the Helix collection designer. With no way of preventing the user from (accidentally or intentionally) modifying the interface, sequences that rely on Home Field/Tab Field commands to step through fields (i.e: “playing the interface”) in a specific order may fail.

Deprecated functionality is also an issue. For example, running under the Classic Mac OS, Helix can cut, copy, paste, or clear a value in a control object (i.e: radio button, checkbox, popup menu). macOS provides no such support, directly limiting Helix in this area. Of course, it is possible that a future revision of macOS will restore the Classic capability, but the larger point remains: relying on interface behavior to remain constant is not the best course of action.

Although there are instances where manipulating the interface is the only viable solution, we strongly encourage collection designers to look for alternative methods that avoid “playing the interface” to accomplish the tasks at hand. Posting — particularly in conjunction with a user-based global relation — is a better method of moving data from one record to another.