Technical Educational Professional 3rd Party Contact Us

Overview Services techdb Issues Tips HMM FAQs Repair Search Chat Feature Requests Bug Reports FTP

First, the misery of the week: Matt’s MacBook is where the ‘test builds’ of the new code are made. On August 19th the hard drive failed, after only 15 months of use. (MacBook buyers beware!) Fortunately, AppleCare replaced the hard drive and Retrospect restored the data, so nothing was lost other than time. Fortunately this did not delay Helix progress at all, since there had been no new code to build and test lately anyhow. All of the engineers have been working on ‘deep’ projects (see below) which are starting to bear fruit. Things should start hopping now.

The last few weeks have been spent diving deeper into the code and fixing obscure bugs involving combinations of features, like multiple nested (two deep) subforms, subforms containing buttons, etc. To give you a feel for how this phase of the project works, here’s one engineer's report on what he has been doing for the last three weeks:

1. Working on a complex form with over a dozen buttons and subforms: every time I find and fix a bug, another is uncovered…
2. On this form, pieces were being displayed in the wrong place. This was because there were two data structures being used to hold subform information, and the code was assuming that they were always in sync. They weren’t. The fix was to search the other data structure to find the matching piece.
3. Attempting to open the window just blew up. It seems that in an abacus that returns a picture, if the picture is undefined, the abacus was returning undefined text rather than undefined picture. This has always been the case, but Classic Helix had code to work around this problem. I chose to fix the bug rather than propogate the kludge into the future.
4. When the window finally opened, clicking on a button had no effect. It was then discovered that buttons in a subform nested inside another subform were not recognized by OS X. It turns out the code that handles clicking on a list was overlaying everything in the record, preventing clicks from getting through to the buttons. So I fixed that.
5. This made it look like everything should work. When the button was clicked, it highlighted. But when the mouse up occurred, the button did nothing. In fact, there was no event from the system to indicate that a button had been clicked.
   Searching the web, it turned out that a lot of people have had this problem. The solution is to have the record highlight widget respond to an event that asks for the ‘clickable area’. Since we were not responding, the system was assuming that the entire area was clickable, so nothing ‘behind’ it would ever get a click. (This is obviously an incorrect assumption, but you can’t argue with a computer.) In our case, the ‘clickable area’ is the area that is not over a button, that is, the same structure that I built to test for button clicks. This was an easy fix, and the system started to report button clicks.
6. But the button still wasn’t doing anything. This was quickly tracked to the fact that click events weren’t being sent to lists or subforms, because Helix knows you can’t edit them. Obviously, those events need to be sent, so that code was written, and my little test collection worked!
7. Back to the original test case. Running the test with the fixed Engine works a little better than the original. Two of the six missing buttons on the form are now visible and something happens when you click them, but the others are still missing. After much work, it was discovered that when trying to execute the query to find records for the lists (remember, these buttons are on subforms, in lists) the code was using the wrong query. Two almost identical queries had been swapped. Once this was fixed, the form looked perfect, but the buttons still didn’t work.
8. The buttons didn’t respond to clicks because of two additional problems. First, clicks were not getting through the record pad, for the same reason they weren’t getting through the highlight view, which was fixed as bug (3). Another application of that technique and this problem was solved.
9. Second, buttons needed to be moved to the front of each record, and apparently that wasn’t being done quite right. I moved the buttons to the front and suddenly they started to respond to clicks.
10. But they still didn’t work. The sequence would start, but very quickly abort because of some unknown error. This turned out to be related to the [new] activity dialog popping up at an inopportune time. Because of a previous kludge, the front window was not being deactivated correctly. That meant that the record lock held by the front window was not being released. Since that window, and the next window that opened were both operating on a global variable, the attempt by the second window to get the record lock failed, and the sequence aborted.
    In this case, the solution turned out to be to get rid of the previous kludge. I discovered a feature in the system called independent activation scope. By setting the activity window to have this scope, it can be activated without deactivating the front window, and all of our problems (with this window, at least) are solved. It looks like the wxWidgets code was actually attempting to set this but something in that chain wasn’t working. By simply setting independent activation scope, I was able to remove the old kludge, and everything appears to work.
11. Except that didn’t quite work either. The first window was getting the record lock on the system globals record, and when it was deactivated, it didn’t release it. A window is supposed to release a lock if it is deactivated and no data has changed, but that wasn’t happening here. It turned out that the window in question had posting attached, and that was being interpreted as a ‘change’, so the record lock was not being released. I changed it to check that the user actually made a change, and it finally worked perfectly.
12. But wait! There was no reason for that record to be locked in the first place! The form in question doesn’t have any entry rectangles, so it should not even be eligible for record locking. I tracked this down to click processing code that was testing to see if the record could be locked by actually locking it, on the assumption that if there is a click in the window, that click must be trying to change some data. That assumption is incorrect if the click is on a button, or in fact anything that is not allowed to get focus. I fixed that, and a couple of similar cases where a record was being locked unnecessarily.

In the meantime our other two engineers have been working away. Here are some more notes:

• Page Up, Page Down, and friends — including scroll wheels — work.
• Page Boundary rectangles now properly print (or do not print) in all known configurations.
• When username security is off the Login dialog now defaults to a user whose name is the same as the full name OS X user that is currently logged in. (If there is no exact match, no user is selected.)
• All new Edit Users dialog.
• Helix Client can once again display asynchronous lists.

We expect this to be the last set of major changes before beta testing begins.

Yeah, so we’re trying to debug something related to what happens when you hold the option key down while starting a sequence and we stumble upon this:

{$IFC GENERATING68K}

For those of you who don’t write code, that is a “directive” — an instruction that tells the compiler to use the next section of code only under certain conditions. This one says to use this code for Motorola 680x0 (68K) processors. The last Mac with a 68K processor was the Macintosh LC 580, running System 7.1 at a whopping 33MHz. Folks, that’s 12 years — and 3 processor architectures — ago. For some odd reason that code won’t work on an Intel-based Mac running OS X!

Whoa. Despite evidence to the contrary we recently discovered that the PICT data format is supported natively on the OS X Pasteboard. (Formerly known as the Clipboard.) Armed with this new knowledge, we now have functional picture fields in OS X Helix! This cuts a lot of time off the work required to get the Picture field working in OS X, and it solves a potential transition problem for end users.

Memory leaks are an ongoing problem (and working in Xcode shows that Apple has quite a few of their own!) but some new tools are helping us keep them in check.

We continue to plow into more and more complex collection constructions, looking for bugs in the rewritten code. It takes a more complex collection (or a unique approach to collection design!) to flush out a new bug these days. This program is starting to look good!

In the process of adding a new feature to RADE, another old bug in the Paste Structure code was found and fixed.

More random bugs fixed:

• Refinement of the work done to dynamically resize text to fit in OS X rectangles. More space is taken up by the three-dimensional border, so we have to shrink the text inside the rectangles slightly.
• Lots of bugs fixed for dynamic popups where the data value is different from the menu value, or of a different type than the menu value. Dynamic popup code appears to be fully working now!
• We seem to have fixed one of the more vexing problems (one of those snow drift in a blizzard moments we refer to) that remain: the Activity Dialog — the OS X compliant replacement for changing the cursor to a clover when things are happening — must be thread safe, and it must run on the main thread to avoid all sorts of nasty crashes.
• Holding the option key down to access a query before opening a view now works.
• The Font/Style palette is now active only when a Styled Text field is selected.
• Popups, combo boxes, etc. now respect the printable flag. Previously they always printed.

Sequences are now being scrutinized more throughly. Lots of odd cases have been found and fixed. More work remains. Sequence execution speed is abysmal.

More random bugs fixed:

• Canceling printing no longer crashes.
• Dynamic popup menus properly handle honor cases where the menu value is different from the data value.
• Attempting to focus on a dynamic popup if the popup is still being built no longer crashes.
• Lots of color conversion issues fixed. Mac Classic Mac, Mac OS X, and Windows (i.e: wxWidgets) all have different ways of defining the color space. We think everything is covered now.
• When editing multiple records, after a Replace, the automatic Find Next now starts the next record with the focus on the last field changed, as does Classic Helix.
• All rectangles now respect the printable attribute.
• Clicking checkboxes/radio buttons and popups now send a focus event so the rest of Helix knows when one is changed.
• (Cocoa) Notification set up so we can catch when the user changes from Aqua appearance to Graphite (or vise-versa).
• Other stuff too opaque to try to explain.

Dynamic popups that allow typing (the Helix equivalent to the OS X Combo box) are now mostly working. There are still problems, but the really hard work is done. We also found and fixed lots of little bugs like: specific rectangle types that were not printing, Helix was unable to remember the windows you left open when you last used the collection, specific constructions of views that would disable the Enter command… lots of little things.

Four Steps Forward:

1. The page border and off page areas are now properly drawn. (And the color of both are controlled by preference settings.)
2. The last of the old Scrap Manager API has been removed.
3. Default buttons now highlight (it is important to provide a visual clue) when they are triggered.
4. Dynamic popups (aka Combo Boxes) are close to working. (This is the only item we are aware of that is keeping us from starting beta testing.)

Two Steps Back: Concurrent to the work on Helix Engine, we continue to test our code with Client/Server. Although Helix Server 6.0 runs in OS X, it uses Apple’s ‘Classic’ event based mechanism for regulating network activity. That was a perfectly legitimate first-step when we did it. Unfortunately, updating Helix’s main event loop to modern standards forces us to take the next step now. Here is the blunt assessment of Steve Keyser, the author of the original Multiuser Helix code, and the guiding hand of our successful OS 9 to OS X networking transition:

The basic problem is that Helix can only do one thing at a time. (Concurrent searches are just smoke and mirrors, Helix is never doing more than one search at a time, multiple searches are just being broken into discrete chunks, and anything that interrupts a chunk has to wait.) Mac OS 9 agreed with this philosophy. Its event issuance and window updating events were designed to let one thing finish before the next begins. Mac OS X is more attuned to multi-threaded applications, although single window apps don't have to worry too much about that, multi-windowed apps are expected to be multi-threaded savvy. Since Helix is not [yet truly] multi-threaded, ([Helix contains its own multi-threading code, written before Apple implemented theirs]), we are going to have to find all the places where OS X lets things get started and close them off, so that new activities can begin only when the program is idle and we can keep Helix in its single minded bliss. The [new code trap we inserted] flags the cases where Helix has started a new task without finishing its previous one.

So much for the dream of a painless path to an OS X native Client. At least the OS X Helix Engine continues to make steady progress.

A Side Note: As people starting using Intel-based Macs to run Helix Server 6.0, we became aware of a recurring theme: the Server tended to crash when users were involved in heavy posting operations. Concurrent with that our internal alpha testing on Helix 6.1 revealed a bug in the code that compiles the posting code. This bug appeared to have little or no effect on PPC-based Servers, but we are now starting to see a connection. So if your Helix Server crashes at all, please take time to review the information in this tech note and see if it addresses your situation. You may want to review the information in this tech note as well.

One ‘need to do’ item addressed: command rectangles (buttons) with pictures pasted in now show the picture!

Another week of bug fixes: getting quick queries to work correctly, getting styled text fields to stop claiming they were changed when they were not, getting views with scroll bars turned off to stop scrolling … and more.

Helix no longer crashes when a view with a command rectangle containing conditional sequence is closed while the sequences are running.

Fixed a bug noted on May 21: menu items can no longer be selected while a sequence is running.

Another week of ‘little bug’ fixes: progress dialog thermometers were not incrementing correctly, simply moving the cursor via the keyboard while in a field marked the record as needing to be replaced, problems with conditional styles, views that generate errors if a record is showing when first opened, problems with the home field sequence command… and more.

Some fixes to plain text rectangles never made it into styled text rectangles. (Although most of them did because of the wonders of object-oriented programming and inheritance.) The remaining cases have been fixed.

Two ‘thorns in the flesh’ remain: 1) Combo boxes (as seen in dynamic popup menus) still need work. 2) The menus remain active even when a sequence is running. This is a serious problem — if the user were to activate (or close!) a window while a sequence was running, it could be a disaster. The idea of allowing the user to do other things while a sequence is running is tantalizing, but there are many things that would have to be worked out before that could become a reality.

Collection Designers rejoice: Helix 6.1 looks for Custom Help in the same folder as the collection, making distribution of stand-alone solutions easier. (Helix Client continues to look in the folder with the application, as the remote structure is more likely to move.)

Although we still recommend putting Helix applications in the OS X Applications folder, Helix 6.1 is more forgiving if you move it to another location.

More dialogs (e.g: Why? messages) use OS X alert code instead of old Classic dialog code.

Lots of bugs fixed: The time stamp command should work now. The optionally show dialogs attribute in sequences is now honored. Paste Records works. Visibility attributes for elements on a view all work. Views now autoscroll when tabbing to a field that is outside the display area. Pasted data is now being stored correctly. Fast Find works. Dynamic popups work on the Client. Other esoteric things. As you can see, we’re at the stage where we can test hard enough that lots of bugs pop to the surface. This is both encouraging and frustrating at the same time. But it is progress.

An interesting problem was observed — and fixed this week. Although I don’t want to bore you with the details, it does point to the difficulties involved, so here we go. The originally observed problem was that ‘Keep Values would not Keep.’ But nothing is ever that simple and by the time we pinned it down we discovered that this bug only struck when (a) a field is inert, (b) the relation the field is in has no ert (non-inert) fields, (c) the rectangle that field is in (in a template) is set to Keep Value, and (d) that field is posted to another relation. If all of these conditions are true, the posting failed.

In solving that problem (and another one) an ‘unrelated cousin’ was discovered that may affect you now. In the last month have seen two problems in Helix Server 6.0 that have been traced back to faulty form compiling. One is documented here and the other here. The solution in both cases is to open the collection with RADE and force all of the compiled data to be discarded and rebuilt. Read those technotes for more information.

And here’s a bit of annoyance for you to consider: Helix allows a checkbox field to have three distinct states: true, false, and undefined. Classic Mac OS had no notion of an undefined checkbox, but OS X does. (It is represented as a checkbox with a dash through it.) Unfortunately, the OS X implementation of checkboxes forces us into a compromise. Here’s why: OS X has two checkbox styles, one that allows the undefined state and one that does not. The one that does cycles through the checkbox states in a defined order: true, undefined, false. When you create the checkbox, you have to say which type you want. At first we were simply using the ‘three state’ checkbox for everything. But this does not work if the field has a default value of true. In that case, the view opens and the checkbox is defaulted to true. Now, you decide to change the value to false, so you click the checkbox to toggle it off. But in OS X, the state after true is undefined and as soon as Helix sees the undefined field, it fills it in with the default value (which is true) making it impossible to ever get to the false state.

The only solution we have found is to use the ‘two state’ checkbox when there is a default abacus in the rectangle along with the field. But this means that a Helix construction such as if test then true else undefined can not set the checkbox to undefined, as its checkbox has been declared as a two state checkbox.

That is unpleasant, but considering the rarity of this sort of construction, this is the solution we are going to stay with for now. If you need the ability to default an undefined value into a field, our recommendation is to use an alternative format: radio buttons, popups, and plain text all work fine.

Buttons can now have transparency! Those of you who put graphics in the background layer and overlay transparent buttons can rejoice. In fact, all of the issues mentioned in the April 21 posting have been resolved. All that is left (for now) is to draw pictures in buttons. (Those of you who paste graphics into command rectangles, please be patient…)

Record locking works! And that old bug is squashed. Fixing this turned up some fundamental issues in the way wxWidgets handles focus — which field is active. This is the current focus of effort.

Also accomplished: the viewable on … page settings are working, sequences now enable/disable at the right times, and some dialog boxes have been updated to use the cross-platform API.

The new ‘question of the week’ has to do with the Enter & Return keys. See our newest poll to provide feedback on this one.

Ugh. This week was spent fighting through some incredibly difficult code…

On one front was the button name issue. Helix allows you to name buttons dynamically, using the output of an abacus to provide the button name. There are also options for dimming and hiding inactive buttons and making active buttons transparent. The naming code is mostly done, and it features a couple of immediate improvements as well as being written in a way that will allow us to provide some serious feature improvements down the road. However, there are issues still to be dealt with. Transparency is going to prove difficult, as the Carbon button code only supports transparency as part of the disabling process. Also, Carbon buttons do not allow the label text to wrap to multiple lines. We are working on some solutions, but they probably won’t be easy.

Another engineer spent the entire week working on record locking. (Before this, our OS X Client/Engine did not lock records, and being able to edit the same record on two views — or from two Clients — would be a serious flaw.) On top of that, we discovered a bug that has existed in Helix, apparently from the very beginning:

1. Create a collection with one relation, having two fields. Make a template with both fields, and a default value (just a constant will do) for one of the fields. Make two views using that template.
2. Make a template+view with both fields, without the default value. Use that to enter a record that has an undefined value in the defaulted field.
3. Using both of the other two views, find that record. They will both show the default value. On one of them, change the other field, but don’t hit Enter. That will lock the record. In the other one, hit Replace. That will store the default value, even though the record is locked by the other window.

This bug was addressed while implementing write locking. But even without that problem, adding write locking was incredibly difficult. Both HIView (Apple’s code) and wxWidgets (the cross-platform API) believe that something really should have keyboard focus in every window. Helix assumes that nothing will have keyboard focus if the record cannot be changed because it is locked in another window. The fix involves changes at many levels in the architecture of the program and to intercept keyboard and mouse input at a more fundamental level.

This week was spent trying to get irritating inconsistencies fixed. This is the stuff that makes programming painful. Getting buttons to enable/disable at the correct time, getting the background objects in a template to stack properly, getting dynamic popup menus to be dynamic (and not crash), getting label rectangles with pictures to put the picture in the right place, getting the ‘Option-Enter’ keystroke to be recognized… the list goes on and on.

One ongoing struggle is with ‘popup menus that allow typing’. In OS X these are called Combo Boxes. For some miserable reason, you can tab into them, but you can’t tab out.

Still, the OS X Helix Engine is actually starting to become a usable product.

In case we forgot to mention it: in keeping with our volcanic code name theme, The OS X Client/Engine project is code named Io.

Arrgh! Getting a cross-platform API like wxWidgets to understand the difference between the Return key and the Enter key is a real pain. Add to that Helix’s variations on what Enter means: Enter (aka: Enter/Find), Replace (Replace/Find), Static Enter (aka: Enter/Stay), Static Replace (Replace/Stay), Enter Overide, Static Enter Override, trigger default button, accept dialog box input, …) For the collection designer there is quite a bit of work to do to make sure Enter does what it is supposed to do in all cases.

In the process of updating the code for OS X we have had to sort these out, and in the process, we have made a change to the way Helix works, closing an inadvertent design loophole where a view with a default button could still be ‘entered’ by using the Enter menu command. In Classic Helix a designer who wants to make absolutely sure the user can never simply enter a record — e.g. because the default sequence must be run — must also remove the Enter command and/or remove the Add/Replace permissions for every user for that view. Removing Enter from the user menu creates other logistical problems. Removing specific view permissions from users is an arduous process where errors can easily slip in. Toss in the fact that most designers do not clearly understand the purpose of the Enter Override and Static Enter Override commands and you have a situation where making sure the user can not simply enter the record — and keeping your data sound — can become a complex and time-consuming task.

The revised code treats the Enter menu command exactly the same as pressing the Enter key. If there is a default button on the view, selecting Enter from the menu now triggers that button. The Helix Reference (4.7.3.1) does not explicitly define what was formerly expected to happen in this case; 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. We debated what the wording in The Helix Reference implies about Enter in the menu and concluded that this spec change does not counteract any explicit specification. That conclusion, along with to our desire to close the loophole, plus the fact that this ‘path of least resistence’ to get Helix to OS X, helped make this decision.

This should not be interpreted to mean that an Enter command within a sequence will also take on this behavior. That command (which will be renamed ‘Enter Record’ in the future) continues to simply enter the record on screen. Use the sequence command Keypress: Enter to simulate a keypress/menu selection Enter when needed.

Also note that the Enter Override and Static Enter Override commands placed on a user menu will continue to simply enter the record also trigger the default sequence.

The names of the enter commands as seen within sequences will be changed to Enter Record, Static Enter Record, Enter Record Override, and Static Enter Record Override in Helix 6.1 to make the distinction clearer.

The Import/Export & Copy/Paste Record Options dialog has been reworked for OS X. Much nicer.

Sort Order now has an inndicator to specify the ‘default’ index. (Bold+Italic text)

The Export Ordered code was left in place, but blocked out, since 100% of our survey respondents so far say they never use it.

More bugs fixed.

Sort Order is reimplemented as a toolbar widget. Much nicer.

Styled Text works much better now. (No memory leaks, color support, etc.)

Lots of little bugs fixed: tabbing from field to field is better, static enter works, dialog box response to keystrokes, dynamic popups no longer crash when clicked on, etc.

Open Query is now functional in OS X.

A nagging problem has been fixed: the new view code thought that simply tabbing through the fields in a record was enough to signify a change to the data, and Helix would ask if you wanted to save changes before closing even when no changes were made. This was traced down to a bug in wxWidgets and fixed.

One from the ‘Ugh’ Department: Buttons in Helix have been changed from Aqua Push buttons to Bevel buttons. This was done because Push buttons are limited to specific sizes, while Bevel buttons allow virtually any size, allow pictures instead of text, etc. Bevel buttons provide the feature set Helix designers expect, so although we personally find them ugly, we have to go that way.

Here’s a link to Apple’a HIG Page Showing Button Styles.

One sentence from Larry in this morning’s email: Printing works!

More words: “I think I’ve got all the pieces, although I’m not completely confident that the pieces all work in every combination. Let the bug reports begin.”

This is a huge step forward and, based on our initial in-house testing, may allow us to finally zero in on a time frame for eventual release of OS X Engine/Client.

Printing. This is a huge task, and probably the last (and largest) hurdle we have to cross before serious testing can begin.

Basic page printing is working, now come the details: large templates (larger than one page), suppressing rectangles where "Printable" is off, honoring the "First Page", "Middle Page", "Last Page" check boxes, printing in sequences, handling a Cancel during printing.

More ‘rough edges’ are being knocked off. The Quick Query toolbar no longer opens every time a view is opened. Subforms are now clickable. List selection is now fully functional.

Click to select records on a list, and double-click to open records on a list now work according to the new spec. The new spec resolves an ambiguity by recognizing the difference between double-clicking an unselected record (which does not create an "ad-hoc query"), as opposed to double-clicking a selected record, or one of many selected records, (which does create an "ad-hoc query".)

A single click selects the record that is clicked, and deselects everything else. The first record selected sets an "anchor point", and a shift-click selects only the records between the anchor point and the clicked record (inclusive.) A command-click toggles the selection of a record, adding or removing it from the selection as needed.

Records in a subform list can be opened with a double-click, but not selected. (Consistent with existing spec.)

Dragging over a list of records to select records under the mouse is not implemented yet.

Next up: Bug swatting.

Converting views to run with native OS X controls is long, slow business. Although the views are up and running we have encountered (and fixed) bugs with names like: "Sequences Can Not Be Cancelled", "P# does not display Page Number", & "Scroll bars still visible when turned off." Many more remain, but steady progress is being made.

Be sure to read our final "The Latest Word" of 2006 for a few screen shots.

Next up: picture rendering, selectable list functions.

One round of "obvious bug" swatting complete. Found some unpleasantness in sequence execution, among other things. It’s still not really usable, but we’re making progress.

Display Subforms! The subform code is the most complex piece of code that must be migrated to OS X before we can ship native Client/Engine. It is finally done — until testing starts finding obscure bugs in it, that is.

On another front: Helix Client’s Visit/Open dialogs had to be reworked, and we took the opportunity to add a few nice enhancements.

This page switched to listing event in "most recent first" order. (Because who likes to scroll all the way to the bottom to read two lines?)

Helix Server’s conversion to Xcode has reached the stage where we can start testing this build to see if Xcode has broken anything.

A "first run" Helix Client OS X was built today and successfully connected to the new Server. Another major milestone is passed!

Some bug fixing on the first pass at entry forms is being done.

And during that bug fixing… oh, wow… the "Helix is a processor hog" bug was found and fixed! Or so we think.

The list code has been committed and sent to testing. Subforms are next.

Alpha testing on entry forms continues. List forms are shaping up. The first version you see may not look like much, but the stage is being set for many new features. (As much as we’d like to do them now, we resist so as not to allow the ship date to slip further.)

A giant step forward. Our Xcode projects for Helix have been totally restructured for more efficiency. The all new, MLTE-enhanced view code has been integrated into the revamped project. Our in-house Alpha testing can begin in earnest.

Please note that this does not mean that release is imminent. We still have a lot of work to do. Nonetheless, this is a major milestone.

Popup menu work is completed. Checkboxes and Radio Buttons are up next.

On a separate thread: we now have a proper About Box (complete with live links to our web site and a "current version" lookup) and an Open Recent menu item.

Dynamic Popup menus are nearing completion.

Styled text hit a few snags, requiring a re-evaluation of the code. In the end we discovered that Apple’s Carbon implementation of the Font Panel is a bit buggy (to be kind) and we switched over to using the Cocoa Font Panel. It seems to be 98% right, which is close enough for now, given the time constraints we are under.

The Fixed Point data type was exhibiting some oddness (nothing to the right of the decimal point, funky rounding) but that’s fixed now.

Pictures in template rectangles now draw correctly. Picture fields work fine, except that OS X clipboard does not seem to support the PICT format anymore. We’re studying the issue.

Styled text is working, except that the old Classic "Shadow" type is removed from OS X, so that type of text displays as plain text. (There’s nothing we can do about that, sorry.) OS X Helix uses the standard OS X Font palette (Select "Show Fonts" in TextEdit or Mail.app to see it) to specify font/style data! It all works except specifying a color.

MLTE work nears completion. Views — including Quick Queries — are like a whole new (OS X native!) world. We’re thrilled to be (mostly) past this obstacle.

MLTE work continues. (Did we mention that this is a big project?)

MLTE work continues. (This is a big project!)

The login interface been rewritten to present a single User/Password login window. This adds security since the intruder must now guess both the name and password at the same time. With User Name Security turned off, the login dialog now uses a popup menu (using OS X controls, so it is also type selectable!) to select the user name.

This week (actually, last week) one of the ‘hard jobs’ of converting an old application like Helix to OS X was started: converting from using the TextEdit APIs to MLTE.

What is TextEdit: TextEdit was originally designed to handle editable text items in dialog boxes and other parts of the system software. Although TextEdit has been enhanced to provide more text-handling support since its inception, especially in its handling of multi-script text, it retains some of its original limitations. (From Apple’s Carbon Reference for Legacy APIs)

What is MLTE: MLTE (Multilingual Text Engine) is an application programming interface (API) that allows your application to provide Carbon-compliant Unicode text editing. MLTE is a replacement for TextEdit that offers more features than those in TextEdit—features such as document-wide tabs, full justification of text, support for more than 32 KB of text, built-in scroll bar handling, built-in printing support, support for inline input, support for the advanced font features of Apple Type Services for Unicode Imaging (ATSUI), and support for multiple levels of undo. (From Apple’s Carbon Reference for Modern APIs)

Considering that the time required to replace TextEdit with MLTE is expected to be about the same as updating our old TextEdit code to be OS X compliant, this decision was a no-brainer. We’ll have a better fix on ‘how long’ in a few days.

Note: our plan at this point is to leave Unicode support turned off in the first release of an OS X Client/Engine. We need to fully understand the ramifications of that before adding such a dramatic new feature and work out how this will interact with the existing OS 9 Client.

Adriaan van Os, Mac OS X/Pascal code guru and member of the GNU Pascal Compiler (GPC) development team has signed on as a consultant. Adriaan will be working with us to improve the performance of the compiler and to work through the tricky details of moving our Pascal to Xcode.

With Helix Engine in the hands of testing, engineering turns its attention to creating Xcode versions of the other Helix products. In less than one week the Helix Server project was moved from CodeWarrior to Xcode. The few wrinkles that were found were ironed out quickly. Next up: Helix Client.

Helix Engine is now ready for initial alpha testing. Next week we start running our baseline tests and looking for obvious bugs.

Larry writes: Some more real progress was made today. I got the query window dialog working, and actually stored some data and found it with the query. I checked in my current code...

Progress on Helix Engine has been stalled over window drawing issues. It took days to track down the problem. The old code that draws windows is going to be a problem until we have time to totally rewrite it. For now, we stick with QuickDraw (which has been depreciated by Apple and will be dropped at some point) and give up all the nice things Quartz would give us. Getting an OS X Client/Engine is deemed more critical than having beautiful, anti-aliased text.

Parallel to the main work, there is an ongoing project to eliminate the last vestiges of OS 9 dependent technology. Behind the scenes, we were still using one of Apple’s ancient apps (MPW Shell) to generate the code that gives each type of icon its attributes. MPW Shell is an OS 9 only tool, and therefore destined for the dustbin. All of the scripts that ran in MPW Shell have now been converted to Python and thoroughly documented, so we now have a firm handle on this fundamental aspect of Helix code creation. Next up is the Dynamic Popup Menu code, which is still (believe it or not) written in 68K assembly language!

The best example of where this comes into play is in the copy/paste structure code. Helix’s ability to paste structure from older versions of code requires thorough knowledge of the attributes of the objects, particularly how they changed as new versions of Helix were released. Some of the copy/paste structure bugs we’ve fixed lately were introduced because there was, from 1997 to 2003, nobody working on Helix who thoroughly understood how this code worked.

On a more sober note, this week Larry’s father encountered some serious health issues, and Larry may be sidetracked for a few days. While the rest of us continue plugging away on Helix, we ask you to join with us in praying for the best for Larry and his family.

Larry writes: Helix Engine can now launch cleanly, open a collection, enter records, and save the collection. (This is a major milestone!)

Helix Engine compiles in Xcode, but crashes immediately when launched.

Since Helix Client is, essentially, Helix Engine plus networking, getting Helix Engine converted is a much more efficient way of working on the code. Once Helix Engine is debugged, Helix Client will be mostly complete. (Helix Server is already running in OS X, so our networking code is already there.)

“Update Collection now works.”

Attention turns to moving Helix Engine to Xcode.

Our first product to convert to Xcode is Update Collection. This is chosen because it is the smallest Helix application, which will give us faster turnaround times when making changes. (It’s good to start with a simpler project before trying to tackle a huge one like Helix Engine.)

Converting large CodeWarrior projects to Xcode projects is not the walk in the park Apple presented it as. Many fundamental assumptions (e.g. how many bytes are required to store an integer) must be challenged and revised. Helix code must be painstakingly searched for such assumptions and turned into explicit declaration.

Xcode’s lack of support for legacy Pascal requires that we go on a search for a third party Pascal compiler that works with Xcode. We settle on GNU Pascal Compiler (GPC).

Apple releases Intel-based PowerBooks and iMacs. We accelerate plans to build OS X native Engine and Client in Xcode.

After we "made a valiant attempt at creating a Helix Client with CodeWarrior" and saw that it wasn’t going to work, we made the decision to abandon CodeWarrior and start moving to Xcode. Larry Atkin is tapped to head this project.

We ship Helix Server, Helix Utility and Update Collection as OS X native components.

Attention turns to the feasibility of quickly creating OS X native Client and Engine built in CodeWarrior. CodeWarrior’s general inability to handle our user interface code makes progress slow.