Re: [Hx] Problems Preventing Upgrade Beyond Helix 6

Skip to first unread message

Michael S. Scaramella, Esq.

Jul 20, 2022, 5:12:50 PMJul 20
to Helix-L Discussion List
Lenny, et al.,

I apologize for my delay in replying. I have been engrossed in trying to identify a Wi-Fi LAN intruder in coordination with the CISA. We still run some older hardware which is limited to WPA2 Wi-Fi security, partly to run Helix. WPA2 has known vulnerabilities which are being exploited by the intruder. We want to see the intruder apprehended before I raise our Wi-Fi security level, especially since one of the costs will be further erosion of Helix functionality.

I moved this reply to a new discussion thread because it is at most tangentially related to the original thread that I started about the possibility of running Classic Helix applications on High Sierra on UTM. An incidental benefit of my delay has been acquiring a more detached perspective that has enabled me to see an underlying theme that warrants focused and candid discussion. It seems that all of us who have remained Helix proponents over the years since the Macintosh platform moved to its Unix foundation have also become Helix apologists, at least to some extent. To be clear—I am not exempting myself. It can be persuasively argued that the Apple platforms are superior to competitive platforms in part due to the grand tradition of mercilessly criticizing Apple blunders and deficiencies while clearly recognizing the inadvisability of switching to lesser platforms. Perhaps trying to make “insanely great” products is not so insane after all. I often say that Apple does everything well—including screwing up. Too many years have passed for our focus to be only upon Helix survival. The image of Helix as a Phoenix has worn thin. Helix once was great. It needs to reattain a high level of quality as a condition precedent to reacquiring its former status.

So—what are we to do? I suggest that as we do with Apple products, we should candidly deplore Helix problems and deficiencies while continuing to sing the praises that Helix has so long deserved. The critical path to Helix surviving and thriving needs to be clearly understood and relentlessly pursued. All development budgets are limited. Just contributing more funds is ineffective unless those funds are expended intelligently, efficiently, and effectively. Helix development needs to prioritize and focus upon the critical path. This has not happened, particularly in recent years. Instead, too much development has been on “pet” projects, sometimes funded by particular users, with short-term goals unrelated to the critical path. The result has been obsolete Helix, rather than Helix running natively on Apple SoCs with full utilization of the available multiple processing cores and vast integrated memory resources. Helix, including through version 8, barely scratches the surface of what contemporary Macintosh computer systems are capable of.

More concretely regarding what we can do—current Helix users who wish to remain Helix users should report and document Helix problems as fully and clearly as they are able: techdb Primer: How to File Reports (Bugs, Feature Requests, etc.). Those who are more experienced and able should participate in the beta testing program. Too often I have been the only one reporting major problems. Multiple reports about a particular problem filed by multiple testers prove that the problem is not related to a particular Collection file or a particular Macintosh system. When I am the only one reporting a problem, the tendency to consider the problem something particular to me and our system can be too great. Someone recently noted to me a loss of interest in testing Helix and filing problem reports due to the lack of progress for so long. Someone else stated a lack of willingness to continue investing time and effort in testing because so many problems reported so long ago remain unaddressed. I easily empathize with these sentiments. Still, some hard and too-often unrewarded work needs to be done if Helix is to survive and thrive again. Being benefitted again by the use of a thriving Helix could be the eventual reward.

I had not expected my brief list of Helix problems preventing our upgrading beyond Helix 6 to elicit lengthy commentary. Since it did, I should reply:

That Helix should reliably export data without data loss should require neither argument nor explanation. Helix 6 on macOS, Helix 7, and Helix 8 all have this problem, but possibly to different degrees. There is no clear pattern to when data are lost, yet data are always lost when all data in our large Collection files are exported by Helix for macOS. Helix 6 running on Classic always exports all data reliably. Only I reported this major problem, at least as early as before Helix 7 was officially released. Perhaps this problem would have been fixed long ago if anyone else had filed a similar report. That this problem persists in a shipping version of Helix is difficult to justify. My testing indicated that there is no globally ascertainable limit beyond which data are lost on export. It is likely that the limit Lenny identified is particular to the Collection and system he has been working with. I discussed this problem in detail in messages posted to this List on April 18, 2018, and on July 15 & 16, 2020, so I will not add further detail now.

That Helix should support contemporary fonts should require neither argument nor explanation. It is disheartening that Lenny so cavalierly dismissed the value of our custom fonts. They are our intellectual property born of much difficult development work expended over many years. If I could communicate with myself of 1990, I would advise using only custom font files for which we own the copyright in our Helix-based applications. I have moved toward this more enlightened development policy as much as I have been able. To the extent practicable, professional software developers should control the resources used by the software applications they develop, especially resources used by software intended for commercial licensing. Unnecessarily relying upon resources freely changeable by others is a recipe for future problems. History has proven this true many times. It once was possible to control font resources at the Collection level. Classic versions of macOS looked first for font resources installed in the resource fork of a file being opened by a Classic application. Font/DA Mover could install fonts into Collection files with the magic of the Option key. No version of macOS supports this. Font resources in the resource fork extended attribute of files are ignored by macOS. This necessitates installing custom fonts used by Helix-based applications into the macOS system space or the macOS user space of the Macintosh systems running Helix. Doing this makes the fonts usable by other applications. Users and system administrators should only be asked to install contemporary font resources into systems that they administer.

The development decision to make Helix support fonts from the dawn of the Macintosh platform at the expense of Helix not supporting contemporary fonts was made with knowledge and intent. I would have made a very different development decision, and so advised at the time. For clarity, I should note that the custom fonts I developed are fully supported by macOS from System 8.6 with standard ATM through macOS 12.4 and beyond. Classic Helix supports our custom fonts, as does every macOS application other than Helix that I have ever used which enable fonts to be selected. Even Windows natively supports the fonts that I developed.

Looking up a value based upon a looked up value, and looking up a value that itself is based upon a looked up value, are normal and essential functions which Helix must perform properly and reliably. The major commercial applications that I developed could not exist without this functionality. Helix must be made thread-safe. This is not optional. The days of single discrete CPUs with single execution units processing instructions strictly in sequence passed long ago. All of Helix must be upgraded to run reliably on contemporary Macintosh systems.

I am not a contract developer working on others’ Helix Collections. I develop Helix-based applications intended for commercial license to end users. Our licensees need to be able to upgrade the applications that they license from our software publishing company. This necessitates exporting data records from an earlier Collection file and then importing those records into a newer Collection file. Those records must be validated on import, which requires validation at the field level. These validations cannot be done using conditional Sequences. Also, handling errors upon execution of conditional Sequences is broken in recent versions of Helix. This would make any attempt to use complex recursive conditional Sequences with Keypress Enter unreliable. Ultimately, data validation is a fundamental and essential function of all data management systems. The problem I listed is that field values are validated prematurely. This causes Helix to sound the system alert very often and mostly inappropriately. I have apologized for this misleading and very annoying Helix behavior far too many times. Classic Helix validates fields upon data rectangle deselection or upon record entry or replacement. Helix for macOS should behave the same way.

Automatic advancement of focus to the next data rectangle set to “Allow tab” when a control selection is made often causes the control to auto-scroll out of view immediately after the control selection is made. This is another misleading and very annoying Helix behavior that I have apologized for far too many times. I have never seen another macOS application behave this way, including Classic Helix which behaved as all other applications behave.

It is purely fanciful to imagine that an AppleScript could be developed that would effectively substitute for my judgment exercised in real time when determining how to arrange Helix icons to provide organization essential to further developing and maintaining any Helix-based application even fractionally as complex as Managing Partner®. The Helix GUI should resemble and function similarly to the contemporary macOS Finder rather than like a malfunctioning approximation of the Finder of the latter 1980’s. We need more and better ways to organize our Helix work. Helix should have no commands that anyone would have any reason to say should never be used.

I did not mention Auto-Open Posts in the original discussion thread, either explicitly or impliedly, so am surprised that Lenny referenced them. Since he did, I should reply. As I have stated before, there are critical instances where only Auto-Open Posts can fulfill a need legitimately. I have previously discussed this at length with detail on multiple occasions, so will not now repeat that detail. What I will do is more particularly explain an example that any of us can see. The Helix problem reporting form includes a field for comments. Appropriately, that field is not directly editable by users. Instead, new comments are appended to previous comments by a Posting operation. Since users adding comments do not have a corresponding Helix User icon, the UserName tile cannot return a value unique to the user, so posting a Report record number to a User Relation would be ineffective. The only proper alternative is to use an Auto-Open Post to automatically transfer the Report record number to the form used to enter new comments. Instead, a Sequence copies the Report record number to the System Pasteboard (Clipboard) and then pastes it into the corresponding field of the form used to enter a new comment. This replaces the previous contents of the Pasteboard with the copied record number. This is illegitimate because it causes completely unexpected user data loss. When a macOS user copies or cuts data to the Pasteboard, it should remain there until the user deliberately runs another Copy or Cut command. This user data loss is particularly inexcusable since Helix has included Auto-Open Posts for many years which do not depend upon the Pasteboard or User Relations to move data between forms. There is no justification for overwriting user data unexpectedly, especially when an easily implemented and readily available alternative standard non-destructive method could be employed. This embarrassing defect of the Helix Problem Report system should have been fixed long ago.

Managing Partner includes many critical functions that only Auto-Open Posts can accomplish without unacceptably poor or clearly illegitimate alternative methods being used. Any assertion that Auto-Open Posts have been “superseded by what [S]equences can do” is incorrect. Sequences cannot fully replace the functionality of Auto-Open Posts. No one is forced to use Auto-Open Posts. Using them skillfully requires full command of conditional Sequences, of conditional Posting, and of how the Sequence and Posting conditions should be logically interconnected. Our licensees seem to appreciate the functions that employ Auto-Open forms with complex conditions most of all. It is rewarding to receive calls from licensees using words like “awesome” and “amazing” when describing forms that open automatically when and as needed. Without the functionality of Auto-Open Posts our Helix-based applications would be hobbled beyond recognition.

I was extremely surprised to read Lenny’s characterization of me as somehow stuck in the past. I doubt that anyone has tried to push Helix further or faster into the future than I have. I remain dependent upon Classic Helix because Helix for macOS remains lacking—not because I lack the willingness to improve or update the software that I develop. If anyone or anything relevant has been stuck in the past, it is Helix itself. This is what must change.

With sincere regards to all,


On Jul 13, 2022, at 3:33 PM, Lenny Eiger <> wrote:


We have addressed all of these issues:

data loss on data export
We have discovered the limit of exporting data, and now use a series of functions to pull out data in loops. We load 16 or 17 thousand records to a database on the iPhone. Quickly and without error. 

incompatibility with contemporary custom-designed fonts used extensively in our Collection files
We simply chose other fonts. 

consistently failing lookups especially when based upon previous lookups
Lookups should not be based on other lookups. We simply don't do this, or very rarely. One can't fully normalize Helix, as it can't do what other databases call "relations".

premature validations
We use conditional sequences for validating. Validation in Helix has many problems, especially that it is only reliable on new records..

automatic advancement of focus to the next data rectangle set to “Allow tab” when a control selection is made
I don't see this as an issue. 

and irreversible destruction of the very important and carefully maintained organization of icons in Icon Display Mode when the Align Icons To Grid command is run. 
I never run this command. I have AppleScripts that I have developed to arrange icons in a specific place, rename them, and so on.

I also never use Auto-Open posting. It's an old technique that is superseded by what sequences can do.

When I wrote the first version of the CRM mobile app we were in Swift 2. Then came 2.2, 4, 5, and so on. Each time, the app required a rewrite, both because new and better things were available, but also because some stopped working, or never really did (Auto-Layout). 

I respect your desire to maintain old systems. However, I wouldn't suggest it to anyone. I can't tell my clients that their program only works on an OS that is 10 years old, or more. The expect me to keep up. It reflects badly on your company's ability to adapt to changing programming conditions.

There are a lot of folks that are committed to one feature or another in Helix. The figured out a way to use it that they like. Some of these will undoubtedly disappear in an upcoming release. We simply don't have the same OS we had in 1983, and Pascal, as good as it was then, is not a reasonable language to work in today. Things change. As developers, we have to be creative and come up with news ways to solve each of the issues in question. The only way thru time is forward.


On Jul 13, 2022, at 11:38 AM, Michael S. Scaramella, Esq. <> wrote:


Multiple long-unresolved and well-documented problems with Helix 8 in particular, and Helix for macOS X and later in general, prevent me from upgrading our Collection files. Several particularly salient problems that come to mind in no particular order are: data loss on data export, incompatibility with contemporary custom-designed fonts used extensively in our Collection files, consistently failing lookups especially when based upon previous lookups, premature validations, automatic advancement of focus to the next data rectangle set to “Allow tab” when a control selection is made, and irreversible destruction of the very important and carefully maintained organization of icons in Icon Display Mode when the Align Icons To Grid command is run. Our continued dependence upon Classic Helix is far from voluntary.

I have no practical choice except to continue using Helix RADE 6 for both Classic and 32-bit macOS to maintain our complex Collection files. I have developed a few small Helix-based applications using Helix RADE 7 by carefully working around problems and limitations. Nothing more is practically feasible at present.


On Jul 13, 2022, at 1:40 PM, Greg Morin <> wrote:

Ok, probably dumb question, but why would one need to run "classic helix" at this point. Collections can be run on the latest intel hardware and 10.14... which is where I thought we were all currently "stuck". Are you saying some folks are still using their Helix under classic emulation on a PPC Mac? Why? Why not simply update the collection to run under Helix 8? 

Greg Morin


Computer Division
 ~  *  ~


Lenny Eiger

Jul 21, 2022, 5:59:25 PMJul 21
to Helix-L Discussion List

The only thing I would say is that you have some opinions about what Helix "should" do. 

In mot cases I don't disagree. I can work in the realm of "should", however. I have to work in the realm of what it actually does. My clients, all wonderful and erudite folks, need me to develop features that work every day, day in day out. In today's world. They might be willing to stick with Mojave until the 64 bit version is out, but no further back than that. Certainly not for a Client.

That's my world. I get that it might not be yours. My clients want things that don't fail.... and that's what we do at DataBright.


On Jul 20, 2022, at 2:11 PM, Michael S. Scaramella, Esq. <> wrote:

Lenny, et al.,

Reply all
Reply to author
0 new messages