Author: Dennis Kolva

We are starting to use our own data to test Goldenseal Pro accounting software. There’s lots of small stuff to do, to get it ready for running TurtleSoft.

First step was the sign-on dialog. It’s now a bit better than the current version, with an option to view or hide the password as you type it.

Ever since we switched to Apple’s most recent memory management system, the main window has crashed randomly after switching tabs. We finally narrowed it down to one line of code, but were still baffled. Something was breaking that never should have. It finally turned out to be an old Apple bug in the NSTabView class. We posted details to the Cocoa developer list, and folks gave some suggestions that eventually led to a work-around. Tabs are working properly again. We switched them to newer Apple code, so they even have niftier animation now.

There have been database errors in bank accounts that were converted from old format to new. Duplicate ID numbers. The whole system to give record IDs has always been a problem, ever since Goldenseal 1.0. Its code is confusing. Bug fixes over the years have only made it more confusing. So, we tossed it all and rewrote everything from scratch. It’s simpler now, and will be much easier to maintain.  Software design is much easier after you’ve made every possible mistake already.

We are also about half-way through the Reconcile command. That uses a table. They have been the hardest programming problem so far, in the Mac update. Fortunately, several types of tables are now working, so we can duplicate that code. Our staff futzed around with tables all Winter, but they will go faster now.

I’m not even going to try to estimate completion. Our staff will be finishing features and fixing bugs until it’s done.

Dennis Kolva
Programming Director
TurtleSoft.com

All the basics are now working for the tables in lists and accounts. Menus pop up, check boxes change, and text saves. Our staff is double-checking all of the tables now, to find any small details that may need extra code.

Even better, our staff can use the same basic code for other types of tables. We aren’t masters of NSTableView yet, but at least we aren’t baffled by it any more. The home stretch is in sight.

In the current Goldenseal, the C++ table classes handle mouse clicks, screen drawing, and everything in between. For Goldenseal Pro, NSTableView takes over all the mouse stuff and screen drawing. So, the remaining work will be in the special details in the middle, plus deleting lots of obsolete code.

The first step was to entirely remove the old messaging system from Goldenseal.

There are lots of ways for users to interact with an app: they can click on something, or double-click, or click and drag. They can type stuff from the keyboard. Most actions need to be passed along elsewhere in the code, to actually do something. Most platforms do that by sending a message. Apple’s Cocoa framework is extremely message-heavy. Microsoft’s MFC framework and the PowerPlant framework also use messages, but less so.

The current version of Goldenseal has a few hundred different messages that go traveling around. Unfortunately, the whole message thing turned out to be one of those ideas that sounds great in theory, but never lives up to its promise.

The biggest problem has been that messages are hard to debug. All code starts out with bugs, but what counts is how easy it is to fix them. With messages, the code doesn’t directly explain how it works. One side sends a message and the other side receives it, but there’s no way to be sure it actually gets to the right place. To check it requires 2o or 50 steps in the debugger, instead of just one or two.

Even worse, messages can be sent at the wrong time, or in the wrong order. Debugging that kind of error is a nightmare. Sometimes we have to log every single message, and then try to deduce what’s wrong.

As our staff fixed bugs in Goldenseal between 2001 and present, we solved many problems by replacing messages with simple, direct connections. Often, a complete rewrite was easier than trying to debug and fix the messages.

The original plan was to replace the remaining messages gradually.  But then we discovered an extremely old bug in the Work Crews command. It’s not a biggie, but enough to inspire extra skepticism for the existing code. If we’re going to test every last detail, then there’s little reason to keep any remaining message-based code.  Better to delete it all, and reduce clutter.

BTW the message system inside the Cocoa framework drives us crazy. It’s one of the major reasons why this conversion is taking so long. I’ll complain more specifically in a future post.

Dennis Kolva
Programming Director
TurtleSoft.com

Our staff is back to working on Goldenseal Pro. Right now we are focused on the little tables inside lists. It’s going well, with steady progress each day.

Working with Cocoa’s NSTableView class has been extremely frustrating the past few months, but I think we are finally over the hump.

About a year ago, it only took a few weeks to get the various tables to show data. Back then we were very optimistic. Unfortunately, creating a data entry interface turned out to be much, much harder than just displaying some text.

Apple has two different ways to set up tables: with cells or with views. Last year, we set up all the tables with cells. They are simpler, and we couldn’t find any sample code that used views. Unfortunately, since then we discovered that Apple has deprecated cell-based tables. That means they are officially obsolete, and will eventually stop working.

Because of that, we switched the list tables over to view-based. After everything is working properly there, it shouldn’t be too painful to go back and switch over the other tables, also. After all this effort, we really don’t want to start out with any outdated code in Goldenseal Pro.

During the past month, our staff spent many hours in Excel, fiddling with the spreadsheets that calculate pricing and page details for SmartKnives.com. It was interesting to be writing Excel macros again! That is how TurtleSoft first began, back in the late 80s.

It was also interesting to work with the new Cocoa-based rewrite of Excel for Macintosh. It seems very clunky and awkward, compared to the previous Carbon versions. Maybe we aren’t the only ones who have struggled with NSTableView.

Dennis Kolva
Programming Director
TurtleSoft.com

There’s not much progress to report.

While finishing Goldenseal Pro, TurtleSoft has paid staff and bills by selling rare/retired Swiss Army knives and Leatherman tools on eBay. We have piles of them, purchased from airport confiscations in the Aughties. Cleaning and sorting multi-tools is a soothing break from programming.

A few weeks ago eBay decided to eliminate shipping of knives outside the US. That was about half our sales.  So we are finishing up the shopping cart on our SmartKnives website, a year earlier than planned.

Setup work was already close to completion, so it shouldn’t cause too long a delay. We ought to be back to full programming speed in a few weeks.

Dennis Kolva
Programming Director
TurtleSoft.com

Our staff is making decent progress on member tables (the relatively small tables found in a few accounts, and many lists). Simple ones now work properly. Next were the ‘to/from’ tables used in Tax Tables and a few other places. They are more complicated, but most features work in those now, also.

We also made a breakthrough on the breakdown tables used in Estimates and many other transactions. The current Goldenseal uses two types of tables: category breakdowns let you type in a list of items, while item breakdowns have a list of Assemblies or Cost Items. The difference is not obvious, and it often confuses users. Their code also overlaps by quite a bit. Category breakdowns still need to show allowances and bids, while item breakdowns sometimes use type0ins.

Last year, we decided to combine them into just one type of table. Merging them was not too hard, but they still seemed a bit too complicated.

For example, in Estimates there are 37 possible types of line items. It makes for a very long list of choices in the pop-up menu. Overwhelming. It was also difficult to find short phrases to describe each option properly. The merged version is even worse.

The breakthrough was to add one more column to the breakdown tables. Each line item now starts with a Type column.  It splits up the list, so the Cost Area options are shorter and more logical. That should make data entry easier for beginners (or tired experts).

A year ago, we estimated that tables would take 2 months of programming time. So far, our staff has spent about 5 months on them. There is probably another month or two left, before they are completely done and polished. It was a gross under-estimation, but that has been the trend for this project. Working with the Cocoa library is hard.

Dennis Kolva
Programming Director
TurtleSoft.com

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
TurtleSoft.com

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
TurtleSoft.com

Last week we finished redoing the basic windows setup in Goldenseal Pro for Mac. This time we built the code with the latest OS version (and the latest version of Apple’s Xcode development tool). Xcode now gives better log messages for improper setup, so we could eliminate the errors, one by one.  Finally, everything was proper.

As a result, Goldenseal Pro now runs fine for all OS versions. The former crashes are gone. All windows are also resizable, now. They used to be stubbornly fixed-size, probably because their constraints weren’t valid.

There is still one more big hurdle to overcome.  Our staff has started on breakdown tables several times, but every time we get stuck. Most things work OK, but the basic interface is just not right. We want to have an editable text field appear promptly when you click in a cell. Unfortunately, that basic task has been extremely challenging to pull off.

What we finally figured out is that Apple’s table class (NSTableView) is designed for Finder-like lists.  To change a file name in the Macintosh Finder, you click in the text, then wait a second, then click again. It works that way so you won’t accidentally rename files when you really just want to double-click to open a file, or click-and-drag to move it.

Unfortunately, click-wait-click is not a good fit for Goldenseal Pro. That behavior is deeply baked into NSTableView.

To solve problems like this in C++ and PowerPlant, we would set breakpoints in the code, and then step through line by line to see how the library works. Eventually that leads to a clear understanding of the mechanics. Then, eventually, we can write code that does the job reliably.

Unfortunately, Apple’s Cocoa library is header-only.  Stepping into it show machine language. It is much, much harder to understand than C or C++ code. Even worse, it doesn’t show any of the comments that good programmers add, to help others understand their code. As a result, Cocoa is pretty much a ‘black box’. We have to try things, and see what they do. Then try other things. Maybe we can eventually understand the code, and maybe not.

Best guess right now is another week until we get the breakdown tables working properly, when you click on a cell. After that it will go much faster. Most of the rest is already programmed.

Dennis Kolva
Programming Director
TurtleSoft.com

Every computer app needs to position stuff on the screen. Usually it takes four coordinates for each item: horizontal and vertical positions, plus height and width. The whole setup is called a frame, since it defines a rectangle that encloses the field, button, window or whatever.

Numbers are fine for computers, but not great for humans. We programmers would rather use a drawing program to lay out the screen appearance. Then we can see what we’re doing.

Goldenseal includes a simple drawing program in the Custom Layouts command. It lets anyone drag around fields, and change the appearance of data entry windows, printed forms or reports. Our staff used Custom Layouts to set up the stock layouts. Users can customize anything with it.

To set up the rest of the interface for Goldenseal, our staff used Constructor. It was a simple drawing program that came with PowerPlant, the library we used to build the first Goldenseal. Constructor set up the rest of the appearance that Custom Layouts couldn’t handle.

For Goldenseal Pro, we use similar visual drawing environments built into Xcode (for Mac) and Visual Studio (for Windows). They save a lot of time.

Frames are good enough for a simple screen layout. Everything has its size and place. But, what happens when you resize the window? These days, people expect stuff to rearrange, and stay useful whatever the size and shape of the window they are in. Unfortunately, a dynamic layout is much harder to set up than a static one. There are many complications.

One layout tool that every programming library uses is containers. All the contents of a container will move together. As a bonus, containers make programming a bit tidier. PowerPlant called them panes, Apple’s Cocoa framework calls them views, and Microsoft’s MFC calls them windows (in Windows programming, everything is a window). Containers are generally a good idea, but they do add some complexity.

Cocoa also has separate controllers for each view, as part of their MVC architecture (model/view/controller). Another good idea, but it adds even more complexity.  The main window in Goldenseal Pro has 9 different views, each with their own controller. Even worse, we need to swap several different views into the top bar and main record area, depending on what you are doing. It took a few months to get it all working correctly.

The other layout tool found in modern programming libraries is constraints. Basically, they are a way to bind each item to its neighbors, so it knows where to go when its container moves or resizes.

PowerPlant and Constructor had a very simple constraints system, but we rarely used it.

For the Mac version of Goldenseal Pro, it’s required that we use the constraints built into the Cocoa framework. We tried doing without it, but just got errors. Unfortunately, they are a confusing mess.

Apple started out with a ‘struts and springs’ metaphor, pretty much like connecting screen items with paper clips and rubber  bands. Then they replaced it with an auto-layout feature in the drawing view. It works great for some things, but can’t be used everywhere.

In OS 10.7, Apple added a NSLayoutConstraint class.  Every view needs at least four constraints, and each looks something like this in the code:

It’s much more palatable, and less prone to stupid errors.

Over the past two years, we used frames to lay out some things in Goldenseal Pro. For others we used constraints, with some of each type. The screens looked OK, but we were definitely bumbling around and didn’t always do the right thing. Sometimes we accidentally added duplicate constraints. Some conflicted with others. Some were just plain wrong. Those inconsistencies are probably why the code crashes when we build with the latest versions of Mac OS.

This week we are redoing all the windows to use the most recent Cocoa constraint system. It’s going to be all anchors.  Newer versions of Xcode are better at reporting errors, so I think we can finally get it right.

Dennis Kolva
Programming Director
TurtleSoft.com