The login process has been completely rewritten. Instead of two dialogs, a first one for entering the User Name and a second one for entering the User Password, there is now a single Authentication dialog that handles both. This enhances the security of Helix, as it prevents a user from guessing at the User Name and Password is separate steps. (When either of them is incorrect, Helix returns an error that merely indicates that something is not right. The attacker will not know if it is the User Name or Password they are guessing incorrectly.)

If you do not use passwords in your collection, simply leave the Password field blank when logging in.

Also, when User Name Security is off, users are presented in a popup list instead of a scrolling list box.

Helix Border rectangles are drawn as OS X Group Boxes. This gives them rounded corners, a shaded background, and a subtle 3-D appearance.

Nested group boxes take on increasingly darker shades of the background color, so rectangles within a group box may look odd if their background color does not match the group box color.

To create Helix colors to match the nested group box background shades on a white background in OS X 10.4, use these the HTML picker with Web Safe Colors turned off, and set all three fields to these values:

1. F7 (247 or 96.9%)
2. EF (239 or 93.7%)
3. E7 (231 or 90.6%)
4. DF (223 or 87.5%)
5. D8 (216 or 84.7%)

A framed data rectangles containing Radio Buttons are also drawn as an OS X Group Box. The shades are the same as for border rectangles.

Framed data rectangles in OS X always use the OS X 3D appearance. Colors specified for data rectangle frames are ignored.

Framed text label rectangles in OS X always use the OS X 3D appearance. Colors specified for text label rectangle frames are ignored.

The Helix Reference (4.7.3.1) does not explicitly define what should happen when there is a default button on a view and the user selects the Enter menu item. It only notes that if you remove Enter from the menu you must make Enter available in a sequence (button) on the view to enter the record. OS X Helix clarifies that condition.

Helix has many variations on what Enter means, depending on what the collection designer created. When you press the Enter key on the keyboard, Helix can: Enter a record, Replace a record, trigger a default button, or accept dialog box input. If a user holds the option key down while pressing the Enter key, Helix can either Enter/Replace the record and keep it displayed on screen or trigger the default button and show all dialogs the sequence can present, assuming ‘Optionally Show Dialogs’ is set for that sequence. (Holding the option key down while dismissing a dialog does nothing special.)

However, when you select Enter from a menu in Classic Helix, it means just one thing: Enter a record. The Enter command on a menu changes to Replace when you are replacing a record. Holding the option key down stores the record and keeps it displayed on screen. The collection designer can also place Enter Override & Static Enter Override directly on user menus.

OS X Helix changes to the way the three Enter commands work when selected from a menu: selecting any of these menu commands is now handled exactly the same as pressing the Enter key. This only changes what happens if there is a default button on the view when a Enter menu item is selected. In Classic Helix, selecting any of the Enter commands from the menu bypasses the default button and simply enters the record. In OS X Helix, selecting any of the enter commands triggers the default button. Selecting Enter from the menu while holding the option key down (or selecting Static Enter Override from the menu) triggers the button and honors the ‘Optionally Show Dialogs’ sequence settings.

Note: this does not mean that the behavior of an Enter command within a sequence also takes on this behavior. That command (which will be renamed ‘Enter Record’ in the future to provide clarification) continues to simply enter the record on screen. Use the sequence command Keypress: Enter to simulate a keypress/menu selection Enter when needed.

A common design technique is to create a default button on a view specifically to intercept the Enter command and initiate a sequence instead of performing a simple enter/replace record command. Giving the user the ability to circumvent this via the menu command is a loophole that can be guarded against, but one that becomes an increasingly arduous and time-consuming process as a collection grows in complexity. This change resolves that problem.

In prior versions of Helix, the Why? message that an error produces lasts only until the next operation is done. If you do not check the message immediately, it is lost.

In Helix 6.1 Classic and OS X products, the most recent Why? message remains available until a new error replaces it.

Upon opening a collection, the initial Why? message reads “The collection is open and ready for use.”

It is still possible to remove the Why? menu item from a user’s menus, making it impossible for them to check the error messages. This is strongly discouraged as it leaves an application that can beep for no reason apparent to the end user.

Views now use the OS X native controls, so keyboard controls for cursor movement and text selection work according to Apple’s Human Interface Guidelines.

In Classic Helix, an empty data rectangle with the ‘underline’ attribute draws the underline across the full width of the rectangle. In OS X Helix, MLTE only underlines actual text, so no underline is shown when the rectangle is empty.

In Classic Helix defaulted and invalid fields were overlaid with a dot pattern to indicate the default or invalid nature of the data shown. In OS X Helix, defaulted and invalid fields are shaded with color (light green for defaults, light red for invalid data). These colors can be changed by editing their preferences: HxDefaultBackgroundColor & HxInvalidBackgroundColor.

For more information on default and invalid field shading, see this technote.

In Classic Helix a button can be disabled based on the output of an abacus. The disabling can be by dimming or by making it invisible. However, the "invisible" option is ignored in cases where the button is disabled because the first command is illegal.

OS X Helix always honors the designer’s specification for disabling a button, regardless of the reason it is to be disabled.

In Classic Helix, pressing the escape key within an active field on an entry view clears the text from that field. In OS X Helix the escape key removes the focus from all fields.

The Quick Query is now found in the OS X toolbar. (Click the widget in the upper right corner of the view.) Whenever the toolbar is open the quick query is active and must be filled in in order to find records.

All fields in data rectangles that have the ‘Allow Query’ attribute set appear in the query popup. The order of the entries in the popup is the same as the tab order on the view.

To cancel the Quick Query, close the toolbar. (Click the widget in the upper right corner of the view.)

In Classic Helix, canceling a Quick Query after finding a record also disables the Find Next/Previous commands if and only if there is also a From Query attached to the view. In OS X Helix Find Next/Previous are always enabled when a stored record is shown.

In Classic Helix, pressing the Enter key after specifying a Quick Query performs a ‘Find First’ (as does pressing Tab or Return). In OS X Helix, the Enter key actually enters the record currently shown on the view. Use the Tab key (or Find First) to find the first matching record after specifying a Quick Query.

The Sort Order dialog is now found in an OS X standard toolbar. The toolbar can be open at all times, showing the current sort order. To re-sort the list, simply select a new sort from the popup menu. The default sort order is indicated by the index listed in bold italic typeface.

A button (or sequence) containing the Sort Order command toggles the toolbar when clicked: if the toolbar is closed, running a sequence with the Sort Order command in it will open the toolbar when the command executes. Likewise, if the toolbar is open, it will be closed.

In Classic Helix the Sort Order is always enabled and can be opened from any list view, regardless of the number of indexes available. This could result in the user seeing a dialog offer zero or one choices. OS X Helix enables the Sort Order command only when two or more indexes are selected.

Changing Sort Order from a modal dialog into a toolbar option results in a critical spec change: a sequence containing a Sort Order command will no longer pause until the user chooses a sort order. When the step executes the toolbar opens (or closes) and the sequence continues immediately.

Sort Order is only available on Document type views (views with a drag bar). Plain and Invisible view types are no longer able to display the Sort Order dialog.

User Interface elements provided by OS X — buttons (command rectangles), checkboxes, popup menus, radio buttons — no longer support non-standard sizes, colors, or fonts now. Only the fonts and sizes provided by the OS are available. In OS X 10.4 (Tiger) all UI controls use Lucida Grande.

In views, the shape of a button is now taken from the system definition for bevel buttons not the (standard) push buttons. The standard push button is used in dialogs.

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 OS X Helix the naming order is streamlined and open for more useful features in the future.

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 enablement 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 button (or into the Button Name field)
4. The primary sequence’s custom name
5. The primary sequence’s icon name

In OS X Helix, 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. OS X 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 an button displayed with no name, name it with two or more spaces (or make sure everything in the hierarchy — including the primary sequence itself — has no name).

Special case attributes are available to buttons whose contents are text only. (These can not be applied to buttons containing styled text or a graphic.):

1. A button with a single space name (direct input only) creates a transparent button
2. When Use Abacus Output returns undefined, the button is dimmed and the name is taken from the when invalid, dim with name field.

The OS X code is more flexible in that the special cases apply regardless of how the button name is acquired. For example, if Use Abacus Output returns a single space, or the button name is taken from the sequence and the sequence name is a single space, the button is transparent. (The OS X code will also allow us to extend these attributes to buttons containing styled text and graphics, but this will not be implemented until OS X RADE is released, as there is currently no interface for managing such choices.)

Specific places a button name change may be seen in a collection running in OS X Helix:

Use Abacus Output is selected, the abacus returns undefined, and the when invalid, use name text is empty.

In Classic Helix the button is dim and has no name. In OS X Helix, the button is dim and the name is taken from option 3–5 (above).

The output of Use Abacus Output or when invalid, use 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 OS X Helix, the button becomes transparent, as per the single space specification.

AM/PM option removed. Keyboard control of checkboxes. Increment/Decrement thumbs work.

Two-state Radio Buttons can no longer be undefined once they have been defined. If you need to allow undefined as a state, use the three-state radio button instead.

For data rectangles that do not also include an abacus to set the default value, the default remains undefined (neither radio button selected).

For previously entered records where the radio button field is undefined, the field remains undefined (neither radio button selected).

Under OS X, checkboxes have three states:  On, Off, and Indeterminate. An indeterminate checkbox is drawn with a hyphen through it. Helix uses the indeterminate state to indicate an undefined field.

A field formatted as a checkbox containing a default abacus can not be set to undefined, even if the default abacus is undefined. This is because of the way OS X checkboxes are created. If a defaulted field must allow an undefined option, use an alternative format, such as a three-button radio button.

Helix applications will not launch if placed on a "Mac OS Standard" volume. "Mac OS Extended" format is required.

An inconsistent specification for selectable lists has been addressed.

First, the history: In the beginning there were "clickable lists" -- double-click a record in a list and a specified entry view is opened with that record. From there you were free to look at other records on the entry view. Later "selectable lists" were introduced -- highlight multiple records and then perform an action (post, delete, copy, paste-replace, open) on them. Under the hood, Helix creates a selection query containing the selected records. This is why when you select 2 or more records and then open the selection, the entry view will only show the selected records.

Now, the problem: When this was added, it created a conflict with the original "clickable" spec. Originally, double-clicking a record opened the entry view, but "double-click" is a shortcut for "open" so the question was (apparently) asked: when a single record is selected, then opened (aka: double-clicked) should the selection query be created and the entry view restricted to showing just that one record? That would break the expectations of people used to double-clicking a record and then roaming around on the entry view.

The spec that was chosen back then is this: If two or more records are selected, create a selection query and restrict the entry view to just the selected records. If only one record is selected (whether by double-click or by discreet click/open events) no selection query is used.

The big problem with this is when the designer wants to create a sequence such as "Select the records you want to print and click this button to print them" with the idea that a sequence will open the view (designed for printing) and do a "Find and Print All" on the selection. It works great if they select two or more records, but if they select just one record, Find and Print All prints all records available on the view, since no selection query is created. With a "Print Selected" scenario it is annoying; with a "Delete Selected" scenario it is disastrous.

This specification has changed as follows:

A single click, by itself, begins the selection process. The record is 'lightly' highlighted to indicate that the mouse click was registered. If no secondary click (double click) is detected within the required time, the record is 'fully' highlighted, the first click is interpreted as a selection, and the selection query is formed containing just one record. This effectively closes the loophole discussed above while retaining the double-click behavior people are accustomed to.

Likewise, click-drag, shift-click, command-click all add to the selection query and extend the selection. The visual indication that a query has been formed is the highlighted record.

A double-click constitutes an "open" request, and no selection query is formed. This allows old, learned behaviors to continue. The key interface change is that in this case, the feedback for a single click is a light highlighting; if a second click occurs on the record while that light highlighting is in effect, the specified entry view opens. In the case of a selectable list, one click turns into a selection event if there is no secondary click within the designated time span. (Designated by the user's system preference -> mouse -> double click speed setting.)

So in OS X Helix, if the user clicks once, Helix waits for the duration of the double-click speed, and after no secondary click is detected, Helix THEN highlights the record, indicating that a selection query has been formed. Once the query has been formed (as indicated by the highlighting) a subsequent double-click opens the entry view with the query intact.

Click and drag to select records is currently broken.

In Classic Helix: when an entry view is opened from a list, the first field (with allow tab enabled) on the view is selected. In OS X Helix, no field is selected. This change was made to avoid inadvertent write-locking that occurs when accessing an entry view via a list.

When a template is designed to print multiple pages, each printed page now counts as a page in the print dialog. In earlier versions of Helix, the template counted as one page, no matter how many pages were actually printed.

For example, consider a template that prints four pages, used on a list that repeats that template three times. When you ‘Print All,’ 12 pages come out of the printer, no matter which version of Helix is being used. The difference shows up when you specify a page range to print. In Classic Helix, printing ‘From 1 To 1’ prints the first four pages, that being ‘one set’ as defined by the template. In OS X Helix, printing ‘From 1 To 1’ prints only the first (upper left) page of the first set. In Classic Helix, printing ‘From 3 To 3’ prints the four pages from the third repetition of the list. In OS X Helix the true third page — page 3 of the first set — is printed. To print the ‘third set’ in OS X Helix, you would print ‘From 9 to 12’.

Simply put, you have more control over exactly which pages are printed.

In Classic Helix pressing CMD-up arrow or CMD-down arrow while editing a field would tab to the next or previous field, respectively. In OS X Helix, CMD-up arrow moves the cursor to the beginning of that field's text. Likewise, CMD-down arrow moves the cursor to the end of that field's text.

Helix uses Apple’s help system to allow administrators and developers to add Custom Help to their installations. Apple’s help system uses html formatted pages, so anybody with skill in creating web sites can create informative custom help for their collections. For more information on creating help pages, see http://developer.apple.com/ue/help/.

When a collection is opened, Helix looks for a file named index.html in a folder named CustomHelp (no space between the words) in the same folder as the collection. If that file is found, the Custom Help menu command is activated. When Custom Help is selected from the Help menu, Apple’s Help Viewer application is launched and the index.html page is displayed.

The location and name of the default file can be modified via a preference setting.

Classic Helix has always allowed a user to control checkboxes and radio buttons from the keyboard — even though the OS itself did not provide such a feature. When a checkbox/radio button has focus in Classic Helix, you can use the arrow keys and the various true/false values (1/0, T/F, Y/N, and any specified custom values) to toggle those controls. Pressing the delete key while in a control sets it to undefined.

OS X provides a mechanism known as Full Keyboard Access to allow keyboard control of all interface elements: checkboxes, radio buttons, popup lists, buttons, etc.

OS X Help for full keyboard access says: “… With full keyboard access, you use the Tab key, arrow keys, and space bar to move to and select or activate items on the screen … You can use your keyboard to select … items in windows and dialogs. Selected items are highlighted. You can specify whether you want to use the keyboard to select only text boxes and lists in a window, or all the controls in the window …”

These two specifications are similar in some respects, and differ in others. In OS X, Helix will support what the OS itself supports. The Helix features that are not supported will not be supported.

In Classic Helix it is possible to copy a document from one field and paste it into another. This bit of clipboard sleight of hand will not be brought forward to OS X Helix.

The Edit Users command has been renamed Edit User List to clarify what its actual function is.

Attempting to do certain actions (see list below) in a view that has an edited but not yet entered record on it brings up the Save Changes Before… dialog. There are significant changes to this dialog.

The details are found in this technote.

Since you can not currently tab into (or otherwise select) a field displayed as a popup menu that does not allow typing, the Classic method of removing data from a field no longer works. There is now a blank popup item at the end of the popup’s menu; selecting that undefines the field.

In Classic Helix, dynamic popup menus are limited to 253 menu items. There is no (practical) limit in OS X Helix.

Note that the longer a popup menu is, the longer it takes to create. Popups containing thousands of items can take a very long to create.

In Classic Helix, a when a sequence or a lengthy process (importing/exporting record, posting or deleting from a list, etc.) is running, the on-screen mouse pointer changes to a Command (clover) symbol, indicating that the user can cancel the action by pressing Command-period.

In OS X Helix, a Progress dialog appears during sequences and lengthy processes. This dialog contains a ‘Cancel’ button that is used to cancel the action. This button can also be triggered by pressing Command-period or the Escape key.

The Classic OS stipulates that a background application should never open a window. Classic Helix has always followed this rule, so any time a Helix application is put into the background while a sequence is running, the sequence pauses after the current step completes.

OS X has no such rule, and OS X Helix follows that lead. A sequences in OS X Helix does not pause between steps when it is in the background. However, sequences that directly manipulate views (via Tab Field, Copy, Paste, etc.) will fail when Helix is in the background, as the view is not enabled for input at that time.

In Classic Helix, a text field with both Word Wrap and Horizontal Scroll Bar turned on would show you a horizontal scroll bar, even though it could never become active. (Word wrap causes the text to wrap to the next line, so there is never a need to scroll to the right.)

This ‘conflict in logic’ is resolved in OS X Helix in this way: when both Word Wrap and Horizontal Scroll Bar are turned on, OS X Helix turns the horizontal scroll bar off altogether.

See Horizontal Scroll Bars In Text Fields in the known problems section of this document for information on OS X bugs with horizontal scroll bars.

When a Classic Helix window is closed with the Quick Query panel still open, the window height is stored including the Quick Query panel. OS X Helix moves the Quick Query into the toolbar, and the height of the toolbar is not included in the window height under any circumstance. This change was made because the height of the toolbar in OS X is unpredictable (and subject to change if Apple desires).

Consequently, a view that is closed in Classic Helix with the Quick Query panel open and then opened in OS X Helix has a view size that includes extra height, resulting is a view whose height is greater than it should be. The converse is also true: close an OS X window with the toolbar open, then open the collection in Classic. The view height is truncated.

For resizable views this will not be a serious issue, but fixed size views present a problem if the user also has the ability to open/close the Quick Query panel. Unfortunately, because a collection can not know which system it was last opened in, there is no way to avoid this problem.

In Classic Helix, if a popup menu has the Allow Menu to Resize to Data attribute turned on, menu values that contain multiple lines show the full value, stripping out the return characters (and not replacing them with space characters, so ‘Line 1<return>Line 2’ becomes ‘Line 1Line 2’).

In OS X Helix the menu value always stops at the first return character. In the example above the popup menu now shows ‘Line 1’. The data value is unchanged.

In Mac OS 9 and earlier, the Apple Menu could be modified to add application specific commands. Along with the standard About Helix… item, the Help, Custom Help, & Why? menu items were placed here. A collection designer could also place other items in the Apple menu.

Mac OS X discourages installation of items into the Apple menu. OS X Helix moves items found in the Apple menu as follows:

• The About Helix… item is moved to the Application menu. (The first menu after the Apple logo, containing the application name.)
• The Help, Custom Help, & Why? menu items are moved to the Help menu.
• Designer-added items are moved to the to the Application menu, below the About Helix… item.