Category: Goldenseal Pro Design

Goldenseal is pretty good at reconciling bank accounts, but our new accounting software is better. The list of transactions loads almost instantly. It’s easier to switch from one account to another. But there still is a rough spot: what do you do when the bank statement doesn’t match what you entered?

Sometimes it happens because of typos, or bad data from faded/crumpled receipts. Sometimes it’s because of Walmart. They have a bad habit of adding an extra penny to sales tax for online orders, but then rounding correctly on the actual charge.  The result is a Reconcile line item that’s off by a penny.

Goldenseal has no easy way to fix that kind of error while the middle of a Reconcile. The quickest goes like this:

1. 1. 1. Remember or write down the error.
      2. Leave the Reconcile window.
      3. Find the bank transaction and change its status to Void.
      4. Save changes. That removes Paid status from the purchase and unlocks it.
      5. Open the purchase, and enter the proper amount.
      6. Go back to the bank transaction, and also give it the proper amount.
      7. Change payment status to Entered, and save changes. That also updates the purchase.
      8. Go back to Reconcile and try again.

More than three weeks ago, our staff set out to improve that. The goal was to do the One Penny Tango in just a step or two. Except, we ran into bugs. Many bugs. One crashed the new accounting app. Several were due to changes in bank transactions. One zapped the purchase record in the database. That took a couple days to track down: a lingering problem in how we mark records as “dirty” so they’ll be saved.

The Walmart problem is almost fixed now. You can double-click in the Reconcile window, and see the bank transaction. Then right-click to see the purchase. You can change them and save, but we haven’t tested the posting yet. That will be tricky. It also needs to update the line item in Reconcile.

Adding those pop-up transactions is a big design change. We’ll need to play with it for a while, and see how well it works in real life. If good, the same thing can happen in all the other action windows: Pay Bills, Project Billing, Deposit Funds, Job Costing, etc.

Linking from one record to another is a big strength in our software. Usually it’s easy to get from here to there. The links also are a PITA for our programmers. They make a complex web, with so many ways to go wrong.

Dennis Kolva
Programming Director
TurtleSoft.com

 

 

 

Goldenseal accounting software rarely crashes, thanks to lots and lots of sanity-checking code. If something isn’t kosher, it gives an error message with the exact source code line that failed. That makes it easy for us to find and fix the bug. Then it exits to the event loop, so you can keep working.

The approach works well, but it does have a cost. Of the 26 megabytes in the Goldenseal app, almost half is just text for error messages. 99% of them will never be triggered, but it’s worth the weight to get quick fixes for the naughty 1%.

Programming the new accounting software works the same way. We rarely see crashes: just error messages and things that don’t work right. However, this week there was an actual crash. It happened after using the Link button to see the bank transaction that pays for a purchase. The dialog worked OK, but the app crashed later.

The bug turned out to be a dangling pointer in the bank transaction. We can’t test for those, so we must never let them dangle.

The accounting app has to keep track of which records are visible, so the screen will update if one is changed remotely. For example, changing payment status also changes the purchase status. In Goldenseal, each record keeps a pointer to the viewer it’s in (or null if not visible). When we post to the record, its viewer is also reloaded (if it exists).

The code is efficient, but a design flaw. A risky way to do the job. This wasn’t the first time the app has crashed there. Rather than slap on a quick fix, we decided to scrub it clean. The new app now checks every tab and window to see if the record is showing. No need for a pointer at all. It’s slower, but only by microseconds.

During the rewrite, a couple other possible bugs turned up, deep in the guts. To fix those, we need to understand the old code better. That means running current Goldenseal in the debugger, to make sure the new app does the same things at the same times. Linking records to the screen is complicated.

Setting up an old machine to run version 4.96 was a challenge. Because of the tough real estate market, TurtleSoft was in two temporary offices in 2023, plus the original and the new. Many chances for important stuff to be tucked away in a miscellaneous box. Some are still unopened.

We finally found an older Mac Mini with proper setup, plus all the wiring and converters it needs. Weather sucks, so app development is moving right along.

Dennis Kolva
Programming Director
TurtleSoft.com

Our new estimating/accounting software still had one unfinished data entry field: a color picker. It’s only used in Cost Categories, for Estimate breakdowns. Colors make it easier to see which items belong to each project phase.

Getting the picker to work was easy: just a few lines of code. Tidying up the source code for colors took longer. Some parts are as cluttered as an attic or garage. Kinda like a 30-year time machine, showing the evolution of PCs.

Goldenseal began when most personal computers used 1-bit monitors. Back then, there simply wasn’t enough memory for more than one bit per pixel. Black & white for Macs, various pairs for MS/DOS.

As RAM increased, colors crept onto the scene. The earliest used just 3 bits: six colors plus black and white. Later, Macs upgraded to 4-bit colors: twice as many choices. There was pink! Light blue! More than just Roy G. Bv. Later, 6-bit and 8-bit became common, expanding the gamut even further.

All those were indexed colors. Each pixel chose from a palette of 8, 16, 64 or 256 shades. For anything in between, you dithered two colors in a pattern. OK when viewed from a distance, but pixelated in close view.

By the time Goldenseal shipped, nobody used less than 8-bit colors (256 choices). Our code supported five different bit depths, but ignored four of them. The system palette was too garish, so we made a custom version that was mostly light tints (for backgrounds) and dark shades (for text).  Data entry backgrounds used 24-bit true colors to get more pastels.

Twenty years later, RAM is cheap. Nearly everyone uses 32-bit colors. Rather than a palette, those have 8 bits apiece for red, green, blue and alpha (transparancy). That’s 16 million shades, good enough for most uses. It’s what we use everywhere in the new accounting app.

Apple goes deluxe, with 64-bit colors in their Cocoa framework. The extra depth is a slight improvement for high-quality photo editing, but overkill otherwise. Few users will notice the difference.

Sadly, for a few years we used Cocoa for the new accounting app. Some of our color code is still 64-bit. Switching between the two sizes sometimes causes bugs, but at least they are obvious and easy to fix. If Qt ever enhances their color setup, we’ll be ready.

For business forms and data entry screens, the old 8-bit palette was perfectly fine. Colors aren’t any better in the new system. In fact, the pickers are more complicated now. Too many choices. However, we updated to full color despite that, because it’s easier. Our staff has better things to work on than a retro popup of 256 color squares, made from scratch.

Dennis Kolva
Programming Director
TurtleSoft.com

 

Bank transactions are the heart of any cash-based accounting software. They track how money moves around.

Goldenseal uses object-oriented programming. For banking, we went overboard with it. There are seven types of bank accounts: cash, checking, credit cards, escrows, investments, loans and savings. Each has their own transactions, which makes 14 object classes. On top of that, there are 5 more for checks, payments, deposits, transfers in and transfers out. Each has a different screen layout, showing slightly different data.

The new accounting app is simpler. There are plain old bank accounts instead of cash/checking/credit cards/loans/savings. The differences have blurred anyhow, thanks to deregulation. Also, there is just one layout for all money going in or out. The change removed a lot of excess code, dropping from 19 classes down to 6.

Using a single layout in the new app was more cluttered, with unused fields causing confusion. This week, our staff fixed that problem. Excess fields now disappear when you switch from a check to a transfer or back. It required some new code that turned out to be very nifty.

In Goldenseal, the title for each field is a separate caption block. Aligning them is a pain, and there’s no way for the code to change their text or hide them.

Bank transactions now create field labels automatically, using text from a resource. They can hide labels or change their text. As a result, banking looks like Goldenseal again.

There are other places that can use the same approach. In fact, we probably should use it everywhere. The advantages: simpler layouts, more consistent spacing, and easier translation to other languages. It’s too big a project to tackle now, but maybe in future upgrades. We can do it gradually.

We also improved another bit of banking interface. In Goldenseal, you can only see transactions for one account at a time. It’s annoying, but we never were able to fix it. The new app shows as many accounts as you want, each in its own tab or window. Major rewrites sure take their sweet time, but they do let us fix basic design flaws.

Every time our staff tidies layouts, we improve Custom Layouts just for our own convenience. The customizing interface won’t be perfect for the first release, but it already looks pretty good.

Dennis Kolva
Programming Director
TurtleSoft.com

If you ever looked up something in a phone book or dictionary made of paper, you probably used binary search. Open to the middle, check which direction you need to go. Split that half in the middle. Repeat until success. It’s faster than a page-by-page linear search that starts at A.

If you ever played 20 Questions, you also used binary search. The same process, only with all possible things. Is it bigger than a breadbox? Does it exist within a mile of me? Is it inside this house? Good questions can find 2²⁰, or about a million choices. Only noobs start with “Is it my uncle’s left eyebrow?” That should be question #20.

Last week, our staff found a minor bug in the new accounting software that took a full day to fix. We probably should have used binary search to solve it, but we didn’t. The Reconcile command sometimes showed the wrong name for transfers between bank accounts. Debugging started at the table display and worked backwards. It was step by step all the way to bad data in the file. The conversion from Goldenseal 4.9x skipped a value. We must have run the code 50 times to discover it.

Linear search does have its good points. You start at one end and keep going. No need for fancy splitting. No risk of accidentally missing something. People don’t use pure binary search on phone books or dictionaries. After getting down to a few pages, it’s easier to stop splitting and just go 1-2-3.

Goldenseal is built with a database library that once used pure binary trees, as on the left:

We changed it to eight branches per node (right image), and everything ran faster. Turns out that a mix of binary and linear search works best. Later, we upped it to 32 branches at each node. That was even faster.

The new accounting app uses very broad trees: up to 1024 branches per node. They’re more like creeping shrubs or ground covers. Wide trees are speedy, but they waste space. Right now an empty file starts at 12 megabytes. We may tweak that design before final release.

Dennis Kolva
Programming Director
TurtleSoft.com

For income taxes, there are two ways to do the math: cash or accrual. Goldenseal accounting software includes both.

Cash accounting is based on when money changes hands. It’s all about bank transactions. Expenses come from payments by check, credit card or cash. Income comes from deposits received for sales, project work or rentals. It’s simple, so most people do taxes that way.

Accrual accounting happens when you earn money, or someone earns money from you. Expenses come from equipment and labor hours, material purchases, subcontractor and other costs. Income from sales happens when you sell the item, even if you are paid later. Rental income accrues when rent is due. Project income is complicated. You need to calculate or guess at the value of work completed at any given time.

Job costing is an accrual variant that is useful for construction accounting. It takes accrued expenses for each project, and matches them up with the original estimate. If you do it right, job costing will calculate that value of work completed, and let you know whether the project is over or under budget.

This all leads up to a tech problem we had recently. A user followed the instructions for pre-paid deposits on time & materials work. Some reports gave bad numbers. We suggested various workarounds. Most made it worse, or broke something else.

I think the root of the problem was because Project accounts are designed for accrual, not cash accounting. Paying to them on account is a cash thing that comes from the wrong side of the fence. Our final suggestion was to make down payments to the Customer account instead. They are better at dealing with cash. The down payment will show up in the Billing Statement, which is already designed to resolve everything.

Our staff needs to chew on this problem for a bit. Maybe we should add specific code to handle down payments for T&M work. Maybe it’s better to keep projects completely separated from cash income. Right now, you can receive money on account from a project, but that may be a mistake.

Goldenseal’s philosopy  is to enter normal business transactions, then get financial reports from that data. That won’t change in our new accounting software. Usually it works out OK. Sometimes there are IEDs.

Dennis Kolva
Programming Director
TurtleSoft.com

 

 

A rare but nasty bug has been lurking in Goldenseal for years: one that can erase the data in a record. It happens in our own TurtleSoft accounting file, maybe once every 2 or 3 years.

Last week our staff experienced it while reconciling bank accounts. There were clues to the cause. We started a find for Material Purchases, then switched to Other Costs and posted a payment. It seemed to zap the purchase record that was active before the find. All fields were blanked out.

Later testing could not duplicate the problem. We tried all sorts of things. It must need very specific conditions. There’s still a missing piece to the puzzle.

Rare bugs are always the hardest to fix. For now, the best advice is to not do a Find and then leave it dangling while you do something else.

Yep, even after 20+ years of polishing, Goldenseal is not perfect. The root of the problem: accounting software is complicated. Probably more so than a house or a car. There are thousands of moving parts inside. Sometimes they interact in strange ways. Houses have evolved for a few thousand years, and cars for 150. They still have problems. So, perfection probably is impossible for our accounting software. The best we can do is make it as reliable as we can.

One thing that helps is refactoring. It’s the software equivalent of remodeling: tidying up, modernizing, improving the design.

Whatever causes the Find bug, the new accounting app probably won’t do it. We rebuilt its interface. Goldenseal uses the data entry layout for Finds, and switches everything into find mode. The record is still there, and vulnerable. The new app has a separate Find panel, instead. It’s totally separated, and safer. We couldn’t do that in the original app. Memory was too tight. But now we can throw around an extra 100K of RAM, and get a better design.

Goldenseal is an old app, started back when Macs used 680×0 chips, and Windows ran on 386 and 486s. Screens were small. Hard drives and RAM were tiny. Processors were slow. In house years, it was about 1885. The software equivalent of lead plumbing, knob-and-tube wiring, and 8×8 sill beams rotted to sawdust.

On top of all that, the C++ language was only 5 years old when we started to use it for Goldenseal. Object-oriented programming was very new. We made plenty of design mistakes. Now the language has matured, and our staff is more experienced. The tools and the workers are better, this time around.

Meanwhile, our staff spent most of the past week refactoring code in Custom Layouts. We want to make the new data format 100% reliable. It was a major overhaul. For example, Goldenseal has about 20 different classes for the things you drag around in Custom Layouts. The new app uses one class for everything. It’s simpler code that is easier to debug.

Updating has sure taken a lot of time, but the next generation is more solid.

Dennis Kolva
Programming Director
TurtleSoft.com

 

 

We plan to abandon or delay a few Goldenseal features, when we update to the new accounting software. Please let us know if you adore any of them, and don’t want to see them go.

Import and Export: Export in the File menu saves data to a text file. It can move the entire company file, or parts. Import reads text, and adds records to Goldenseal. The commands helped us to save sample data before version 1.0. They also came in handy for everyone when the file format changed in 2001. We haven’t used import/export since then. Probably ditto for other users. Rather than take a few weeks to update the interface, it seems better to just retire the commands. Instead, you can make a report, then click Save As Text.

Fonts: Goldenseal uses an ID number for fonts. That is how Mac OS 9 managed them. It worked OK when choosing from a dozen basic fonts. These days, PCs come with hundreds of font families. There’s no good way to number them, so modern systems refer to fonts by name. They can swap in something similar if the requested font is missing. We will add modern font-handling and Unicode in a future rewrite of Custom Layouts. Until then, all text will be Arial. Maybe we can add a hack to offer a few more fonts, but it’ll be better to wait and do it right.

Date/Number Formats: The first release of TurtleSoft Pro will ignore most custom formats for dates and numbers. That’s another thing that needs the new Custom Layouts. Qt is good at international formats, and we can take advantage of that. They also have an auto-translate feature that may let us release versions in Spanish, French and other languages.

Payment Receipts: Goldenseal 1.0 came with an optional transaction to print sales receipts. It was an extra step in between Sales or Billing Records, and bank deposits. Then we added receipt printing direct from the sale or project bill, so Payment Receipts were disabled in 2005. Records in that class will not be imported into TurtleSoft Pro. It may cause error messages if you work with ancient sales records, but the removal won’t do anything worse.

Web Visits: TurtleSoft used these for a while to track raw traffic to our website. It showed the truth about pay-per-click ads: 99% were bots or third world click farms. After that, logging wasn’t worth the effort. Web Visits will disappear unless we hear otherwise.

Multi-User: The first release will only be single-user. Networking needs a total rewrite, and it’s too much to tackle now. Multi-user will be a high priority once the basic version is out.

Time Tracking: I’m pretty sure this feature didn’t survive the update to Mac OS X. It’s only practical over a network, so it won’t be in the first release. Employee time tracking will be much more useful when you can log in from a phone app. Once we have a few of those set up, it will come back.

Chart of Accounts: The very first accounting interface for Goldenseal had a screen full of account icons. You could drag money bags between them. It was cute, but awkward to actually use. We renamed the window to Chart of Accounts, and exiled it to the top of the View menu. Its code is a tangled mess, from a programmer who wrote spaghetti. This is the last of his work that hasn’t been rewritten or removed. Unless we hear a whole lotta love, it’s gone forever.

Dennis Kolva
Programming Director
TurtleSoft.com

 

 

 

 

 

Turtle Creek Construction computerized in 1986, soon after the Mac Plus came out. Microsoft Excel was our go-to app for almost everything. It worked great for construction estimates. Less ideal for job cost accounting, but good enough. We even used it to print invoices.

TurtleSoft began in 1987. Retail has more data and less math than construction. We soon found that Excel wasn’t the best tool for selling estimating software. Luckily, we discovered FileMaker. Together, the two apps met most business needs. Problem was, they didn’t talk to each other. Neither app could do it all on their own.

Goldenseal accounting software happened because we needed a better way to run things. It was frustrating to enter everything twice.

From the beginning, Goldenseal was built for our own software business, as well as for construction companies. We made it look like what we already used every day. Breakdown tables copied Excel, mostly. The rest of the interface came from FileMaker. The look and feel were different enough that we didn’t get sued.

The biggest addition was posting. Enter material purchases, and Goldenseal posts them all over the place. It creates instant payouts or adds to Accounts Payable. It updates job costs, T&M billing for projects, and current prices for estimating. It adds things to inventory. That’s what was missing from the Excel/FileMaker combo.

Almost all Goldenseal business transactions do some posting. They also link to related records with a button, a menu or a double-click. Connections make the data more useful.

Posting is what our staff has been working on the past few weeks. Most of the code was already OK as is, but some was affected by design changes.

TurtleSoft Pro is less like FileMaker, now. Our staff has learned many new interface tricks since the 90s. But, some of the improvements affect the posting process. For example, Goldenseal pops up a bank transaction window when you pay for a purchase. That’s not so easy in the new single-window interface. We finally decided to skip the extra window. Often it was just distracting. The PAID watermark already lets you know it’s done.

Bank transactions changed, and that affects almost everything. It’s not just that we merged the former cash, checking, credit card, loan and savings accounts. The old app also used different layouts for deposits, checks, payments and transfers, plus even more layouts for breakdown tables. Now, everything shares the same layout. It’s simpler, but different.

Action dialogs also do a lot of posting. Reconcile, Pay Bills, Deposit Funds and Job Costs work well now. We’re currently testing Project, Sales and Rental Billing. Last on the list is Write Payroll.

Payroll was the last thing we added to Goldenseal accounting software. That and estimating took a few years to get completely right. Likewise, they will be the last things to be finished in TurtleSoft Pro. The basics are already done for them, but their quirks may take a few weeks.

Dennis Kolva
Programming Director
TurtleSoft.com

Our staff went on a rampage last week, and deleted many C++ classes from the TurtleSoft source code.

Some were left over from the early days of Goldenseal development. Back in the early 90s, computers were s-l-o-w. It took at least 7 minutes to compile the app after any change. Bigger changes ran over lunch, or overnight. Really big ones took all weekend. It would have been even slower if we didn’t use the fastest possible hardware, at $7K a pop (1992 dollars).

For the first few years, TurtleSoft had two or three programmers. Because builds were so slow, we split many classes into parent/child files, using C++ inheritance. Smaller files were quicker to compile. Each programmer also could make changes on their own assigned files, without affecting the others. We merged files every Friday, before the big weekend rebuild.

TurtleSoft wasn’t the only code base using many generations of small classes. The PowerPlant and NeoAccess frameworks were also that way. Cocoa and Qt still are.

Having many small generations does have some advantages. But it’s more confusing, and it sure makes debugging harder. It’s kinda like having tools in a case in a bag in a toolbox, inside a cabinet in a truck in a garage. You’ll spend more time fetching tools than using them.

The frenzy started last week while adding right-clicks to smart fields. The None option erased the field OK, but the text came back later. Arrrrrgh! Debugging the problem went deep into old Goldenseal code. Four different classes were involved. Too confusing. We merged them into one class, and deleted the others. Then it was easy to fix the problem.

It felt so good that the rampage continued. Popup menus, buttons, checkboxes and text fields all shrank. It was like popping C++ pimples.

Once you start swinging a wrecking bar, everything looks like a wall that should come down. So we went through the list of source files, and deleted more that were obsolete. Another twenty or thirty bit the dust.

Shrinking the code base saves compile time, but that hardly matters these days. Even on a cheap Mac Mini, a full rebuild takes 62 seconds or less. Most changes only need a few seconds. The biggest gain is reduced clutter, so programmers are less frazzled and more productive. It helps to have a tidy workplace.

After all that fun, our staff got back to regular programming. Plenty of little details that still need work.

Testing sometimes turns up obscure bugs that have been around for years. For example, the warning about customers going over their credit limit is too strict when you change an existing sale. We found that by accident while testing something else. Now the code is more complicated, but exactly right.

Dennis Kolva
Programming Director
TurtleSoft.com