Goldenseal Pro Progress Report (Oct 24)

The Windows version of Goldenseal Pro is now caught up with the Mac version. Both show data entry layouts, load records, and move through them with the browser controls.

The Windows MFC library includes something called a combo box. It turned out to be perfect for our clairvoyant fields, which show a list of accounts (or whatever else) that goes into a field. You can click and choose from an alphabetical list, or start typing the first few letters until it jumps to the correct item.

Combo boxes also work for lists that doesn’t change (for example, status options or account classes). In the original Goldenseal, those are in a popup menu, which requires a mouse click. With the Windows combo box you can still do that, but you can also tab into the field, and type to choose. It makes data entry faster, since everything can be done from the keyboard.

When we wrote the Macintosh interface last winter, we used popup menus that require a mouse click, similar to Goldenseal 4.x. But, now that the Windows version works so much better, we will revisit that code and see if we can make it more similar.

Up until now, we have leap-frogged every 2 or 3 months between the Mac and Windows versions. As we move forward on one platform, we often discover improvements that apply to the other. We will continue to leap-frog, but on a faster cycle. The big stuff is out of the way, and the remaining tasks usually take days apiece, instead of months.

Programming for modern computers is turning out to be significantly easier than what we went through, during the 1990s. The libraries are more mature, and the hardware is more powerful. Back then, desktops typically had 4 megabytes of RAM, so we had to be very frugal about what we loaded into memory. Now that the norm is 4 gigabytes, life is much easier.

For example, in the current version of Goldenseal, we look up the data for popups and clairvoyant fields when we first load each record, so we know what text to display. But we don’t store the whole list, since it’s several hundred kilobytes of memory. When you click in a field, the list is retrieved a second time, to build the menu. It means a fraction of a second delay.

For Goldenseal Pro, it’s no big deal if we use an extra megabyte of RAM per record tab or window. Since we need to fetch the lists near the beginning anyhow, we might as well keep them around. That saves some milliseconds, if you click in the field later. We do have to worry about updating issues (what happens if you add an account?), but at least we have more options, now.

Next on the agenda: saving records, and the Find commands.

Dennis Kolva
Programming Director

Goldenseal(s) and High Sierra (Oct 17)

We recently tested Goldenseal 4.96 with the new Mac OS version 10.13, High Sierra. It worked properly, with one possible exception.

High Sierra uses a new file system called APFS (Apple File System). It is optimized to run on SSD drives, as well as hard drives. We were concerned about how well the original Goldenseal would handle it, but the results were uncertain. The first time we used the Save As Text button to create a file, it gave an error message and did not save. That also happened a second time. After that, it worked fine, and the problem did not repeat again for any of the file-save operations.

The error message sounded like it was related to user permissions or app code signing, rather than a file system error. Unfortunately we did not write down the exact text (and then never saw it again). The error occurred with a fresh install of the OS and a freshly downloaded copy of the Goldenseal app, so it may have been related to some quirk in Apple’s code-signing system. Whatever it was, it went away on its own.

We decided to try testing with a fresh install on a different computer, with hopes of seeing the error message again, and actually writing it down. Unfortunately, High Sierra would not install on an external drive, and we didn’t want to replace the OS on the internal. People are reporting freezes and other problems with High Sierra 10.13.0, and we don’t want to get too committed to the new OS until 10.13.1 or later.

So, there may be obscure problems when the current Goldenseal app first saves files on Mac High Sierra, or there may not be. We will appreciate hearing from any users about this possible problem, whether or not it occurs.

Meanwhile, we installed the latest Mac development software (Xcode 9.0) and used it to build Goldenseal Pro. That went smoothly, and it ran fine on High Sierra after zero changes.

When we build any version of Goldenseal, we use something called an SDK (Software Development Kit). The Mac SDK includes Cocoa and other Apple code. Newer SDK versions add features, but also prevent the app from running on older OS versions. For each release we need to decide which SDK to use, since it limits the range of computers that can run the final product.

For now, we will continue to build Goldenseal Pro on slightly faster machines running OS 10.11 El Capitan. Before releasing Pro, there will be a user survey, to help make a better decision on which SDK to use.

Dennis Kolva
Programming Director


Goldenseal Pro Progress Report (Oct 10)

For each Goldenseal software update, we use a fairly standardized development flow. At the beginning, we schedule large changes and major redesigns. Those are most likely to add subtle new bugs, and it’s good to have plenty of time to catch them before users do. As work progresses, we gradually become less daring. Near the end, we only make the smallest of changes, proceeding with extreme caution.

Goldenseal Pro is by far our biggest upgrade to date, so it has been an opportunity to make very large changes to the guts of the software. Some are fixes for design choices that we later regretted. Some is refactoring, to take advantage of modern C++ and modern hardware. Some is just rewriting mediocre code so it is simpler, more reliable, better organized, and/or easier to maintain.

Last week, we merged the two classes that managed the basic data entry interface, and then split off five helper classes. It took some futzing to get everything working together, but by mid-week the code ran just like it did before. The new setup will be much easier for our staff to navigate, over the next few months.

After that, we started on the Windows interface, which was soon ready to load record data onto the screen. It then needed some real data so we could actually run the code and see something.

More than a year ago, we wrote a translator that converts existing Mac files to the new Pro format. It is mostly there so users can transfer their existing data, but it also helps us. We use a converted version of the Sample Company File for testing, which is much easier than creating temporary records. So, we ran the translator code on Windows for the first time, but it gave a zillion errors.

Goldenseal Pro uses a new database system to manage records. However, the translator still uses NeoAccess (our former database engine) to read existing data files. It is old, 1980s-style code that is the C++ equivalent to a crawl space filled with spider webs and mummified rodents. Sadly, that’s what was breaking. Our staff spent a couple days slithering around in the murk, converting obscure 32-bit code to 64-bit. Fortunately, that was all it needed, and the Windows translator now runs OK.

With the prep work finished, we can move on to interface programming. It is a lot more fun! There are frequent small triumphs and visible changes, which makes the effort seem more rewarding. The past few months have mostly been spent slogging through libraries and groundwork, so it’s a treat to switch to more tangible work.

Dennis Kolva
Programming Director


Goldenseal Pro- Farewell to DB_Editor (Oct 2)


Goldenseal’s source code uses object-oriented programming (OOP). That means its C++ code is divided into about 600 object classes, each in separate text files. For example, CEstimate manages all the data for estimates, and CEstimateViewer handles their screen display. Those files are the first places to look, when fixing a bug in Estimates or adding a feature.

OOP is a fantastic organizational tool, akin to sorting your construction stuff into tool boxes, bags, buckets and totes. Goldenseal Pro’s source code contains over 350,000 lines of C++ code, and 150,000 lines of comments. There is no way we could ever navigate it all, without OOP.

Inside the original Goldenseal software, we had two main controller classes to run data entry windows. DB_Editor handled basic window functions, and  everything in the gray regions on the left and top. DB_RecordViewer managed everything in the big colored rectangle on the right. They worked together for loading, scrolling, editing, saving, finding, and anything else involving data records.

Last Spring we connected DB_RecordViewer to the Cocoa and MFC interfaces, and it went very smoothly. We started on DB_Editor a couple weeks ago, but it proved to be more complicated. We fought with it for a while, then decided that the editor class really isn’t needed for Goldenseal Pro. All of its functions can be handled just as easily by other classes, and its basic concept doesn’t make sense any more.

We gradually moved all the code out of DB_Editor last week, but soon discovered a deeper problem. The best place to put most of its code is in the record viewer, since they already work together to manage the data entry process. Unfortunately, DB_RecordViewer is an enormous file. It  had 275 functions, when the ideal is more like 10 or 20. If OOP classes are tool boxes, this is a van stuffed solid with equipment and construction materials. It needs less clutter, not more.

To accomplish that, we will split the record viewer class into smaller pieces. All the find/skip/replace code is now in a new DB_RecordFinder class, and we are starting on others. It’s mostly just copying and pasting code from one file to another, but we will also reorganize and modernize as we go along. The design may evolve.

This code is pretty much the heart of our software, so it’s worth taking some time to make it more understandable. Linking in the new interfaces will be much easier if they connect to a structure that is solidly built, and well prepared. Spending a week or two now can easily save us many weeks of work, later on.

Dennis Kolva
Programming Director