Helix Client 6.2.1: The Charm This Friday
26 September 2013 — In 1839, in her book Letters addressed to R.H. Home, the poet Elizabeth Barrett Browning wrote, “ ‘the luck of the third adventure’ is proverbial.” Twenty-three years later, in The proverbs of Scotland, the Free Church of Scotland minister Alexander Hislop wrote, a bit more succinctly, “the third time’s lucky.”
Somehow, the notion that the “third time is the charm” has worked its way through many cultures. A popular explanation references an English law that says that any man who survives three attempts at hanging is to be set free. That explanation is based on the story of John ‘Babbacombe’ Lee, the so-called “man they couldn’t hang,” who was sentenced to death in 1885. He stood on the gallows three times and all three attempts failed. He lived another 55 years.
Easy to see why that explanation is popular. But clearly, the charm inherent in the third attempt has nothing whatsoever to do with Mr. Lee, since the poet first penned her phrase more than 40 years before he was born, and she was quoting someone. In any event, the phrase became part of our collective subconsciousness, and now we are hoping that it rings true this Friday at noon. Our desire to ship Helix 6.2.1 is starting to feel like a noose tightening around our necks, so we are hoping this ‘third’ test proves to be the charm we seek.
HelixChat Resumes: Friday, September 27th at 12:00 PM Eastern US Time (-4:00 GMT)
Three weeks have passed since our last public test of our new, Intel-only Helix Client. While not as widely attended as we had hoped (a big thank you! to those who were there) it was a predominantly wonderful experience: The progress was clearly visible, even though one nagging issue remained. In the three weeks since then, we have been working to resolve that last bug, and now we believe we have it.
And so the third public test of Helix Client/Server 6.2.1 begins tomorrow, Friday, September 27, at 12:00 PM Eastern Time. (That corresponds to 4:00 PM GMT on Friday for international users.) We apologize for the short notice, but it was only yesterday that the ‘final bug’ was (we believe) fixed.
Very important! You will need to get the most current Helix Client — build 5952 — before joining us on Friday. If you participated in our last test, Helix Client 6.2 should automatically prompt you to install the new version. (If not, disconnect from the server and choose Check For Updates from the Helix Client menu.) If there is no Check For Updates menu item, read the next section for instructions on getting the newest Helix Client.
Either way, once you have the new Helix Client installed, connect to techdb, open HelixChat, and join us for what we hope will be the final test. If you’re an old hand at these tests, you can skip the next section and read on for an explanation of what we found after the last test and what we need you to do to test this new fix. If you are new to all of this or your version of Helix Client is too old to include the automatic update feature, the next section is for you.
For Newcomers and Re-Joiners…
If you haven’t participated in our prior test, or you haven’t been connected to techdb lately, throw away any older copies of Helix Client 6.2.1 you may have and click here to download the newest build. If you need a short tutorial on HelixChat, head over to the techdb page for detailed instructions.
Once you’ve downloaded Helix Client, use the Connect To… menu (new in Helix Client 6.2) to open your previously saved connection document or to start a new connection (hostname: techdb.qsatoolworks.com).
If you have previously registered in techdb, you can enter your customer number and password in the HelixChat window (keyboard shortcut: F4) and start chatting. (i.e: entering records) If you’ve never registered, just follow the instructions in the “Access Password Registration” view — or visit this web page for more detailed directions. Once you’re in HelixChat, read on to see what this test is all about.
Not Quite an All-Nighter
As noted above, we’ve been struggling with one elusive ‘big bug’ that the HelixChat window demonstrates quite well. This view contains a subform that is limited by a query to display only the four most recently entered records. When the problem occurs, the manifestation is in the message field of the last record in the subform, which seems to “freeze” with one message stuck there. The other fields in the subform — the name and picture rectangles — update correctly, but the message does not, and an old one remains ‘stuck’ there until the window is closed and reopened. That’s clearly unacceptable.
A late-night group debugging session among our engineers was proving fruitless until, at about 1:30 AM, somebody noticed something happen that “simply cannot happen.” Basically, the subform rectangle was acting as though the user had somehow typed directly into it! As a result, the rectangle stopped updating —so it wouldn’t lose the non-existent changes that it thought had been typed in.
We scratched our heads: how could this rectangle possibly think the user had changed it? The answer came about an hour later: the Font Panel! As participants in the last test know, we were coming to the conclusion that using styled text was somehow contributing to this bug, but every test we devised to flush it out failed miserably. Whenever we thought it was within our grasp, it receded into the fog and we were left with nothing more than a growing sense of frustration.
But now we know: because the font panel is a floating palette, the font changes made there have to be ‘sent’ to the rectangle where you are typing. This is all handled by macOS and is supposed to be automatic, but something was causing the system to get confused and send the data to the wrong rectangle. Identifying and cornering this bug required a very specific set of steps, taken in a specific order, which is what made it so difficult to isolate.
We cannot say categorically whether this is an outright bug in macOS or just a really obtuse API. Our solution was to put in a number of safeguards and double checks to make sure the Font Panel data gets sent to the right rectangle.
So when you join us for tomorrow’s HelixChat, here is how you can help us prove that our fix is working: use the font panel to style text in your HelixChat message. It isn’t necessary to go crazy with fonts, sizes and colors; simple changes are sufficient. What would be most helpful is to style your text using as many different approaches as you can think of. Leave the Font Panel open all the time, or close and open it frequently. Choose your style before typing text, or type your text then select it and apply a style. Set some text in a style, then click to deselect the text before posting… anything you can think of that might ‘trip it up.’
All the while, be deliberate in thinking about the steps you are taking. It is also useful to have your sound turned on because this form causes your computer to beep each time a new record is entered, courtesy of the ‘Notify on Change’ property.
If you do find something that causes the subform to fail to update properly — or you see any other screen anomalies — note how you got there, then close and reopen the HelixChat window and try to reproduce it. If you can’t, you either missed a step, or got a couple of them in the wrong order, or added an extra step. Whatever you do, please keep after it until you’ve got a reproducible example.
Of course, it is our hope that you see nothing out of the ordinary and we can conclude once and for all that this bug has truly been eradicated.
It’s a lot of work, and it’s fairly annoying, tedious and repetitious work, but there’s an as yet-to-be-determined prize for anyone who can make it fail repeatedly, so good luck to you all and let’s hope no one actually wins this one!
Once again, we thank you for helping us refine Helix Client/Server 6.2, and we look forward to seeing as many of you as possible with us online this Friday, from noon for around three hours or so. A successful test sends this product to beta testers and brings us to ‘the next step’ in the evolution of Helix.