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.

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.

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

Framed data, text label, and repeat rectangles use the OS X appearance API when drawn on screen, resulting in specified color and line widths being ignored. Colors and line widths specified in Classic Helix are used in OS X only when printing.

OS X provides a limited set of visual options for interface elements: checkboxes, radio buttons, popup lists and buttons. Collectively, these items are referred to as Controls. Changing the color of the element itself or the background is not possible at this time.

This information has been moved to its own technote. See Full Keyboard Access Issues for details.

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.

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 impact performance negatively.

When a popup menu that allows typing (aka: a combo box) also has the Allow Edit attribute turned off, only the popup is disabled. The text field is always enabled. If you want the field to be non-editable, use a plain text field instead.

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 top of the popup’s menu; selecting that undefines the field.

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).

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.

In addition, because of the way OS X cycles through the three states: (true, undefined, false) a checkbox that has a defaulted value of true can not be changed to false. When the current state is true, the next click changes it to undefined, which allows the default value (true) to reassert itself, making it essentially impossible to cycle all the way around to false. Again, the workaround is to use an alternative format, such as a three-button radio button.

In Classic Helix, a user could change an Enter command into a Static Enter by holding the option key down while the sequence was running. In OS X Helix, the sequence always executes the command in the sequence, ignoring the Option key except for the purpose of honoring the Optionally Show Dialogs setting.

In Classic Helix, a text field with both Horizontal Scroll Bar and Word Wrap 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.)

In addition, a field with Horizontal Scroll Bar turned on and Word Wrap turned off runs up against a known bug in Mac OS X.

Both of these problems are resolved in OS X Helix by always turning the horizontal scroll bar off.

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.

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 Form Query attached to the view. In OS X Helix Find Next/Previous are enabled when a Quick Query is cancelled.

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 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.

Click and drag to select records is currently broken.

In addition, 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.

In the earliest Preview Releases a dialog (like the one shown in the Sequence Processing section below) appeared whenever a lengthy operation was going on. Except that clicking the Cancel button had no effect.

A Helix list showing the busy indicator centered in the view.

In the 6.1.3 Preview Release that was replaced by the standard OS X busy indictor, placed in the upper left corner of the view.

In the 6.1.4 Preview Release, the busy indicator moves to its proper location in the center of the busy window. When this indicator is seen, the view is still gathering and displaying all the necessary data. When the view is ready, the busy indicator goes away.

Because long lists are still quite slow in OS X Helix, you sometimes have to wait a while for the busy indicator to disappear. And since lists are currently non-asynchronous, you can do nothing in Helix until the list is ready and the busy indicator has gone away. Wait it out: patience is a virtue that will be rewarded.

In the 6.1.6 Release, Asynchronous Lists have been reimplemented, and a Data Pending checkerboard pattern is displayed wherever Helix is unable to display data because it is still being calculated/retrieved by Helix, or has not yet arrived from the Server. The Data Pending pattern and the busy indicator are used to indicate two different situations and work in conjunction with each other.

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.

This is the sequence progress dialog. It appears whenever a sequence of more than one step is running. The Mac OS X Human Interface Guidelines (HIG) do not recommend using the cursor for feedback, so the Classic Helix method of changing the cursor to a Command symbol (which was to indicate that you could press Command-period to interrupt it) had to be changed. (And that was a pretty lame indicator anyhow.)

Sequence in Progress Dialog

In the 6.1.3 Preview Release, the dialog contained the text Running: followed by the name of the sequence.

In the 6.1.4 Preview Release, the word Running: was removed, so only the name of the sequence is shown. This allows collection designers to name sequences (via the Custom Name option in Design Mode) in a manner that will display text that communicates with the end user in the manner of their own choosing.

The dialog contains a Cancel button, which (naturally) cancels the sequence. A secondary dialog appears asking if you really want to stop the sequence from completing. At that point you can resume or cancel the sequence.

In the 6.1.6 Release, we have added preference settings that allow you to adjust the way the sequence dialog appears. You can present the thermometer as an 'indeterminate progress' indications (the animated barber pole type) and you can control whether the dialog shows the name of the sequence and optionally the name of the step that is currently being executed.

This information has been moved to its own technote. See Technote R6153 for details.

Keyword separator table has been changed. Details are found in this technotes.

Classic Helix did not respect the Allow Query attribute for rectangles in the Form Query specification window. Rectangles with the Allow Query attribute turned off could still be queried. The attribute is only applied to the Quick Query command.

OS X Helix disables querying on fields with the Allow Query attribute turned off in both Form Query and Quick Query.

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.

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.

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

Since Helix’s earliest days, the specification for how Helix should respond when an unentered record is printed was never clearly defined. This led to behaviors that were buggy, confusing, and sometimes required workarounds to preserve data integrity.

The situation is made even more complex when Post On Print options are factored in: views would respond differently depending on which posting options were used.

Helix 6.1.6 and later address these issues, creating a comprehensive specification that a collection designer can rely on.

Technote R6112: Printing Unentered Records covers the changes in detail.

Classic Helix uses a fixed grid size when printing views. OS X Helix changes this specification in a very important way: Helix now automatically reduces the size of the output to fit the whole template on a single page.

Technote R6405: Page Setup is not retained between launches covers the changes in detail.

When Helix was originally created, dot matrix printers were the norm, and Helix's 1 point line width was not unreasonable. With today's high resolution printers, 1 pixel lines appear too heavy.

During the OS X transitional phase, Helix reduces line widths by a factor of 0.7. (That is: the standard 1.0 point line is printed at 0.7 point width.

When the OS X transition is complete, Helix will give greater control over line widths to the collection designer.

When a template contains a subform, it is possible for a single record to generate more than one page. Which pages are printed when the user specifies a range of pages has changed in OS X Helix.

In Classic Helix, Find and Print All prints the specified page range for each distinct record on the form. That is, if you Find and Print All and specify ‘From 2 To 2’, only ‘page two’ of records whose subform contents are large enough to generate a second page are printed. In other words, each record is treated as a distinct print job, with each records having a page 1, page 2, etc.

When printing such a form in OS X Helix, the entire print job is taken as a single entity, and ‘Page 2’ is the second page that would have printed had a range not been specified.

For example, consider a template that prints customer statements, where the outer template is an entry view showing the customer address, etc., and a subform lists outstanding invoices. If there are 10 statements to print, and the fifth statement requires two pages, there will be a total of 11 sheets of paper printed. A Find and Print All with no Page Range specified outputs 11 sheets of paper, just as you would expect.

But what if the user specifies printing pages ‘From 5 To 6’? In Classic Helix, no pages print because none of the individual records have a fourth or fifth page. (Actually, a single blank sheet of paper is actually printed, adding to the confusion.)

In contrast OS X Helix prints the fifth and sixth pages of the whole set, which would be both pages of the fifth record — the one record that requires multiple pages in this example.

This change is a significant improvement, as you now have much better control over which pages are printed in OS X Helix.

When a template is designed to print multiple pages, each printed page counts as a page in the OS X Helix print dialog. In Classic Helix, the template is considered a single page, no matter how many pages are 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 between Classic and OS X appears when you specify a page range to print. In Classic Helix, printing ‘From 1 To 1’ prints the first four pages, because the template defines one ‘page’ as requiring four sheets of paper. In OS X Helix, printing ‘From 1 To 1’ prints only the first (upper left) page of the first set. Likewise, where printing ‘From 3 To 3’ prints the four pages from the third repetition of the list in Classic Helix, OS X Helix prints the true third page —i.e.: page 3 of the first set. To print the ‘third set’ in this example in OS X Helix, you would print ‘From 9 To 12’.

This change is a significant improvement, as you now have much better control over which pages are printed in OS X Helix.

The login process (for both Client and Engine) 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.

See also the What’s New page for information on the Open Recent command for instant access to saved structures and collections.

The Visit dialog has been completely rewritten. A single field is used to enter the address of the Server and to Visit it when found.

When entering an address, Helix Client will notice when you pause (for one second or more) and search for the address entered. No more "tab required" to initiate the search.

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.

These Options dialogs have been redesigned and now feature popup selection of options instead of slot machines.

The Power Query specification dialog — aka: the Power Query Term Specifier — has been redesigned and now features an interface patterned after the Finder’s search window. View a technote with video demonstration.

The Form Query specification dialog — aka: the Query Term Specifier — has been redesigned and now features popup selections instead of the multitude of radio buttons. View a technote with video demonstration.

The Save and Log feature has been reworked, and is automatically enabled in OS X Helix. With Save and Log enabled, Helix Server no longer has a Save and Stop Logging menu item. (Helix Engine and RADE do.)

The HxAutologging preference setting can be used to disable automatic logging.

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

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.

In a Form Query window, a rectangle that can not be queried (e.g. a "Form Count" abacus) is no longer displayed. In Classic Helix the rectangle is shown, but clicking on it sets a Why? message that "An abacus containing a form related tile cannot be used in a query icon."

The Windows menu gains functions that are supplied by OS X: Minimize, Zoom, Bring All to Front, and Command-` to switch the active window. See this technote for more information.

AM/PM option has been removed, and you can now control the checkboxes via keyboard shortcuts.

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.

In OS X, Helix typically saves so quickly that the Last Save Length and Average Save Length statistics are sometimes reported as ‘0 seconds’. In Helix 6.1, saves are reported with 0.1 second accuracy.

One of the keys to maximum performance in OS X is to minimize the use of Virtual Memory. VM usage is best gauged by the pageins & pageouts statistics. These are now available in the Collection Info window, under the Machine Info tab, to make it easier to determine when VM may be hampering performance.

OS X includes the ability to define custom key commands via the Keyboard System Preference panel. Keyboard commands assigned from within Helix itself take precedence over OS X keyboard commands.