Author: Dennis Kolva

Connecting your computer to a network isn’t hard, but plenty of stuff goes on behind the scenes to make it work. One part of that is ports: channels that carry a certain type of traffic. The multi-user version of our new accounting software needs one so clients and servers can talk to each other, whether over a LAN (local area network) or an Internet connection.

There are 65,535 possible ports (two bytes minus one). First up are the well known ports, using the first 1,023 numbers. For example, http web traffic moves over port #80, while encrypted https uses #443.  For email, there’s #109 for POP2 and #110 for POP3.

Most well-known ports are already allocated for something. They are much too classy for our accounting software.

Next step up are the registered ports, from 1,024 to 49,151. Only 10% of those are filled. Last week TurtleSoft sent in an application to register #21,587 for the new app. It’s TS as text. Goldenseal has been using #18,259, which translates to GS, but we want to keep them separate.

The Internet Assigned Numbers Authority (IANA) assigns ports. Sadly, they shot us down, and said to use the temporary range (49,152–65,535) instead. We appealed, explaining how users needed something easy to remember. Nope, shot down again.

Then we looked at the list of registered port numbers on Wikipedia. TurtleSoft is not the only one out in the cold. Apple, IBM, Microsoft, Cisco, Minecraft and many others use an unofficial port number rather than a registered one. Apparently IANA is stingy to everyone.

Right now, nobody else has registered GS or TS, and that status probably won’t change. So we will use 21,587 (TS) unofficially for the new multi-user accounting software. In the unlikely case that our port conflicts with some other app, you can easily switch to a different number.

Meanwhile, the networking code is almost finished. Soon we can get back to regular testing and programming.

Dennis Kolva
Programming Director
TurtleSoft.com

Our staff has started testing the networked version of our new accounting software. A contractor wrote the basic code to connect and send messages between computers, and we hooked it into a modernized version of Goldenseal’s multi-user code.

Like the current accounting/estimating software, the new version works over a local area network (LAN). You can connect either by Ethernet or wireless. One computer holds the company file and acts as a server. Other computers log on as clients. The app looks the same for them, but all data comes from the server.

The new software adds something new: connecting over the Internet. Enter an IP address for the server, then sign on just like the LAN version. A Mac or Windows machine then acts like a regular client, just a bit slower.

We’ll also have apps for Android and iOS to make the connection. Those can’t be full version clients: too small a screen, and not enough memory. Instead, phones and pads will have single-purpose apps to enter purchases, log in employee hours, or enter quick estimates. If there’s enough demand, we can app-ify any record window.

The original plan was that servers would need a static IP address. It turns out that may not be necessary. If you don’t pay for a static IP, your Internet provider assigns you a dynamic IP address instead. It’s easy to look up, and the new app can use that. In theory, dynamic IP numbers may change at any time, but in practice they usually don’t. Worst case, clients may need to switch to a different address to reach the server. We’ll test it for a while and see how practical it is to use dynamic addresses.

The whole IP connecting system has an interesting history.  The current version is called IPv4. Each IP address is a 32-bit number, usually split into four bytes with periods between. It has room for over 4 billion addresses.

When IPv4 started in 1982/3, the Internet was still very sparse, so the 256 top-level numbers were passed out like Halloween candy. Harvard, MIT, Stanford and a few other universities each got one. So did companies like Ford, Xerox and Apple, plus the military. Each of those sat on more than 16 million addresses. The leftovers were kept in reserve for future expansion.

An “oops” moment soon came, later in the 80s. By then the Internet was expanding, and the reserves were already in danger. From then on, IPv4 has survived by squeezing out extra addresses and finding ways to cheat. So far it still works, but some day 4 billion won’t be enough.

There’s already a replacement called IPv6, first developed in 1998 and made official in 2017. Rather than expand to mere 64-bit numbers (18 quintillion, or 2 billion for each person on earth), it jumps all the way to 128-bit numbers (340,282,366,920,938,463,463,374,607,431,768,211,456 addresses, or 9 quintillion for each person on earth). Apparently the planners want a system that can cover the known universe.

Qt supports IPv6, so you’ll just have to enter extra numbers to connect, some day. IPv4 and IPv6 don’t talk with each other at all, which will make things interesting.

Dennis Kolva
Programming Director
TurtleSoft.com

There are 689 records in TurtleSoft’s Problem Log, nearly all of them for bugs in Goldenseal accounting/estimating software. Most showed up during the first few years, then tapered off. This year there was a slight uptick because of old bugs caught while testing the new accounting app.

257 bugs are marked as Completed. Most of the others were fixed long ago, but didn’t get a status update. A few are user bug reports that we couldn’t duplicate.

Recent bug finds are usually small stuff: slightly annoying or very rare. However, last week we discovered a serious Goldenseal design flaw. It may be the cause for some mystery errors. The problem will linger on in Goldenseal, but not in the new version.

One handy feature in our software is linked records. There are many ways to see something related. Some are commands in the View menu. Others are buttons in records. You can also see links from clairvoyant/smart fields and from double-clicks on report lines. All those actions will activate a window, then jump to a record (some buttons start a new record, instead).

The system is nifty, but we overlooked something important. What happens if the window was already open, with an unsaved record? It’s an “edge case”. Probably rare, but it may happen. The code tries to save changes, but if it’s too incomplete to save, the record sits in limbo after another one is loaded. When you quit the app the dud record will disappear, but it may cause chaos before that.

Fixing it took a while because we discovered another problem. The different ways to see links were added gradually, with slightly different code each time. Rather than fix four different functions, our staff combined them so only one change is needed. That will make future upkeep easier.

The new accounting software now warns about the unfinished record, and cancels the link. Slightly annoying, but better than creating a mess.

Dennis Kolva
Programming Director
TurtleSoft.com

Last week, our new accounting software finally started to print good-looking sales receipts. We used it to run day-to-day TurtleSoft business for a few days, then took a break to fix all the bugs that turned up. That on/off cycle will continue for a while, with longer ons and shrinking offs.

The nastiest bug was in the memory cache system: code that decides which records to keep in RAM. It zapped some records, but also was the easiest to fix. Just one missing line of code when duplicating records. Easy-peasy.

The most complex bug happens for linked records. It’s a basic interface problem. Goldenseal puts everything in separate windows. It makes a cluttered screen, and needs windows-inside-a-window on MS Windows. The new accounting/estimating app has just one main window with tabs, for a more orderly screen. But it adds a new problem. What happens when you want to see a linked record?

The solution is to pop it into a separate window. In fact, you can still put everything in separate windows if you want.

But what happens if it used to be in a tab? The solution for that is to move tab contents into the window, then delete the tab so they won’t get out of sync. That has been working for a while.

But what happens if you close the window? There’s the bug: the tab is still gone. Slightly annoying. Going window-to-tab is the reverse of tab-to-window, but the code is complex and can’t just be flipped. Our staff is working on that now.

Breakdown tables have always been difficult, and there’s also more to do there. Most things display OK, but Billing Records, Bank Transactions and Payroll Records have more than one type of table. They still need a way to deal with that.

Meanwhile, the subcontractor working on networking is making good progress. Some time in the next month or two, we could use help testing the remote access feature. You’d need a static IP address, so clients can find the test server from afar.

Dennis Kolva
Programming Director
TurtleSoft.com

TurtleSoft just hired a developer to write networking code for our new accounting software. It will allow more than one person to log into a company file over a local area network (LAN), using Ethernet or a wireless connection. The interface will be similar to the one in Goldenseal.

The new accounting app also adds something nifty: log in from remote locations. To make that happen, you’ll need a fast Internet connection on your laptop (Mac or Windows). Also, the server must be on a computer with an Internet connection and a static IP address. That’s something you can get from your ISP (ours costs $10 a month; your service may already include one).

The second half of the project is to build mobile apps for Android and iOS. They will only write a starter version with a user log-in screen and a few fields. Later, our staff will add the guts to make single-function apps for phone or pad. A few ideas come to mind right now:

• Material Purchases/Subs/Other Costs, for expenses entered from anywhere.
• Labor Hours, so employees can enter their hours from job sites.
• Estimates, for quick field generation of quotes.

Networking should be ready soon after the first, early release of the single-user version. Mobile apps will take a bit longer.

Beta versions of our new accounting software are guaranteed to have some bugs and missing features. Hopefully, they will be good enough for daily use. We will update weekly, so bugs won’t linger long.

Goldenseal went through 3 years of alpha and beta status, then a few more years when important features were added gradually.

Fewer things will go wrong in this release, since the accounting and business management code hasn’t changed.  That’s where most of the Goldenseal bugs were during the first ten years.

Dennis Kolva
Programming Director
TurtleSoft.com

Soon after the last post, we abandoned the C++ diamonds, and found a better way to modify breakdown tables in our new accounting software. There’s still more we can do in Custom Layouts, but it’s finally good enough for a first release.

Printing also is coming along. Breakdown tables now print a list of items on sales receipts, which was a biggie. But it’s still not finished. Right now, multi-line fields don’t print anything, thanks to some Qt complications. Popup fields and smart fields do print, but they look like a data entry screen. Our staff found a new approach that should solve all those problems at the same time.

Meanwhile, we just posted on UpWork and Guru.com, looking for a subcontractor to write code for the multi-user version. The first day drew 70+ applicants. Narrowing down to those actually qualified is a gradual process. Hopefully, we’ll learn enough about Qt networking along the way to make a good decision.

Part of the project specs is to make a very simple mobile app for iOS and Android. It’s step one in creating links from phone to home computer, so you can manage purchase, estimates and other tasks while in the field.

Dennis Kolva
Programming Director
TurtleSoft.com

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