Category: Goldenseal news

Two months ago, our staff was ready to start serious testing on the new accounting software. Again. We do that by “eating our own dog food”. That means daily use to run TurtleSoft and SmartKnives. It was at least the 30th time we’ve done that. Each attempt gets a bit further.

What stopped us this time was printing: invoices and sales receipts were ugly. Custom Layouts is the way to fix that, but it still was missing some things. While adding those, all sorts of other bugs turned up, and were fixed one by one.

Printing is better now, but still not complete. It’s down to extra gray when drawing rectangles, and an ugly breakdown table. Sales receipts need one of those to itemize multiple items, and it needs to move down a bit to look good. Fonts are different, so some column widths need a tweak.

All that happens in Custom Layouts, and it stirs up a C++ problem. To change the table’s position, it has to act like the other fields: a click shows handles, and a drag moves it around. To edit columns, it has to be a table: double-click in a column shows details to change, drag on the edge of a column changes its width.

TCQ_LayoutField is our C++ class which handles the clicky and draggy stuff. It’s a type of QWidget, the Qt class that draws stuff on the screen (plus other tricks).

TCQ_Table is another C++ class which makes a spreadsheet-like table. It has children that handle each place it is used: in breakdowns, lists, reports, and printed forms. TCQ_Table is also a QWidget.

Custom Layouts has a TCQ_TableLayoutField which acts like both. The C++ way to do that is to give it two different parents. Normally that is no big deal, but this time it creates a dilemma. There are two paths to QWidget: which one to take? It’s called diamond inheritance. Kinda like incest, but for screen objects.

Up until now, TurtleSoft has never made any diamonds. There always has been a way to avoid them. We tried a few ways to make that happen for TCQ_TableField, but all had serious problems. So, right now we’re trying the diamond. When the compiler complains, we just need to tell it which branch to take.

This is a bold experiment in advanced C++ design. Tables still don’t drag right in Custom Layouts, but we’re working on it. Worst case, our staff will toss a few days work and try some other way.

Dennis Kolva
Programming Director
TurtleSoft.com

People usually procrastinate when projects begin, then rush around at the last minute to finish. It’s all because of net present value.

NPV is an accounting calculation that gives the current value of a future asset/liability. Getting money today is better than getting it next year, so NPV uses a percentage for risk/interest/opportunity cost to adjust from then to now. Multiply that by the time delay then subtract, and you get present value.

Likewise, spending time or money next year is better than doing it today. The math says: the more you can push to the end, the better.

Net present value is not something we calculate in our accounting software (though depreciation is almost the same). NPV is a planning thing, not bookkeeping. If you need it, Excel has a function to give a number quickly.

Allocating time and effort is important for survival, so every living thing seems to have an internal NPV calculator. Usually, it says “don’t think too far ahead”. In fact, humans have a much longer time horizon than most other species. Excepting beavers and orcas, maybe.

Work on TurtleSoft’s accounting software has gone that way. At first, completion seemed close: just a year or so to finish. So, the project was all-consuming. The expected reward was large, and worth whipping out in that time frame.

When things proved harder than expected, work slowed down. Other projects with nearer rewards took precedence. Then Covid took massive attention for a spell: fear of dying will do that. Despite all the barriers, programming did continue. Just slowly.

Now that the end is in sight, the new accounting software gets more attention and time. That probably will accelerate.

It also helps that TurtleSoft is firmly settled into its new home. The garden did great this summer, thanks to work put in over the past year. Some construction still needs doing, but nothing major. No more relocations are on the horizon. Finances are solid, unlike the final push to finish Goldenseal. That version was built on massive credit card debt. There’s much less anxiety, this time around.

Dennis Kolva
Programming Director
TurtleSoft.com

Back in July, our staff needed to tweak TurtleSoft’s printed forms so we could test the new accounting software in daily use. It meant adding more features to Custom Layouts. Every time work seemed to be finished there, something new came up. There have been many “last on the list” items.

Rich text is last on the list (so far……..). It’s what you see here: text with bold, italic, font changes, and other formatting.

The good news is, rich text was easy to add to our multi-line fields. One line of code, setAcceptRichText(true); was enough to turn it on.

The bad news is, Qt does it in a weird way. From the name, we figured they’d use RTF (rich text format). It’s a simple markup language developed by Microsoft in the 1980s. RTF is supported by MS Office and many other apps, and it would be perfect for our accounting software.

However, Qt uses HTML, instead. It’s probably a wise choice for the long term, since everything seems to be web-based these days. But HTML is way overkill for an accounting app.

For one thing, their approach is bulky. Every field has at least 465 bytes of hidden markup text: even if it’s empty. Basically, they set up a whole web page. Actual content can easily have more hidden HTML tags than text. RTF is much more compact than that.

Also, Qt only has partial support for HTML and CSS. It ignores php and JavaScript completely. So, text pasted from web pages may lose some details. Pasting from RTF has similar problems: some things don’t make it over because the tags are different.

Even worse, there’s no way to edit formats while inside our new accounting software. Text must be created in a word processor or other app that handles HTML, then pasted in. You can’t just type in rich text, nor can you change it after it’s there.

Qt does have classes to set up a rich text editor and/or an HTML viewer. But they’re complex, and meant for whole scrolling windows, not database fields. A mini text-formatting bar would be nice, but Qt doesn’t have one. Our staff does not want to program one from scratch. It’s a several-month project.

For contracts and spec-writing, HTML may be worth the downsides. Elsewhere, probably not. So, rich text is turned off by default in the new software. Custom Layouts has a checkbox to turn it on, for fields where you really want the fancier formats.

Rich text is slightly nifty.

Dennis Kolva
Programming Director
TurtleSoft.com

 

On a whim, our staff pasted some emojis into the new accounting software last week. It worked! The text saved fine to the database, and displayed properly. Much easier than expected. It’s all thanks to Qt’s robust support for UniCode.

Unicode is the standard format for all kinds of text, these days. It includes Ελληνικά (Greek), Українські (Ukranian), 한국어 (Korean), and any other language on this planet. Plus ♔♕♖♗♘♙, 😝🍑🏈🔥💩 and more.

This is one area where it really paid for us to procrastinate. Computer text has had some difficult times, but we missed most of the pain.

A typical English-language typewriter or keyboard has 47 printable keys, give or take a few. With shift and space bar: 95 characters. ASCII is a 7-bit system (128 choices) that’s big enough to handle it. Leftover slots are used for line feeds, tabs and the like.

Apple expanded ASCII to 8 bits. That’s what Goldenseal uses. The extra 128 characters include diacritics (ßàæçñòóôõö etc), Greek letters, extra currency symbols, and fancier punctuation. Other companies also expanded ASCII, but everyone used different setups. It’s why you’ll sometimes get emails with weird symbols.

8 bits is sufficient to cover most European languages. But move east, and there are whole new alphabets. Too much for just one byte.

For a while in the 90s and early Aughts, the solution was wchar_t. It’s 16-bit text, with 65,536 possible characters. That’s enough to hold alphabets for Britain, Thailand, and all points between. Wide characters support العربية (Arabic), کوردی (Kurdish), हिंदी (Hindi) etc.

That era was not fun. Some things still needed ASCII, some needed wchar_t. Use the wrong one and you’d get gibberish or worse.

Microsoft created a special hell, with LPSTR, LPCSTR, LPWSTR, LPCWSTR, LPTSTR, LPTCSTR, CStringA, CStringW, bstr_t, CComBSTR, WCHAR and TCHAR, all for different types of 8 or 16-bit text. There were equally obscure ways to convert between them: CW2A, C2AEX, etc. Use the wrong one and code would crash: sometimes suddenly, sometimes randomly later.

Move on to East Asia and wchar_t had another problem. China/Japan/Korea use ideographs: a different symbol for each word. Many thousands of them in each dialect. 2-byte text lacked space for them, so it wasn’t good enough for global use. It also was twice as bulky for regular Latin-language text.

Unicode fixed all that. It’s a clever system that mixes characters of different sizes: anything from 1-byte Latin to 4-byte 𒁎 (Ancient Sumerian). With over 4 billion possible glyphs, there’s room for every human language, current or extinct. Plus music notation. Emojis. Dingbats. Weird math symbols. And plenty more.

Even better, Unicode converts easily to UTF-8. That’s an 8-bit format that programmers can use to treat Unicode just like simple Latin text. Thanks to UTF-8, text-handling code inside our new accounting software accepts Unicode with no need to rewrite anything.

The new accounting app will have a few problems with Unicode, but nothing serious. Find works OK with special characters or emojis, but sorting won’t know what to do with non-Latin text. You’ll need to be careful with fonts: none support the entire gamut of Unicode, and some may be Latin-only. Other quirks may arise.

The next thing for us to test is rich text: with multiple fonts and formats inside. The Qt class we use for multi-line fields supports it. If we’re lucky, that also will be easy.

Dennis Kolva
Programming Director
TurtleSoft.com

Custom Layouts is almost complete in our new accounting software. The biggest item still on the to-do list is pictures.

Goldenseal stores pix as binary data inside the company file. It uses Apple’s PICT format: once the most popular way to store bitmaps and vector images, but now obsolete.

Qt supports BMP, JPEG, PNG and a few less common graphic formats. But it can’t read PICT. We also couldn’t find any C++ code to do that. Sadly, when you convert your company file from Goldenseal to the new accounting app, any pictures will be left behind. Screen shots are the easiest way to salvage them.

The new business software stores all pictures as external files. You can put them in the TurtleSoft folder inside Pictures, or anywhere else that you choose. The database just has some text: a path to the folder location and file name.

There are trade-offs to the new system. On the plus side, it makes the company file smaller: no huge chunks of binary amongst the accounting and estimate data. Editing pictures is easier. There’s no need to export/import, just open them with any graphics app.

On the minus side: backups are more complicated. Switching to a new computer means moving more than just the app and company file.

File paths are good for more than just graphic images. They also can link to PDF documents, Excel spreadsheets, or anything else. Those files won’t display inside the accounting software window. Instead, they’ll launch the app that created them, and open in a separate window. Links also can use an Internet URL: those will open a browser page.

Goldenseal didn’t start out storing pictures inside records. We added them piecemeal to a few classes: first Cost Items, then Estimates, then a few more. In the new accounting app, any record class can store a picture, file link or website URL. The coding is easier that way.

I think pictures and links will be useful in many new places.

Dennis Kolva
Programming Director
TurtleSoft.com

 

 

 

TurtleSoft released Goldenseal accounting/estimating software in 2000. It wasn’t long before we wanted to change it. New apps are never perfect in version 1.0. Heck, automobiles have been around for 138 years and they’re still getting big rewrites.

There’s a problem when we add new data fields. Users may already have records with the old setup, so the new code must accept two different arrangements. The solution is to use a file version number. When you read from disk, the code branches, depending on the version. Some data classes have changed many times: the current maximum is 9.

Layouts for data entry screens, reports and printed forms also need a version system. For example, we added help text to data fields in late 2000, then to buttons in 2001, then to breakdown tables in 2002. Each change added more data to read, so layouts also need different versions. The current max is 14.

For users, versions are invisible. For programmers, they are a PITA. Branches are easy to screw up. They clutter up the code base, and cause hard-to-find bugs.

Our new accounting software is a chance to start fresh. Once you convert your Goldenseal accounting file into the new app format, it bypasses all the old version branches. Some day we can delete them.

Likewise, new layouts are stored as text, not binary. Some day we can clear out the complicated code that reads Goldenseal layouts. In fact we won’t need many versions from now on, since text is less fussy than binary. We can add stuff at the end of a line and just continue if it’s not there.

Versions are one reason our staff has taken so long for the 64-bit replacement. We want to make all the big changes before the first release. Getting it right at the start avoids headaches later.

Meanwhile, our staff is still working on Custom Layouts. It’s now possible to add new fields and graphics. Colors can be partly transparent. Circles and ovals finally draw right, after much frustration. Lines are still a challenge. You’d think they’d be simpler than rectangles, but they’re not.

Dennis Kolva
Programming Director
TurtleSoft.com

Goldenseal accounting/estimating software is 24 years old. It was designed for the smaller screens of the 90s and early 00s, with pixels at 72 dots per inch. Since then, screens grew bigger and pixels shrank. Expectations of what an app should look like also changed to suit the bigger space.

Our new accounting software needs to fudge Goldenseal’s layouts to make them look OK on modern hardware. It has code for most problems: text expands from 9 points to 12, fields get bigger. The approach is similar to the Magnify feature in Goldenseal, added in version 4.3 to solve the same issue.

Even with adjustments, layouts still looked cluttered. So we added code to shift the right column over by 10 pixels. Plus a few other tweaks. Sometimes Mac and Windows need different treatments.

The code hacks makes most screens look better, but some are still ugly. We’ll need to adjust those individually, using Custom Layouts. Our staff spent the past couple weeks improving it: the work is nearly complete. You now can export layouts to a text file or import them back. Most of the nifty tools are working.

Editing a text file looks like a decent way to tweak layouts. Every value has a label, and most make sense. We also made a few changes to improve the new text-based system.

About the only thing left unfinished is pictures and logos. We did most of the work for those last year, but it’s time to make a final version. I’ll talk more about that in a future post.

Dennis Kolva
Programming Director
TurtleSoft.com

 

When printing, the new accounting software currently puts everything onto paper or PDF, but it looks ugly. Right now our staff is working to make their appearance as close as possible to Goldenseal’s. It means another deep dive into Custom Layouts, the user interface that lets you change the appearance of just about anything in the app.

One update is in date formats. Goldenseal uses this dialog:

It’s complicated for users. Complicated to program. In fact, the sample date at the bottom sometimes won’t update properly: a very old bug that we just noticed.

The new software uses the Qt method, which is similar to Microsoft Excel. Just some text: M/d/yy = 7/26/24 and MMM d, yyyy = July 26, 2024, etc. It’s easier for users, and simple to program. No need to futz with radio buttons.

There are other details still unfinished in Custom Layouts: money and number formats, table setup, fancy font details. Some of those would take weeks or months of work to look like Goldenseal. For example, it has this complex dialog to set up report tables:

The new accounting software saves layouts as text, internally. We plan to avoid a ton of interface work by exporting and importing those. Then users (and our staff) can make fancy changes in a word processor or spreadsheet app.

We just need to figure out how to make the process as obvious as possible. Or at least less scary than that report table dialog. It was a monster to program, and not easy to use.

Dennis Kolva
Programming Director
TurtleSoft.com

 

 

 

We just fixed the problem of huge files in our new accounting software. It was caused by a couple stupid bugs in the code that decides where to save changed records inside the file. Zapping one got the TurtleSoft company file from 11 gigabytes down to 1.5 gigs. The second fix shrank it to 85 megabytes: bigger than the current 64 megs in Goldenseal, but that’s expected. We added a few things.

Our staff is back to using the new accounting software for our own business, in parallel with Goldenseal. As soon as there’s a month without serious bugs, it’ll be time for a first release.

Why did TurtleSoft write its own database code? Well, if we were just starting now, we’d use something free and open-source, for sure. Let someone else write the code to manage data on disk.

That was the original plan for Goldenseal in the late 80s, also. Our first estimating & accounting templates hit the limits of MS Excel, so we needed to switch to a real app. Open source software didn’t exist back then, so it needed to build atop something commercial.

First, we tried a dozen different databases and other development platforms: FileMaker, FoxBase, Omnis, etc. All had fatal flaws (usually lack of spreadsheet-like breakdowns for estimates).

We finally decided to write the interface in C++, and license an object database called NeoAccess to manage files. Neo was popular at the time, especially on Macintosh. It worked pretty well, up until we started to test with real data. Uh oh, there were crashes, corrupted files, and weird error messages deep in NeoAccess code. Emails to their tech support went unanswered. Soon the company disappeared.

Searching the early Internet showed internal emails from AOL, Netscape and others also searching for solutions, and/or making plans to give up on Neo. We were in too deep, and had no better options. So our staff spent a year rewriting NeoAccess to be more sturdy.

Most of the work was just making the code readable, so we could figure what it did. Several definite bugs turned up. We probably fixed others accidentally. That made it good enough for the 1.0 release. A couple years later, there were more updates to Goldenseal’s database code. Those fixed the last of the leftover bugs.

Our new accounting software inherits the good parts from the original NeoAccess design. Plus the good parts of what we changed and added for Goldenseal. Plus a few improvements, based on 20+ years of experience afterwards.

One thing that’s different now is gap tracking. It helps keeps files compact, even though records change size and need to move elsewhere.

Neo used CNeoFreeList to track empty spaces. Actually, many of them, scattered within the file. We replaced them with a single DB_GapManager, doing the same things but easier to debug. We also added a DB_FileManager, a list of where each record was in the file. It made double-sure that records would not write on top of something else. Later, it also allowed recovery of data that was lost when a NeoAccess index became corrupted.

Tracking gaps is complicated. Removing a record may leave a gap of the same size, or it may widen a gap that it touches. Remove a record with gaps on either side, and three gaps must merge into one. The system worked, but it was too complicated.

For the new accounting software, DB_GapManager is gone. Computers are fast enough now that we just zip through lists of record locations and sizes, and compute gaps between them. Simpler and more reliable, once the stupid logic bugs are fixed.

DB_FileManager is also replaced. Goldenseal sometimes ran out of memory because the manager was so big, so we now divide the file into bite-size sectors. DB_SectorManagers each handle disk space for 16,000+ records. Our company file has 13 sectors. There’s room for 16,000+ more, enough to manage 256 million records. There’s a way it can go beyond that, if ever needed.

BTW Google still shows a few hits for CNeoFreeList, 20+ years after its death. It’s mostly users back in the Aughties, trying to fix error messages and crashes in various apps.

NeoAccess caused pain for many Mac software developers, big and small. Other people’s code is not always the best answer.

Dennis Kolva
Programming Director
TurtleSoft.com