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


Author: Dennis Kolva

Programming Director for Turtle Creek Software. Design & planning of accounting and estimating software.