Discussion: This crash is triggered when a Client opens an entry view that has the Quick Query panel open by default.

You can confirm that your crash is triggered by this bug by looking in the Crash Log. About 15 lines from the top you should the following:

Thread 0 Crashed
0 [the first few lines vary, but somewhere around line 3 or 4...]
. com.qsatoolworks.server ... SubResp + 18
. com.qsatoolworks.server ... Clear + 44
. com.qsatoolworks.server ... _p__M7_Clcmeth_S35_Clibldref + 131
. com.qsatoolworks.server ... Clcdocli.8 + 148
. com.qsatoolworks.server ... CLCBldRef + 188
...

Solution: Open the collection in Helix RADE and cancel the default Quick Query on any entry view that has one.

Note: this bug is partially fixed in Helix 6.1.6 (185). After the release of Helix 6.1.6 (185) it was discovered that forms that have both a Form/Power Query and a default Quick Query can still cause this crash. As before, the temporary solution is to open the collection with RADE or Engine and cancel the Quick Query.

Solution: Although this diagnostic code is accurate, it is easily resolved by opening the collection with Helix Server, Engine, or RADE, then Saving and Quitting. As this web page explains, when Helix crashes, it can leave a collection in a fragile state, and reopening the collection can clean up the 'loose ends' that Update Collection reports as structural damage. It is always recommended that you attempt to reopen a crashed collection with Server, Engine, or RADE before running the Helix utilities.

Discussion: This crash is triggered when data is entered on an entry view that contains dynamic popup menus and the view is then immediately closed. Typically only sequences that have an Enter command followed by a Close command can close the window fast enough to trigger this crash, but it is possible to trigger it manually on a slow network (i.e: WAN).

You can confirm that your crash is triggered by this bug by looking in the Crash Log. About 15 lines from the top you will see the following:

Thread 0 Crashed
0 com.qsatoolworks.client ... hxViewRecord::AbortedView() + 6
1 com.qsatoolworks.client ... hxViewRectangles::AbortedView() + 19
2 com.qsatoolworks.client ... hxObjRectangle::AbortedView() + 20
3 com.qsatoolworks.client ... hxDynamicValues::Done(long) + 39
...

Solution: Modify the sequence to leave the view open, or wait until the entry view has returned to quiescence (the busy wheel has stopped spinning) before closing it.

Discussion: When a sequence includes the Copy or Cut command, macOS was attempting to execute that step before the view is ready. As a result, the data to copy (or cut) was not available when the command was executed.

Workaround: A useful workaround for this problem is to insert a Draw Screen command after any command in a sequence that causes a screen refresh. (E.g.: Find… commands, data entry, posting. — if you are uncertain, you can also insert the Draw Screen command before each Copy or Cut command.) Draw Screen tells Helix to explicitly fill in all of the data before going on to the next step. This forces macOS to wait until the data is ready before attempting the Copy or Cut step.

Discussion: On a form with all inert fields, where one of the fields is validated, typing invalid data and closing (or clearing) the form would cause Helix to display the "Save changes before…" dialog. (This should not happen, as there are no ert fields to store, there is no posting, etc.) Clicking the "Enter" button in that dialog resulted in a crash.

Commentary: Using the User Editor to remove Add permission for such a view (and adding a default button to trigger the entry, if needed) is a wise programming decision, and avoids this bug.

Discussion: In macOS, the Helix construction of a static or dynamic popup that allows typing is converted into a macOS-standard combo box field. Code changes in Helix 6.1.6 triggered a situation where applying the Time Stamp to one of these fields resulted in a crash.

Solution A: Log in to macOS as a user with administrative privileges and register the program.

Solution B: Follow this procedure:

1. Right (control) click on the Helix application and choose Show Package Contents from the contextual menu
2. Navigate to the Contents:Resources folder
3. Right (control) click on the owner.hebl file and choose Get Info from the contextual menu
4. In the Ownership and Permissions section, give Others (10.4) or everybody (10.5/10.6) Read & Write permission.
5. Close the Get Info and package windows
6. Launch the program and enter the key. It will now be stored correctly.

Solution:

1. Run Apple's Disk Utility and do a Repair Disk Permissions on the hard disk.
2. If that does not fix the problem, right (control) click on the folder, choose Get Info from the contextual menu, and give Read or Read & Write permission to the appropriate users.
   Correct permissions are:
   • Owner -> system -> Read & Write
   • Group -> admin -> Read & Write
   • Others/everybody -> Read only

Solution: Rename the "Helix" folder (in the Applications folder) before running the installer. A new "Helix" folder is created for the newly installed application. After the installation is done, merge the folder contents and delete the extra folder.