Goldenseal Pro Progress Report- Messages (Jan 28)

Last week, our staff finished the back-end code to run member tables. They are the little tables with a list of checkbooks, rental units, tax table steps or other setup details. The interface is also mostly done, but it’s still not as responsive as we’d like. When you click in a cell, sometimes it shows a type-in field, as it’s supposed to. Sometimes it does nothing, or waits a bit.

Apple’s Cocoa library uses messages for almost everything. Every window and field and button works by sending messages around to other things. Right now we are setting breakpoints in all possible messages, so we can understand exactly what’s being sent when.

Unfortunately, this is not the first time we’ve had to deal with message problems.

Back in 1987, Apple introduced a program called HyperCard. At the time, it was by far the fastest way for non-programmers to whip up something interesting. We used it to create a simple construction estimator called Hyper*Estimator.

HyperCard also worked by sending messages. It was our first exposure to a programming problem called race conditions. A race happens when two messages are sent, then travel through the CPU with no guarantee of which arrives first. The winner may be entirely random. Or worse, one message may win 99.9% of the time. That creates a hard-to-reproduce bug in the rare cases when the other message wins. Even worse, the race results can be different on different machines. Debugging is so much harder when it breaks for users but not for us.

Hyper*Estimator took about 8 months to program. Then it required another 3 or 4 frustrating months to fix the obscure bugs caused by race conditions. Programming in HyperCard was fun, but fixing intermittent bugs was exactly the opposite.

The current version of Goldenseal uses the PowerPlant library, and it also included messages. However, its message system is written in regular C++ code. That meant we can step through it, and always know what happens when. Even then, we use messages sparingly. Usually there are better ways to get things done.

It’s still too early to say whether Cocoa messages have race conditions. It’s not something that Apple discusses in their specs. Regardless, the messaging is buried in machine language, so we can’t see what sent each message, or why. It’s very much a “black box”. The best we can do is experiment, and gradually guess at what’s inside.

That’s a nuisance, but Cocoa is no more opaque than HyperCard was. We eventually conquered that, and we’ll conquer this one too. At least for Cocoa it’s just the first click that’s a problem. After that it’s in our code, and fully under our control.

Dennis Kolva
Programming Director


Goldenseal Pro- Table Progress (Jan 15)

Our staff is making good progress on the new interface for breakdown tables. To edit a line item, it now shows a separate window with regular fields.  This design change gets us past some frustrating road blocks. It also seems like a big improvement over the current interface.

Breakdown tables are difficult. They’ve been a struggle in Goldenseal Pro, just as they were for the original Goldenseal. That’s partly because the bar is set very high for them. A big percentage of data entry happens in breakdown tables, so they need to look good, and run very smoothly.

For example, for the original Goldenseal, we spent a full week designing the little button that appears when you click in a table cell that shows a list of choices. For Goldenseal Pro we spent another full week for the same thing. The standard Cocoa popup button didn’t look good in a cell, and it’s not easy to change it.

Users need responsive action after a click in a table cell, and they’ll want to use arrow keys or tab keys to navigate. Cocoa’s NSTableView just isn’t designed to work that way.

Meanwhile, Goldenseal uses tables for more than just transaction breakdowns. Bank accounts include a little table for checkbooks, and Real Estate accounts have a table for rental units. About 30 lists also have tables. They handle stuff like payroll tax brackets, shipping costs by weight, and depreciation by year.

Fortunately, most of those tables are very simple- just 1 to 3 columns, and usually just text or numbers. Even better, they don’t get used very often. For those, we probably can still enter data directly into cells.

Dennis Kolva
Programming Director