Category: Goldenseal news

Tables are an important part of the Goldenseal interface. They are spreadsheet-like rectangles with a list of details, arranged into rows and columns. Many accounting transactions include breakdown tables. There are similar tables in some types of accounts, and many of the setup lists. Almost all reports use a table. So do the action commands like Pay Bills and Write Payroll.

When we started on Goldenseal back in the mid-90s, computers only had 1 to 4 megabytes of RAM. A construction estimate might have many hundreds of rows in its breakdown table. Multiply that by 18 columns, and a table could take up a significant chunk of available memory.

We built Goldenseal using the CodeWarrior compiler. It included an LTable class in its framework, to manage the rows and columns in a table. LTable was designed to be very frugal with RAM. It did not include much code to manage table appearance or behavior. As a result, Goldenseal has thousands of code lines to handle all the nitty-gritties of tables.

This week, we got far enough along on breakdown tables in the Mac update, to realize that the raw table code is due for a major overhaul.

For one thing, we now have plenty of RAM available. No need to be frugal, so we can redesign table data storage so it’s easier to understand and maintain. On the Mac, we also need to do less. NSTableView (the Cocoa table class for Mac) is already a full-fledged table maker. It handles most of the interface, so our code only needs to store data, and handle the business-specific details. More than half our existing code is unnecessary on the Mac.

We started to delete stuff, but then reverted. It seemed wise to double-check the Windows version, first. Since February our staff has only worked on the Mac version, so there were many changes to sync before we could run the Windows version again.

It turns out that Windows does not have a table class  in their MFC framework. That was surprising, since Excel was the main reason that Windows succeeded, and it is just one big table. There are some open-source table libraries out there, but when we checked them, none seemed worth adopting.

Fortunately, we already have code to draw and manage tables. For the Mac, we will bypass it, but for Windows we’ll still use it. What we can still do for both platforms is improve the basic code that manages tables.

Goldenseal uses object-oriented programming, but for some reasons our tables did not use objects for rows, columns and cells. NSTableView has them, and it makes everything much easier to understand.  Our staff is about half-way done with rehab work, to add them.

Dennis Kolva
Programming Director
TurtleSoft.com

 

In the past couple weeks, our staff has been working on bank transactions, the Find command, and breakdown tables.  No major snags. Progress has been steady. It’s mostly just a constant process of testing, finding bugs, and fixing them. Rinse, repeat.

When writing new software, you might say that the code starts out as 100% bugs. Nothing works at all. Then, it gradually shrinks down to near 0%. For a major upgrade like this one, maybe it starts at 60% bugs.

Similar to construction projects, software has its phases as the structure gradually approaches completion. Most things move in spurts, often with months between them.

For example, the current version of Goldenseal accounting software uses four different types of bank transactions to handle checkbooks, cash, loans and credit cards. We decided to combine them into one. There are currently five different layouts for checks, payments, deposits, and transfers in/out. Those will also combine into one. The change is good for the long term. There will be less code to contain bugs, and a simpler interface for users. In the short term it means extra work.

Our staff finished the database changes for bank transactions more than two years ago.

Bank transactions are unusual, because each window shows transactions for just one bank account. Everything else groups all accounts together. That means some fancy coding for the menus in Goldenseal. We’ll still keep that setup for Goldenseal Pro, since most people work with one bank account at a time. But the accounts will now show individually in the outline view instead of in pull-down menus. We finished that work more than a year ago.

Current users have data that they’ll want to keep using. That means we need to convert it to the new format for Goldenseal Pro.  It’s complicated because expenses and income transactions link to the bank transaction that paid for them, and they also need converting. We finished that last Winter.

Goldenseal currently uses a special window layout for banking, but we wanted to simplify that. We moved fields around and got the new windows working last week.

The basics now work for bank transactions, but some bugs probably still lurk. We will meet and conquer them as we finish banking reports and the Reconcile command, and start using it with our own data.

A similar spurty development process is happening for the Find command, breakdown tables, and every other aspect of Goldenseal Pro.

Dennis Kolva
Programming Director
TurtleSoft.com

 

As mentioned in the last post, we recently switched to a newer memory management system (ARC). That caused a crash after opening list windows. Switching back fixed it temporarily, but we want to use the newer system. Unfortunately, there weren’t many clues to help solve the problem.

One good approach for mystery errors is to eliminate details, and make the setup as simple as possible. We gradually removed everything from the window, but even when completely empty, it still crashed. A brand new empty window also crashed. That was good progress, actually, since it eliminated many possible culprits.

Many of the accounting screens have More Info buttons that show a smaller window that contains more fields. It uses very similar code, and it still works fine. We copied that window, but it crashed. Then we copied all the code that creates it, and it worked OK. Yesterday we changed that working version bit by bit, until it crashed. Then went back a step, and finally got lists working again. It’s not 100% clear why it was breaking, but at least we know approximately how to fix the error, if it happens again.

We use C++ for most of our programming. It’s a programming language with a reputation for being very hard. One reason for that is because the programmer needs to manage memory. It requires care and skill to avoid crashes and memory leaks.

Many newer languages are ‘easier’, thanks to built-in memory management. The Cocoa library also does that with ARC.  It sounds great in theory, to have software that manages memory for you.

I think the best analogy here is that C++ is like a regular car or truck with a stick shift. Hard to learn, but reliable once you learn it. It does what you expect. Cocoa, Java, and other modern languages are like a self-driving car. It’s way easier, and practically lets you snooze while on the road. But occasionally the system won’t see a stationary bus, and you’ll drive into it at full speed. That’s pretty much what happened, the past couple weeks.

I think we will stick with ARC, because it is working fine otherwise. Maybe we won’t hit many more stationary buses.  Or we will get good at spotting buses on the horizon.

The Cocoa library for Macintosh can be extremely frustrating, but sometimes it works like a dream. For example, Interface Preferences has a couple of popup buttons that show a lists of fonts. It took about 30 lines of code to get it working in the original Goldenseal. We did a quick search, and copy/pasted two lines of code. It now shows a standard font dialog. Cool!

Meanwhile, we are going through each data entry window, and fixing the occasional problem or missing feature. For example, bank transactions currently shows a running total on the left side of the window. Goldenseal Pro uses that space for the outline view, so it can’t go there. However, we have a bottom bar similar to Excel’s, and it’s the perfect place for that kind of text. It has been empty for quite a while, but now it shows useful text. We also added a built-in progress bar to replace the current window.

Running a construction business is complicated. Estimating and accounting are complicated. That makes Goldenseal a complicated program. There are many quirks to get working again. The good news is that most of them are easy to convert. They are close to instant gratification.

Dennis Kolva
Programming Director
TurtleSoft.com

 

 

Last week’s switch to ARC (Automatic Reference Counting) seemed to go without a hitch. Our staff was cruising along, finishing up the Preferences window and a few other details. Then, we went to edit a list on Wednesday, and the app crashed. It never did that before.  Xcode usually shows a ‘stack trace’ that explains what went wrong, but this one only had the program entry point. That’s a very hard crash.

A while back I mentioned that the completion date for Goldenseal Pro depends mostly on how many curve balls the Cocoa framework throws at us. Each is different, but here is how we are handling this particular problem.

When there are no clues, the first thing we do is to step through the code to see exactly where it goes wrong. The process can be tedious, but usually it ferrets out an obvious error. This one turned out to be tougher. Sometimes the window would crash immediately. Sometimes it would open and stick around for a few seconds, then crash. Sometimes it would wait until we clicked something. There was no smoking gun in the code.

That delay made it seem like it might be caused by ARC deleting something prematurely. Sure enough, turning off ARC made it work OK again.

Apple has several diagnostic tools that can help with memory errors, including something called NSZombie. We tried them, and discovered that the window itself was being deleted too soon. Very odd. Nothing in the code should have done that. We stepped through the code many times, but didn’t find a smoking gun.

98% of the time, when something doesn’t work we can figure out why, and make a fix that makes sense. Then there is the other 2%, where our staff is totally baffled, and has no idea what’s going on. This is one of those.

One approach that sometimes helps is to go back to older versions and see if they also break. Finding the date when things go bad really narrows down the possible culprits. Unfortunately, older copies also work fine without ARC, but break with it.

Next step was to start deleting things from the window. That usually narrows the problem down to one specific control. Except it didn’t. The app crashed, even with everything removed.  Very odd. Along the way, there was an error warning for a button that was deleted last year. Also odd. A search in the code didn’t turn up any mention of it, but Xcode thought it was still there. That suggests some sort of file corruption in Xcode’s layout data. Why it would only break under ARC, we have no idea.

The list window was the very first Cocoa we worked on, almost two years ago. We made many mistakes and changes, so it is the most likely file to be corrupted. The solution is to just build it again from scratch. That’s on the agenda for today. We will add a few things at a time and test it frequently.

In general, the goal is to have very few changes made between working and failing versions. Then it’s easier to see what’s wrong.

Meanwhile, if we turn off ARC, lists work fine. If we turn it on, everything else still works fine. So we added some code to make it easy to switch ARC on and off. Now it just requires one line of code, instead of 100 changes. That way we can proceed productively, despite this curve ball.

If the rebuild doesn’t fix it, this may be the kind of problem where it’s best to just give up for a while. Sometimes an answer appears out of the blue, weeks or months later. Or, sometimes we accidentally fix it when we fix something else.

To be continued…

Dennis Kolva
Programming Director
TurtleSoft.com

 

Our staff spent the past couple days updating Goldenseal Pro to use ARC (Automatic Reference Counting).  It’s a nifty feature that is Cocoa’s third generation of memory management.  We actually thought it was already turned on by default. But, while checking some other compiler settings this week, we discovered it wasn’t.

Memory is a big deal to programmers. As Goldenseal runs, we create thousands of objects. Each is a chunk of memory that stores some data and does tricks. We give each object a name, then the operating system decides where it will live in RAM.

In C++, we need to decide when each object dies. If we kill it too soon and try to use it after it’s dead, Goldenseal will crash. If we forget to kill it, there will be a memory leak. Accumulate too many leaks, and the app will consume more and more RAM. Eventually the program will get very slow. It may even consume all available memory and crash.

Fortunately, modern C++ has many tools for managing memory, to make sure each object is deleted properly. They help Goldenseal to leak very little, and almost never crash. Some other software is not so careful. For example, most web browsers are very leaky. Use them all day, and they will gradually use up many megabytes or even gigabytes of memory.

Cocoa used to require manual memory management, similar to C++ (but without the modern tools to help). In the mid-2000s it added garbage collection (also a feature of Java and many other programming languages). Garbage collection prevents leaks by periodically checking every object, and killing it if it’s no longer being used. That prevents leaks, but also can be annoying. If you ever have an app suddenly stop dead for several seconds, its garbage collector probably is “emptying the trash”.

Apple added ARC in 2011. It automatically kills each object when nothing else uses it any more. For example, dozens of objects die whenever you close a window. It makes memory one less thing to worry about.

For ARC to work, we had to add a __bridge keyword, every time we convert between C++ and Objective-C.  The compiler colors it bright green. It’s actually kinda nice to have it in the code. The conversions are risky, and anything that makes them more obvious is a good thing.

In general, our staff spends a lot of time looking at brightly colored text. Source code is a huge mass of comments, objects, functions and programming commands. It can be overwhelming. A bit of color coding really helps.

Dennis Kolva
Programming Director
TurtleSoft.com

How to classify things is a problem in both estimating and accounting software. It’s particularly difficult for job cost accounting. Expenses come in randomly, and you have to match them to vendors, jobs and categories.

One important principle in interface design is that people can recognize something much faster than they can recall it. It’s one reason why buffets are popular. No need to remember General Tso’s name. Just scoop and eat. 

Typically, software uses popup buttons for list choices. You click, see the list, and then choose what you like. However, that approach doesn’t work well for long lists (over 30 items). They get too hard to navigate. Popups also require a mouse-click, which is inconvenient when data entering from a keyboard. 

Bruce Tognazzini, the author of Apple’s Human Interface Guidelines, proposed a solution to both problems in the early 1990s. It’s a text field you can tab into. But, when you type, it shows a scrolling list, and jumps to the nearest match. Tab out or hit the enter key, and it selects that item. If you’re not sure what to type, you can also click and scroll until you see what you want. He called it a disambiguating field. At the time, FileMaker had a lookup field that was sorta like that, but his version was better.

In our older MacNail software, we didn’t even have popup menus. Users had to type in a number or letter code to do job costing. Finding a better way to handle long lists of jobs or categories was one reason why we abandoned Excel, and built a stand-alone app in C++. We copied Apple’s specs but called them clairvoyant fields, slightly less vague than disambiguating.

Programming clairvoyants required a text field, plus a temporary table for the list, plus a popup button to choose items with a mouse click. Interactions between them were complicated. Users could do many things with the mouse or keyboard, and the code had to handle them all. Lists might contain thousands of items, so it was challenging to get decent performance on 1990s hardware. We spent a full programmer-year getting clairvoyant fields to work right.

Since that time, both Macintosh and Windows have added a combo box control. It’s almost identical to the original disambiguating field, so we were delighted that we could use them for Goldenseal Pro. Kinda like, we had to build them from scratch back in the 90s, but now you can buy them at Walmart.

It took a few hours to get combo boxes working on Windows. A few days for Macintosh, but we ran into a problem. If you typed something not in the list, it just added that text. OK for some uses, but not for job cost accounting. You don’t want to start posting expenses to the Snith job just because you made a typo.

Apple’s web page for combo boxes said it was possible to restrict them to existing items. Our staff couldn’t find sample code to do that, and couldn’t figure how to make them work right. Eventually we built a replacement from a text field, temporary table and popup button, just like before.

Doing it that way was still just as complicated. Three or four times we got frustrated, and went back to the Cocoa combo box to try again. Then we kept reverting, and gradually perfected the built-from-scratch version.

A few weeks ago, we posted to Apple’s Cocoa-dev mailing asking for help.  Unfortunately, nobody there knew how to make them work right, either. Almost everyone insisted we should use popup buttons instead of a combo box. Out of desperation, we actually tried popups as suggested, but most of their old flaws still remain.

So, the dream of easy Mac combo boxes was just a dream. Windows has a simple yes/no option to restrict to existing, and you’d think that Cocoa would do the same. But, nope.

Building combo boxes from scratch has taken some time. Fortunately, after a couple more weeks of effort, they are working well. Unfortunately, they will look slightly different between Mac and Windows, and we may need to give them different names.

Dennis Kolva
Programming Director
TurtleSoft.com

 

I recently came across an article explaining why it’s hard to estimate programming projects. Still, our users want to know when our Pro update will be finished, and we do too. It’s worth a try, even if the effort is guaranteed to be flawed.

March was the last time we estimated a completion date for Goldenseal Pro, and that predicted mid-October. We just updated the data. The revised spreadsheet also calculates mid-October, but only for the Mac version of our new accounting software. It adds another 2.5 months to finish the Windows version.

It’s still very much a guesstimate. The work in our code is going about as expected. However, occasionally the Cocoa framework throws a curve ball. When that happens, it can take a few extra days or weeks, to finish something trivial. If there are a lot more curve balls, the work could easily drag on a few months longer. It’s an unknown unknown. We really won’t know what we don’t know until it’s over.

Some of the prep work for the Mac version will probably make the Windows update go faster. It’s even possible that Windows part of the estimate is too conservative. But the MFC framework does throw a few curve balls of its own. Those are the main uncertainty.  However, on the whole it is just less complicated to program for Windows. It definitely will take less time than the Mac.  Working with the Cocoa framework is difficult.

Apple has a Cocoa listserv, mostly viewed by developers building software for Mac and iPhone. We have posted a few questions there when stumped. Usually, the other programmers are stumped also. The list does not get much traffic. Likewise, Stack Overflow and other programmer exchanges have few recent posts for Macintosh Cocoa. Nearly all recent questions are for Swift and iOS.

Apple is ending support for Carbon and 32-bit apps in 2019. You would think there would be more developers in our position: rewriting and updating existing Carbon apps to use Cocoa. On the other hand, there were many Mac programs that did not survive the transition to OS X. Moving to Cocoa is even harder, so many developers may have decided to retire. In all honesty, if we had known 3 years ago how difficult Cocoa was, we’d have thrown in the towel then, also. But, our staff is now close enough to completion that it would be absurd not to finish.

I did remodeling work for an accounting professor who had a clever explanation for why people under-estimate projects. Essentially, one big difference between humans and other mammals is that we look further ahead. Building a house or a dam might take 10 years to break even, and no other species would make that gamble. Beavers and apes do a bit of long-range planning, but only on a span of months.

Human brains could have developed stronger foresight, but evolution is random. It uses the first thing that works, even if inferior. So, maybe humans brains just adjusted by under-estimating the cost of big projects, and over-estimating the rewards. Delusion has the same result as wisdom.

Anyhow, Goldenseal Pro looks much better than the current version. It will be good in the long run. It’s good that we were deluded.

Dennis Kolva
Programming Director
TurtleSoft.com

 

 

 

This week we are finishing up the last interface details in the main window for Goldenseal Pro. We like how it looks, so it’s time to release the second alpha version. To download it, click here.  It runs on Mac OS 10.11 (El Capitan) and newer.

We still are not using it to run TurtleSoft, and this version is definitely not ready for actual use. But there are two things you can do with it, that will help us (and you).

First of all, please check out the new interface, and let us know what you think of it. There is still time for us to make changes or improvements. It’s easier now, than later.

Secondly, please try converting your company file to the new format, and let us know if there are any problems. That way, we can fix them before final release.

Follow these steps to run the conversion:

1. Just to be extra careful, make a backup copy of your current company file.
2. Add .glds to the end of your company file’s name, if not already there.
3. Download the alpha version if you haven’t already done so.
4. Double-click on the zip file to decompress it (if your browser didn’t do that automatically).
5. Open the GS-Pro-Alpha folder, and double-click on the GS-Pro-19-Jul-2018 application icon.
6. If your security settings give a warning about an unidentified developer, right-click on the app icon, and choose Open.
7. When it asks you to open a file, locate your current company file, and open it.
8. The app will ask you if you want to convert to the new format. Click OK.
9. The app will ask you to save the new file. Give it any new name, choose a convenient location, and save it.  Your current file will not be changed.
10. It will take a minute or two to convert your data to the new file format. When the conversion finishes, you’ll see a report of what happened, and any problems that occurred.
11. Choose Quit from the Goldenseal menu.
12. Double-click on the new file to open it. Take a look at the new interface. Let us know what you think of it!
13. If you experienced any problems with the conversion, please let us know!  We will fix them, and make sure your file can be converted before the final release.

Dennis Kolva
Programming Director
TurtleSoft.com

When viewing records in accounting software, it really helps if you can tab from field to field. That way, users can keep their hands on the keyboard while doing data entry, with no need to click in each field.

For the current version of Goldenseal, we wrote our own tabbing code, back in the late 1990s. It wasn’t too hard. Each window already stores a list of fields in front-to-back order. When you hit the tab key, it finds the current field, looks through the list for the next editable field, and selects it. For shift-tab, it looks in the other direction. Tabbing in tables is a bit more complicated, but not by much. The entire system took about one programmer-day to build.

Last week, we started to set up tabbing in Goldenseal Pro for Macintosh. The Cocoa framework includes an automatic tab system. They even brag that “you don’t have to write any code” to make it work. We turned it on, but it didn’t work.

Next attempt was Cocoa’s manual tabbing system. It uses what’s called a linked list. Each field is linked to the next field in the list, until you loop back from the last to the first. We set that up in Cocoa, but it still didn’t work. We read Apple’s documentation and checked Stack Overflow, but found no answers. We searched for a sample project with tabbing, and didn’t find any.

Next, we tried stepping through the tab process in the debugger, to see where it was failing. Unfortunately, Cocoa is very much a “black box”. Unlike the other frameworks we have used, it has no visible source code. The debugger only shows machine instructions, which are usually too low-level to be helpful.

When that failed, we went back to our previous approach. Go through the list of fields, and find the next one. To make that work we have to intercept the tab key, and then highlight the next field. Those both turned out to be difficult tasks in Cocoa.  Eventually it worked, but it sure wasn’t easy. Altogether, it probably took a programmer-week. The only good news is that some of what we had to learn will be useful for other things.

Apple’s Cocoa framework is the only major framework that hides its source code. It’s definitely an impediment. We have been working with Cocoa since September 2016, and it’s definitely the hardest framework our staff has ever experienced.  A while back we calculated an October 2018 completion date, but that probably will be pushed back a few months. The only good news is that Cocoa is hard for everyone, not just us. When the Mac goes entirely 64-bit in 2019, a lot of our competitors will be gone.

Ironically, Apple’s Unix operating system code (Darwin) is open source.  That means its source code is not only visible, but editable by qualified developers. Unfortunately that doesn’t help us, since our type of programming entirely relies on Cocoa.

Speaking of open source, it’s an option we are considering for Goldenseal’s code. 

Dennis Kolva
Programming Director
TurtleSoft.com

 

Goldenseal accounting software was designed for a one-button mouse. It’s all that was available for the Mac back then.

Goldenseal Pro is modern, so we can also use the scroll wheel and right-button. Last week we started on the first of the right-click commands. They are a much better way to access some details. For example, when you click the popup button next to a clairvoyant field in the current app, you’ll see a few options down at the very bottom of the menu. They let you enter ‘none’, edit the selected item, or add a new one. A few specialty fields add other options.

In Goldenseal Pro, you access those commands with a right-click. It’s much easier to find the commands (especially when the list is long). Right-click menus are easy to program, so we’ll be adding them in other useful places.

When you click the popup to edit or add a record, the current Goldenseal opens a modal dialog. It’s a separate window that takes control until you hit OK or Cancel. Modern versions of Mac and Windows both use drop-down panels instead. Panels work the same as the old modal dialogs, but they are attached to the current window. That makes them easier to find, and more logically attached to what you are already doing. Goldenseal Pro uses panels for almost everything that used to be in a modal dialog.

There are many places in Goldenseal where we show linked records. For example, in a Project account you might click a button to see Material Purchases for it. When you pay for a purchase, it shows the Bank Transaction that pays for it.

The current Goldenseal opens a separate window for linked records. The end result is often a bunch of different windows scattered about. Our own TurtleSoft file usually has 10 to 20 windows open. It makes the screen very cluttered. Eventually we close them all, but the clutter soon returns.

For Goldenseal Pro, we can use panels to show linked records, or tabs in the main window, or separate windows. As we start to use Goldenseal Pro to run our own company, we’ll be experimenting with different setups. It may be something that we control via Preferences, or by right-click options.

That part of the interface programming is going well. Unfortunately, the bad news is that Apple has decided to discontinue drawers as part of the Mac interface. The code still works, but it is deprecated and will stop working in some future version. Drawers are an additional type of window that slides out from the side, to show extra details. They are (were) perfect for showing breakdowns. We are still looking for a substitute.

Dennis Kolva
Programming Director
TurtleSoft.com