This page documents the new features in Helix 6.1.6, providing technical details and referring to additional documentation.

The main focus of Helix 6.1.6 is performance. Much code has been rewritten and logic streamlined in an effort to get data on screen as quickly as possible.

Helix 6.1.6 addresses performance in multiple ways. The rest of this section provides a technical overview of those features.

Views are now drawn asynchronously. That is, Helix no longer must wait until a view is completely filled in before responding to the next input from the user. While Classic Helix could draw lists had asynchronously in some cases, OS X Helix supports asynchronicity for all Helix views.

More than anything, asynchronicity makes the Helix interface much more responsive (for example, you can now drag and resize a window before it has completed drawing) and allows you to keep working instead of waiting.

Asynchronicity means that views can be cancelled prior to completion. In Classic Helix, this was done by pressing CMD-period while the list was drawing. OS X uses a much more logical route: close the window by clicking the red Close button, choosing Close from a menu, or pressing your designated command key equivalent.

Another area of performance relates to the frequency of screen updates. Mac OS X is much more adept than Classic at running concurrent processes, so the volume of requests that were needed in Classic becomes excessive overhead in OS X. Under the hood, the changes are too complex for a simple terminology handle, but we have settled on Phased Drawing to describe this new aspect. As the name implies, data is now drawn in phases, and if a delay in one phase results in a window having to wait for data, other process are able to continue forward.

In addition, window opening and drawing is now done on a secondary thread. We cleverly refer to this as the drawing thread.

OS X program control is created around the concept of threads, and "thread 0" is the master controller. It is when thread 0 is busy that you see the spinning OS X rainbow cursor. By moving all of our drawing to a dedicated thread, we make Helix faster and reduce the appearance of the dreaded rainbow cursor.

Because the process of drawing data in a window is now separated from the task of receiving and processing that data, a checkerboard pattern overlay (that we are told is familiar to iPhone users) is used to indicate fields where the data is not yet available. While some users will find this overlay disconcerting at first, realize that it is critical to the performance increase, as it allows Helix to draw the data that is available as soon as it is available and to indicate the data that has not yet arrived. This is most obvious in a Client/Server setting, but can also be seen with Helix Engine.

There are situations where all of these independent threads can cause a problem, the foremost being sequences. Every sequence step presumes that the previous step is complete before moving on. Previous steps could involve a window opening, a record found or entered, or even a tab within a form. Because each command depends on which window is in front and what the state of that window is (e.g., clear, record or field selected, etc), sequence processing runs non-asynchronously and waits for interface quiescence before each step. To enforce this, all open windows revert to non-asynchronous behavior when a sequence is running. Note the all in that last sentence: extraneous open windows that have nothing to do with the sequence itself are also run non-asynchronously and can impact the performance of the sequence. This was true in the past as well, but the distinction was not as obvious as it is now.

A subtle visual distinction shows when a list is running non-asynchronously: the view appears completely blank until the data is gathered, and then the entire page "pops" into place at once. During the wait, the Search In Progress icon (formerly seen only on the Helix Server splash screen) may appear in the center of the view until the search completes. (Note that the Search In Progress indicator is different from the Busy Wheel that indicates that drawing is currently in progress, but can be interrupted by closing the window.)

Another area of the performance improvement — Switching from Apple's HIViews to Core Graphics drawing code — is incomplete at this point, and is currently disabled. Our testing shows that the performance enhancements outlined above give us enough of a speed boost that we can postpone the more extensive work required to use Core Graphics. Our early tests show that Core Graphics will give us another performance boost, which we expect to include after we complete the work on OS X RADE.

Addressing the need to improve performance when a Client visits a collection for the first time (and when structural updates require a fresh download of collection structure) we have implemented a new communication model we call Helix Connection Services (aka: HCS)

The first impact of HCS is to resolve the reports of slow & inconsistent log in over a wide area network (that is: the internet). If a Client was not using a saved structure, there could be an extraordinarily delay before the User Authentication dialog appeared. The same could be true when structural changes were made to the collection and a user's saved structure needed to be updated.

In looking at that process, we realized that the Client was downloading the entire database structure before presenting the User Authentication dialog. There is more than one reason that doing all of this — without even knowing if this person has the proper credentials — is a waste of time, but as it relates to performance, it became obvious that, even though the Client may need those things eventually, it certainly does not need them before they have been given a chance to log in. All that is really needed is a list of users. And once a user has successfully authenticated, all they need next is the structure needed to fill in their menu bar. The rest — the views, the sequences, etc. — can be downloaded on an as-needed basis. And so, instead of being complete from the very beginning, the Client's saved structure file can grow on demand. The performance improvement gained by this approach is staggering.

And although it is considered a side-effect of our push for performance, the added security of delivering nothing until the user has successfully authenticated (and after that only sending that which is needed by the user) is a very nice bonus.

Under the new model, the Client initially just receives the list of users. Once the Client successfully authenticates, that Username’s menus are downloaded. During times when the Client is idle, the menus are examined and the structure required for those menu choices is downloaded. If the Client chooses a menu item before it has been downloaded, (perhaps the first thing they want to do is open a particular view), that action takes priority and everything needed for that menu selection — subforms, templates, rectangles, indexes, queries, sequences and whatever else it may need — is fetched immediately. To the end user, this change is transparent, but under the hood, it is a whole new approach.

Bug R6112 — a cluster of bugs that have existed since the early days of Helix — is finally fixed! This is an ancient bug; more like a specification loophole related to what happens when you make changes to a record and a Print or Find and Print All command is issued before an enter/replace of the record. The problem is compounded when Post on Print is involved, and the solution requires a rather important behavior change.

Details on this important specification change are found in the Knowledgebase page for R6112. (Click here to read it.)

In fixing bug R6756 (Posting progress bar does not update) we discovered an opportunity to improve in user feedback. Beginning in Helix 6.1.6, the progress thermometer fills twice when posting records. During the first pass, the dialog marks the progress of locking the records prior to posting. (This first pass happens so quickly that it typically completes before the thermometer can appear for small posting operations.) The second pass tracks the actual posting operation. An astute observer can now determine whether an error in a posting operation was due to a write locked record or some other error.

In the prior OS X releases, we experimented with various amounts of feedback to present when a sequence is running. While some users prefer detailed information, others do not. Consequently, three new preferences related to the sequence progress dialog have been added, giving each user the ability to tailor the feedback to the level they prefer:

1. HxSequenceShowNames: Boolean to control whether name of sequence is shown.
2. HxSequenceShowSteps: Boolean to control whether name of steps in sequence is shown.
3. HxSequenceStepDialog: Integer to set a step count threshold before showing the progress dialog. Changing this preference causes the following behavior:
   0: Shows as indeterminate instead of steps. The user has no indication as to how long the overall sequence will take.
   n: Show only if the sequence has n or more steps. Most useful for prevent the dialog from showing when a sequence is comprised of a single step. (This is the default state.)
   -1: Never show. Suppresses the dialog altogether. However, the generic "processing" dialog may appear after a short interval.
   While the ability to suppress the dialog is available, it is discouraged: without a dialog to block user interaction, a sequence can be disrupted by user actions such as closing a view, clicking another view to the foreground, or selecting a menu item. Also, the sequence progress dialog provides a "Cancel" button, so disabling the dialog removes the ability to terminate a sequence before its natural end. This preference setting should not be used unless you trust your users not to disrupt a running sequence.

Because of repeated reports of Clients ignoring the Why? message when Helix Server is trying to shut down, Helix Client now automatically opens the Client's Why? dialog (up to two times) when the Server is sending out "please leave" messages. These messages are sent by the Server once every minute. Helix Client now automatically opens the Why? dialog on the first and fifth warnings.