Month: July 2022

Our staff has been busy hooking up right-click menus in our new accounting software. They’re a great way to add new and old features.

Add to Favorites is the best so far. It lets you pick which records are visible when you first open the app.

Our current Goldenseal accounting shows each type of records in a separate window. The app remembers their positions when you quit/exit. In theory, you can put Material Purchase in one corner, Estimates in another, etc. That way you’ll know exactly where to find them.

In practice, the interface probably will drive you nuts. Windows keep piling up, until you go on a rampage and close them all. Then, the cycle repeats. Every day, more clutter. For years we’ve been meaning to improve that interface. Now’s the chance. TurtleSoft Pro only remembers what you want it to remember. KISS.

The top bar had some empty space, so we added a Navigate button. It starts out with a few useful links: the About dialog, Help window and Startup Guide from Goldenseal. It took a couple days apiece to get those working. Most likely we’ll add more stuff there, later.

One Goldenseal user turned their Startup Guide into a simple navigation window, with big buttons to open the most common records. It seemed handy, so we’ll add a new Navigator view to TurtleSoft Pro. Another way to get around easily.

We also added tool tips: short help text that appears when you hover over a field. Goldenseal shows the text over on the left, but the new app puts it right below the field. It’s a smidgen better.

Looking to the future, Qt has a QTextBrowser class. It will let us add clickable hyperlinks inside the app. Right now the help window only has plain text, but we eventually it will link it to YouTube videos and pages on turtlesoft.com. We’ll also use QTextBrowser for some data fields, so you can paste links into records.

In general, the new accounting app has plenty of growth potential. After the first version is out, we can add emojis, formatted text, and other built-in features. The advantage of using a framework like Qt is that many improvements won’t require a lot of programming. Someone else has already done most of the grunt work.

Dennis Kolva
Programming Director
TurtleSoft.com

 

 

This week our staff finished the last of the 70+ lists in our new accounting software. 25+ of them have tables that show tax brackets or other details. Those were the hardest.

The way list tables work now is not ideal. If a table cell changes, it notifies the Qt table, which contacts the old Goldenseal table, then the old cell. Sometimes messages go back: old cell to old table to new table to new cell. It’s roundabout, but easier than rewriting a lot of existing code. If Qt ever dies, it also will be slightly easier to swap to some other framework. Hopefully that won’t happen anytime soon.

The very hardest list was Category Systems. It has two tables, with fancier behavior. When you click on a category in the top table, it fills subcategories into the bottom one. The data is also complex: each category has a list of subcategories, so we can’t just do the normal table save. It needed an entirely different way to manage category data.

There also was a bigger problem. The programmer who wrote the interface for Category Systems was not very good. Their code worked, but it was spaghetti. Too hard to understand. After a near-total rewrite, it’s simpler, and about 1/3 as big.

Category Systems are the heart of our job costing software. They organize estimates, then mark expenses so you can compare estimated vs actual costs. Many accounting systems use simpler ways to track expenses, but they miss out on some real benefits.

For one thing, construction companies need at least two ways to group expenses: one for construction work, and one for office overhead. The categories are totally different. For retail you’ll also want two: for whatever you sell, and overhead.

Categories with subcategories are also a good way to choose items when there are many choices. Put in a category, and there are fewer items to look at. Add a subcategory, and it narrows down even further. Subcategories are helpful for construction estimates (choose from 1,000 assemblies) and retail (choose from 10,000 products).

Tables in general are not completely done. They still need code for inserting and deleting rows. Goldenseal does that with control-clicks and shift-control clicks. The new software will use a right-click menu instead. That’s next on the list.

Tables currently use real checkboxes for yes/no choices, but we haven’t been able to get them to look good. We’ll probably go back to √ text as in the current Goldenseal. And we still haven’t figured out how to highlight rows when you click on them. It’s a common question on Stack Overflow, but none of the answers have worked yet.

We also need to tidy up printing and a few other details. In a few more weeks we can start using the app to actually run TurtleSoft. Up until now our staff has done that in a few brief spurts, but each time it ran into a roadblock.

Dennis Kolva
Programming Director
TurtleSoft.com

 

Our staff is still working on the 70+ lists in the new accounting software. Most behave properly now, but the ones with tables are a struggle. They have extra quirks.

For example, Delivery Methods use a “step table” to calculate charges for shipping or deliveries. If you change a row, the next row down also changes. The table makes sure the amounts are sequential, and it fills special text into the last row. Change the calculation method, and the steps can be money or numbers. The charges can be money or percents. The table has a lot of interface for just a couple square inches of screen area.

We want to write general code that works for all the tables. The way source code is organized inside Goldenseal and TurtleSoft Pro makes that harder. Both projects use object-oriented programming (OOP). It was a new concept when we started using C++ in the early 90s. Now it is mainstream.

OOP helps with a big problem: modern apps are complicated. Adding a GUI can easily double or triple the amount of source code for an app. It’s not just the 2x or 3x as much text to write. The code also needs to coordinate with 2 or 3 times as much other stuff. Those numbers multiply, so the net result is 4x to 9x the effort and complexity.

When done well, OOP source code is almost like sentences that explain exactly what they are doing. We never could have finished Goldenseal without tools to navigate the massive volume of stuff inside. OOP made it possible.

Writing our new accounting software means lots of time spent inside that 30 year old code. With hindsight, OOP does have its flaws. The problems are especially apparent for list tables.

In Goldenseal, every list needs several classes to make it work. For example, delivery methods have CDeliveryMethod (data), CDeliveryMethodViewer (interface) and CDeliveryMethodTable (table).

The plus side is that anything related to deliveries is easy to find. It works great if that is what you’re working on.

The minus happens when you try to add a whole new interface. The quirks in list tables are spread out in 60+ different classes. It’s too scattered.

There is an opposite way to program, called a finite state machine (FSM). Most games use one. It puts every possible situation into one huge switch statement, often with 1000s of branches. That can be overwhelming in its own way, but at least everything is in one place. No need to traipse through many files.

It’s not an either-or choice: a code base can use both. We tried writing a mini-state machine for the Qt list table, with branches for each type of list. The verdict? It probably is better, if we had designed it that way from the beginning. But, a major rewrite is too much effort. There are other ways that will take less time.

Still, it was a good experiment. Future iOS and Android apps that talk to TurtleSoft Pro probably will use a blend of state machine and OOP.

Dennis Kolva
Programming Director
TurtleSoft.com

Most of the accounts and business transactions work properly now in our new accounting software.

Right now our staff is tackling the 70+ lists: specs details for accounting, estimating, payroll and project management. They include cost categories, sales taxes, billing rates, payment terms, and more. Many have interface quirks, so we will go through and check all of them.

Some of the work is tweaky little appearance details. Make buttons gray when they don’t do anything. Change the display from money to percents. Get layouts to look good.

The harder part is getting all the parts and pieces to work together properly. Everything is functional, and most things are ready for prime time. But there are still little details here and there that can be improved.

There are lots of moving parts in our accounting software. Smart fields need to listen to their popup button. Ditto for their scrolling list of items. Records listen to the smart field. Eventually they save changes to disk, and post to other records. It all happens with links and messages and actions that get passed around in the code.

I complained about software complexity recently.  TurtleSoft is as bad as anyone, when it comes to making things more complicated. We keep discovering finicky features that we added to Goldenseal between version 2.0 and 4.96.  Some of them take hours or days to duplicate.

For example, Sales transactions have the option to show UPC codes. One user really wanted it. It’s quite possible that nobody else uses it. Right now it’s the only thing still unfinished there. Goldenseal has code to handle it, but we need to figure out how the Qt breakdown table can get at it. That’s 50% of what we do these days. Step through existing code, and decide whether to replace it or burrow a link to it.

Estimates and Payroll Records are the most complicated. Our staff has made a couple passes at them, but I’m sure they’ll consume another week or two apiece. That’s the next project when this phase is done.

One reason we switched over to lists for now is because they are small. If they have quirks, usually it’s just one apiece. If we are lucky, getting them to work will also solve some of the remaining problems elsewhere. Sometimes it’s better to do the easier stuff first.

Dennis Kolva
Programming Director
TurtleSoft.com