Deposit Funds (Oct 13)

Deposit Funds now works properly. Another task done in the big accounting software rewrite. The action commands seem to take about a week apiece. There are five left to do, so they probably will take another month to finish.

The original Deposit Funds code dates from the late 1990s. It’s complicated. Deposits can come from projects, cash sales or billed sales. Later we added rental transactions. Still later we added events (used for our training classes). Sales branches also play a part.

Deposit Funds has a big data structure that gets passed around to each of those classes. It includes a list of accounts, each with their own list of details. Afterwards, the whole mess travels to a bank transaction to actually create a deposit. The code is scattered all over the place.

Bach then, our staff figured things out as we went along. Several people worked on Deposit Funds, spread out over several years. The code ended up as a bit of a Frankenstein. Revisiting it twenty years later, it was baffling. Construction accounting software will always be complicated, but this was much worse.

On top of all that, for the first few years Goldenseal had Payment Receipts. They were intermediate transactions in between sales or project bills, and deposits. Having them made everything twice as complicated and twice as confusing. We finally removed them, and used printed forms instead. Sadly, the code still lived on inside Deposit Funds. Payment Receipts were a bad idea, and it’s time to escape them.

One way to improve software is something called refactoring. Its goal is to make code less confusing and more reliable. To refactor you first break things, then fix them. It’s kinda like doing a gut/rehab construction project, except that the gutting part has to be gradual.

Step one is to remove one bit of code that doesn’t make sense. The compiler then complains, with a list of other code that it breaks. Step two, our staff looks at each error to figure out where and how the mystery code is used. Sometimes it isn’t even needed, so we can delete it. If not, step three is to rename the data and methods to make more sense. Maybe add some comments to explain the quirks. Get the compiler happy again. Then repeat for the next bit that’s confusing.

After a few days of refactoring, the Deposit Funds data structure was about half as big, and the code explained itself. It also was more similar to Pay Bills and Reconcile. That made it easier to connect to the Qt interface.

Sometimes refactoring fixes bugs. Sometimes it adds new ones. Ditto for a major rewrite like TurtleSoft Pro. So, we still need to test everything with real-world data. That phase is coming up soon.

The best way to alpha-test TurtleSoft Pro will be to run the TurtleSoft business with it. Right now is too early to switch over completely, but we’ll run the new code in parallel with the current Goldenseal for a while, and make sure they both act the same. Or in some cases, similar but improved.

It’s ready for that kind of testing now. But the process will work best by having two monitors and two mice/keyboards side by side. To accomplish that requires serious desk de-cluttering, or maybe another desk. Still figuring that out. It may mean moving some file cabinets.

Meanwhile, our programmers have moved on to Project Billing. In Goldenseal that is split up into five different menu commands. We probably can merge them in TurtleSoft Pro.

Dennis Kolva
Programming Director
TurtleSoft.com

Resources (Oct 5)

Our accounting app has tons of C++ programming code for the business logic, data storage and human interface. However, there are places where C++ is the wrong tool for the job.

For example, it takes specialized apps to make sounds and pictures. Screen layouts are possible to build in code, but it’s much easier to design them in a drawing environment. Likewise, the text for menus, buttons and messages is better to store outside the source code. That way it’s easier to tweak them later, or translate them into other languages. All those extra details need to be attached to the software somehow.

During the first few years of Goldenseal development, I didn’t write any C++ code. It was a full-time job designing the estimating/accounting software, and creating icons, layouts, text, etc. At the time, Mac OS used an app called ResEdit to manage non-code resources. They were stored in a separate “resource fork” inside the app.

Mac users could change some details in Goldenseal with the help of ResEdit. It was a way to fix small bugs or customize features. One user translated all the Goldenseal text into Spanish with it. ResEdit died along with OS 9, but there is a free 32-bit app called Rezilla that also can modify Goldenseal resources. Use it at your own risk, and be sure to work on a copy of the app!

These days, software still has resources. Usually they are stored in many little files buried inside the app. Part of our work over the past five years has been converting old resources to new formats. A lot of them migrated into plain text files. We used XML for a while because that’s the current data fad, but simple tabbed text turned out to be easier to maintain, and faster to load.

The past few weeks our staff tackled the last few resource stragglers.

Many Goldenseal layouts have icon buttons. I drew some of them, pixel by pixel. Others were scanned in from a local artist’s ink sketches. They were “icon families” with 2 sizes and 3 color depths (1-bit, 4-bit and 8-bit). It was a relic of the early transition from black & white to color. There also were a few bigger graphics stored as PICT. Both those formats are long gone.

For Turtlesoft Pro, we converted the icons and other graphics via screen shots, cropped in Preview. They now are a couple hundred named files embedded inside the app. When we finish Custom Layouts, there will be an Icon Chooser so folks can add them to screen layouts.

The various clunk and bip and boop sounds were SND resources, also a dead format. There were how-to instructions for the conversion online. It required three different apps: one to read the raw data, one to move it to an in-between format, then a third to edit it into final form. Most survived the update, but a couple will need to be re-recorded.

Screen layouts for Reconcile, Pay Bills and other action commands were stored in yet another format. It was exclusive to CodeWarrior, the app first used to build Goldenseal. It also died twenty years ago. Our staff added code to Goldenseal so it would export layout specs into a text file. Then we edited it down to just table info: column widths, titles and other details. Now it’s much easier to maintain than the old system.

Will users be able to edit the new resources and customize Turtlesoft Pro? Maybe. There are two problems.

First of all, Qt has its own resource manager. It will be a while before we know whether it allows user access. Their final build system is very complicated, and we probably will hire a Qt expert to set it up.

Even worse, both Apple and Microsoft have increased app security. To run on newer OS versions, apps must be authorized and signed, or they won’t even run. Any user changes to the app would probably look like hacking, and be blocked as a security risk. We’ll know more about that after we start making release versions.

Meanwhile, Reconcile and Pay Bills look pretty good. We’re working on Deposit Funds now.

Dennis Kolva
Programming Director
TurtleSoft.com