Category: Goldenseal news

Accounting software helps tame the complex parts of running a business. Putting data into rows and columns is a good way to accomplish that, so our software uses spreadsheet-like tables almost everywhere.

When we first wrote Goldenseal in the mid to late 1990s, we had to build the table interface completely from scratch. There is code that fills in text, draws lines between cells, handles clicks and double-clicks, and deals with all the other little details. Altogether, it took about 2 programmer-years to write all the C++ code that runs Goldenseal’s tables.

Those handmade tables have not aged very well. Despite a few appearance updates, they still look “old”. On Windows, they flicker and flash. Even worse, it’s complicated code that is hard to maintain.

For Goldenseal Pro on Macintosh, we use Apple’s Cocoa library, which already contains a complete table system (NSTableView and helpers). That’s good news, and bad news.

The good news is that Cocoa table views handle most of the nitty-gritty details for drawing and behavior. It only takes a few lines of code to get a functioning table. Even better, when future OS updates change the interface appearance, the built-in tables will update too. 5 years from now, the tables in Goldenseal Pro for Mac won’t look like the spreadsheet equivalent of bell-bottom jeans.

The bad news is that Apple built Cocoa mostly to support their own apps, and they rarely make it easy for other programmers to understand and use. It’s kinda like buying something from Ikea, but without step-by-step instructions. Instead, there’s just a nice picture of the end product, and a list of parts. Where and how to use them? You need to figure that out on your own.

Usually there are sample apps, from Apple and others. Often they are outdated, but it still helps to see a working example. Stack Overflow usually has answers for specific error messages or problems. Still, getting Cocoa tables to work has required much trial-and-error.

Despite the obstacles, we’re making decent progress on the tables for the Macintosh version of Goldenseal Pro. Last week, they started showing columns and titles. This week they are filling in data, and giving a data entry field when you click on a cell. They look and act like tables now.  Still some formatting and other details to finish, but it’s moving ahead at a decent pace.

The MFC library for Windows does not include a table class. That has the same good news/bad news as Cocoa, only reversed.  Other people have put a few projects online that may work. We’re looking at them now. Also, we already have working table code, and maybe it just needs some updating.

Dennis Kolva
Programming Director
TurtleSoft.com

 

The current version of Goldenseal is a 32-bit app. Goldenseal Pro is 64-bit. You might wonder why that makes a difference. So, let’s look closer at computer bits, and how they affect our accounting and estimating software.

First of all, a bit is just a yes/no choice. It’s the smallest possible unit of data. Numerically, a bit is usually considered a 1 or 0. Physically, it may be a tiny magnetic spot, or a tiny laser-etched dot, or a tiny transistor’s state.

Computers have gradually increased the number of bits they can handle. Early PCs used 16-bit addressing for RAM, which meant a limit of 64K (65,536 bytes).  Early Macs increased that to 24-bit (16 megabyte limit). In the 1990s, PCs switched to 32-bit addressing, with a 4 gigabyte limit. In the 2010s they’ve moved to 64-bit, with a theoretical limit of 16 billion gigabytes (=16  million terabytes =16,000 petabytes =16 exabytes).

Our accounting software is not likely to ever need more RAM than the 32-bit limit. Likewise, file sizes will also stay comfortably below 4 gigabytes. However, there are other reasons why 32-bit apps will become obsolete, relatively soon.

On the Macintosh, that impending obsolescence is obvious. Starting in Fall 2019, Mac OS will only run 64-bit apps. Apple has not updated its Carbon library to 64-bit, and does not plan to. That means all software must switch to Cocoa, which requires either Objective-C or Swift as a programming language.

As we have painfully discovered, converting from Carbon to Cocoa is not trivial. Existing C++ code can connect to Objective-C, but it’s a pain. Replacing old interface code is an even bigger pain. The Goldenseal Pro update is less work than the original programming for Goldenseal, but far more than any previous upgrade.

On Windows, the situation is less dire, because Microsoft takes great pains to support older software. However, 32-bit apps are already starting to be cranky, on newer versions of Windows. They often require special installations of older libraries and DLLs, and they may not be compatible with newer printers or other hardware. Running 32-bit apps is already a nuisance, and it will only get worse.

Updating our own programming code from 32-bit to 64-bit was not difficult. Memory addresses changed from 4 bytes to 8 bytes, but it’s rare for code to care about their length. There were other small changes to make, but nothing overwhelming. That prep work only took a few weeks.

Unfortunately, that’s not all that is required to get from 32-bit to 64-bit. Problem is, it’s not practical to write everything needed for a full-sized app, so we rely on libraries written by other people to handle “the basics”. Some are system libraries from Apple or Microsoft, some are open-source, and some are third-party code. Many of those libraries don’t work in a 64-bit world, and will never be updated by their authors.

We faced that situation with the NeoAccess code that runs Goldenseal’s database. It was so old and so badly written that a rewrite would have been a soul-sucking task. Replacing their code completely was faster, and less frustrating. It was a half-year project, but at least the new code will be more reliable, and easier to maintain.

We also had to toss most of the PowerPlant library, and a few smaller 32-bit libraries from the 1990s and 2000s. This massive conversion is something that every software company will have to deal with, if they want to stay viable.

Of course, there are many gains that come from the upgrade. For example, PowerPlant (and the original Macintosh) drew on a 16-bit “canvas”. As a result, reports with more than 1,500 lines were too long to display on the screen (though it was still possible to save them as text, and open in Excel). We tried to rewrite that code to 32-bit, but never got far. By going “native” with the screen drawing, Goldenseal Pro gets a huge canvas for free. It also gets better looking graphics, support for UniCode text, and many other improvements.

Dennis Kolva
Programming Director
TurtleSoft.com

Any estimating software needs to divide projects into smaller pieces. It helps mathematically: if you split the estimate into many smaller calculations, the errors will usually cancel out. It also helps prevent errors: when we did construction estimates by hand, it was very easy to forget a few things. Categorizing also specifies the project in detail: clients know exactly what they are getting, and the building crew know what they’re building. As a bonus, a good category system integrates estimates with accounting software, so you can compare ‘estimated vs actual’ costs in a useful way.

Most construction projects can be sliced in at least two different ways. You can divide by categories of work: foundations, framing, roofing, trim and so on. Or you can divide physically by rooms, units, buildings, stories or whatever. There probably are other ways to slice up a construction project, but those are the most common.

For our own programming projects, it has been a challenge finding ways to categorize the work, for both estimating and job costing.

When we first started to program Goldenseal in the mid-1990s, project management consisted of a print-out of all the menus, with ‘completion bars’ drawn in atop each command. It was a nice, tangible way to see progress, but it also made the work seem like it was moving faster than it was. About 80% of the commands were easy, and each took only a few hours to complete. Some commands like Estimates and Print Forms took months. A couple (Write Payroll and Custom Layouts) took almost a year each. The chart looked like 90% done, when it was more like 50%. I guess that’s proof of the 90/90 rule. You can make the same mistake on a room-by-room construction estimate, if you count the kitchen and bath the same as other rooms.

A few years ago, we listed the Goldenseal Pro update on eLance, UpWork and guru.com. Over 100 subcontractors gave price quotes. Most just guessed or tried to talk us into T&M, but some sent detailed bids. Since we are still exploring the best category system for our own projects, it was interesting to dig them up and see how other programmers divided the work.

Several had a few broad, chronological phases. For example, one had 25% (prepaid) for ‘team selection’, 25% for ‘evaluate code’, 25% for ‘alpha version’ and 25% for ‘bug fixes’.  Basically, they wanted half prepaid before even starting. A few counted windows or menu commands, similar to our first method. The rest sliced the project into 10 to 25 categories, similar to our approach last year.

Looking at other people’s cost estimates is also useful. It’s similar to ‘comparison estimating’, where you start with a similar project and then calculate the differences. It’s a good approach if you know the total cost of past jobs, but don’t have enough detailed job cost data to calculate unit costs.

About 2/3 of the bidders planned to use QT, a popular library that builds code for both Mac and Windows.  Those estimates ranged from 40 to 150 programmer-days, or from $7,000 to $60,000 in cost.

We hired one of those in early 2015. The project started well, but ground to a halt after a few months. Then we discovered the contractor had used many shortcuts to get to the first draw payment, and we probably shouldn’t have paid for that. At least we learned that QT was the wrong tool for the job. The code was just too ugly.

About 1/3 of the bidders planned to convert Goldenseal the way we are doing it now: on the Mac, from Carbon to Cocoa; on Windows, from QuickTime to MFC; on both platforms, from 32-bit to 64-bit. Very few of those were willing to give a firm price, and none gave a detailed breakdown.  We hired two contractors who gave up almost immediately, and one who worked part-time for a few months before “getting stuck”. At that point, our staff had finished the back-end work, so we just started the interface code in-house.

Looking back through the list of bids, it’s clear that almost nobody understood how difficult the work would be. At the time, we assumed that tons of other software apps would already have made a similar conversion: meaning that there would be scads of subcontractors experienced at it. Reality is, those 64-bit updates never happened. Most business apps are still 32-bit, up to and including the big boys like QuickBooks and Sage.

Meanwhile, work proceeds on tables. Our estimate says they’ll take 2 months, but we aren’t far enough along yet to know how accurate that is.

Dennis Kolva
Programming Director
TurtleSoft.com

Last June, we made a quick spreadsheet to estimate completion time for Goldenseal Pro. The math predicted completion in late May or June 2018, but it was very uncertain. Since we write construction estimating software, you’d think we could make highly accurate estimates for our own programming projects.  Unfortunately, that has never happened. Software is less predictable than construction, and harder to specify.

Work on Goldenseal Pro has progressed enough that it’s a good time to recalculate a completion date.  Unfortunately, updating last year’s spreadsheet did not go very well. Its category breakdowns just don’t line up with the actual work we’ve done. That estimate sliced things vertically, but progress has been more horizontal instead.

The calculation method we used was also inferior. It started with a guess of total work needed for each category, and a guess at the percent completed so far. Then, a formula to calculate work remaining. The problem is, multiply two guesses, and it just makes an even worse guess.

For what it’s worth, we did the best we could with that spreadsheet, and it calculated 7.9 months until completion. Probably plus or minus a few months.

Now that we are further along, the calculation will be more accurate if it starts with the time spent to date, then extrapolates from there. We just looked at source control comments, to get a general idea of how much time has been spent on each area, so far.

The MVC (model-view-controller) system is a reasonable way to slice the new code in Goldenseal Pro, horizontally.

At the bottom, the model layer includes business logic, database code, and basic stuff that connects to memory and the OS. Half of the model layer is the business logic that runs our estimating and accounting software: that does not need to change at all. It’s about the only thing that doesn’t. During 2015 and 2016 we did an extensive ‘gut rehab’, and replaced all of the other half (including a complete database rewrite).  The model layer is pretty much finished now, but it probably still needs a few days, here and there.

At the top, the view layer handles what you see on the screen, and what happens when you click a mouse or type on the keyboard. For Goldenseal Pro, we need to replace 100% of that code on Mac, and about 75% on Windows. About 1/3 of the view layer programming is for basic windowing, and ‘mode shifting’ between data entry, find commands, layouts, printing and reports. That portion is mostly finished on Mac, and half-done on Windows. Another 1/3 is buttons, fields, and other small interface. Most of it works now, but there are many small details still unfinished. This portion is probably at 50%.  The final 1/3 is tables and other complexities, which we are only just starting.

In the middle, the controller layer coordinates the model and view, and also links between C++ and Objective-C. It applies almost exclusively to the Mac version. The MFC library for Windows does not use MVC, possibly because the acronyms might interact and explode. Generally, the controller layer just makes life more complicated at every turn. It’s hard to itemize the effort it takes, but it’s a good place to throw in 2 or 3 months for forgotten complications and unexpected cruft.

Before using math on programming work to date, we really need to adjust for the learning curve. Productivity was close to zero when we started using Cocoa and MFC, and it ramped up from there.  Smooshing the first 6 months into 2 productive months seems about right.

Throwing all that into a spreadsheet says 7.3 months to first release. It’s several months later than last year’s estimate: October instead of June. No surprise, given the many uncertainties, and the extra work we’ve added since then.

The estimate will grow more accurate, as we move further along.

Dennis Kolva
Programming Director
TurtleSoft.com

 

At Turtle Creek Carpentry, our first construction estimates were based on simple rules of thumb. E.g. for house painting in the mid-1970s, we figured $100 per side (labor only), $10 per window or door, and scratch-your-head extra for wide eaves, porches, and anything else unusual. That kind of math was reasonably accurate, quick to calculate, and easy to remember. It worked well enough for estimating simple construction projects like painting, roofing, storm windows, and the like.

Unfortunately, rules of thumb didn’t scale up so well for larger, more complex projects. Those required much more time and math. Bids took days or even weeks to prepare.

When Turtle Creek computerized in 1986, the first task was to set up construction estimating templates. It took a few months to assemble rules of thumbs and actual calculations into a spreadsheet. When it was done, the results were amazing. Bids took 1/5 the time to prepare, and they were much more accurate. It probably worked so well because construction work is tangible and repeatable. That makes it relatively easy to turn construction details into data and formulas.

Unfortunately, many other project types are not so tangible, or not so repeatable. For those, it is much harder to calculate time or cost in advance.

For example, in 2011 the SpaceX Falcon Heavy was first predicted to launch in late 2013. It actually flew in early 2018. Completely-new stuff is just plain harder to estimate. We face the same uncertainty when trying to estimate  our own software projects. It’s also an issue when we try to expand our estimating approach to industries other than construction.

Since we evolved from rules of thumb to serious math in our construction estimates, maybe it’s worth following the same path for less tangible estimating. For “fuzzy” projects, there do exist some “fuzzy” rules of thumb.

On the pessimistic side, one rule is “it always costs twice as much/ takes twice as long as you expect”.  Or even more pessimistically, you can add “even when you figure it will take twice as long as you expect”.  That rule certainly applies to my bold prediction on Jan 11 that we could start using a beta version to run TurtleSoft in “a month or possibly two”.  Doubling that seems much more reasonable.  Quadrupling it?  Probably not, but it’s certainly possible.

For software, a similar rule of thumb is the 90/90 rule. It goes “the first 90% of the project takes 90% of the time.  The last 10% of the project takes the other 90% of the time.” This definitely applies to the layout view. After 2 weeks work, it’s now doing most of what a simple drawing program needs. It looks pretty far along, but there are many small details that will easily take another 2 or 3 more weeks. The original estimate was a month for the Mac version, and so far that looks accurate.

On the optimistic side, sometimes projects go faster at the end. It certainly applies to jigsaw puzzles, Sudoku, and computer sorting algorithms. To some extent, it also applies to software projects like Goldenseal Pro. Our work started out very slowly, because of the ‘learning curve’ for new languages and libraries. Productivity has increased dramatically since then, and will keep increasing as we near the end.

There are also sound mathematical reasons to plod at the beginning, and rush at the end. You can use the same math as for project financing. Interest cost = amount * duration * rate. The more spending you can delay to the end, the shorter the duration, and the cheaper it is.

Similar logic applies to risk and the ‘opportunity cost’ of labor. Procrastination pays off, if applied correctly. For just that reason, our staff will be increasingly motivated, as we get closer to finishing. When the end is in sight, it’s easier to put in extra hours.

Dennis Kolva
Programming Director
TurtleSoft.com

 

 

 

Our staff is making progress on tables, and also starting work on the layout view. It replaces the Custom Layouts command that sets up data entry screens, printed forms and reports in the current version of Goldenseal accounting software.  The layout view is essentially a drawing program. It has a tool palette, and graphic objects that you can click on and drag to new locations. We use it to set up most of the appearance in our estimating and accounting software. It also allows users to change things.

Apple has sample code for a simple drawing app, which makes our life easier. But not that much easier, since the sample was written in 1998, and its code is very outdated. It’s a helpful start, but we end up rewriting most of it.

The Objective-C language that Apple uses for Cocoa is even older.  Both Objective-C and C++ evolved in the early ’80s as enhancements to the venerable C language (origins mid ’70s). However, C++ has been updated frequently since then, while Objective-C has lagged. Almost nobody uses it except for Apple.

The little boxes that you drag around in the layout view are a perfect example of how difficult it is to migrate a large app like ours from C++ to Cocoa. In our existing code, each box is a C++ object. The object responds to mouse clicks, updates the screen display, and stores its new position when you stop dragging it. When you save, it writes changes to the database. The code is not trivial, but it’s all in one place. For the new Windows version, we can still use the current code with only minor changes.

The 64-bit Mac version still needs that C++ object to read and write data. It also needs a “linker” object (written in a hybrid language called Objective-C++). The linker connects with an Objective-C object which knows how layouts work, and that in turn contains a Cocoa control object that responds to mouse clicks and draws on the screen. Four classes instead of one. To make things work, we either have to pass messages back and forth through 3 layers, or write it from scratch in Cocoa.

This is a general problem that all software developers must face. Objective-C is not bad for small apps, but for a large app like ours it would be horrendous. Objective-C is creaky and cranky and decrepit. Then, the end result would be code that only runs on Apple hardware. It would require a complete rewrite for Windows, with two code bases to manage. Mixing C++ and Objective-C is possible, but challenging. We are doing that now, but it pretty much added a year to the development time for Goldenseal Pro.

Most big companies like Microsoft and Adobe only converted their Mac apps to Cocoa in the past few years. That’s very slow, considering that Mac OS X and Cocoa first appeared in 2001. Apple’s apps are written almost entirely in Cocoa, but they’ve had the benefit of adding Cocoa classes that specifically suit their own needs. Apple pretty much programmed their apps with a lot of C language code, and just a little Objective-C.

The new Swift language may some day make Mac programming easier, but it’s still immature. It also does not connect with C++ at all. Developers either need to write in pure Swift, or have two linkers (one from C++ to Objective-C, then another from Objective-C to Swift). It’s doable, but not fun.

Even more worrying, the usage rate for both Apple languages has been dropping, rather than expanding. Swift’s percentage in the TIOBE index declined from 2.1% to 1.8% over the past year, while Obj-C fell from 1.5% to 1.1%. That compares to 15% for Java, 11.9% for C, and 5.7% for C++. Programmers really don’t like either Apple language. Meanwhile, C and C++ are growing.

This coming Fall, the newest Mac OS 10.14 will start to give a warning when you run older 32-bit apps written with the C++ Carbon library. In the Fall 2019 release, Mac OS 10.15 will not run them at all. That change will affect the current Goldenseal software, but not Goldenseal Pro. Right now it’s looking pretty good for getting the Pro update out before this September.

Many good apps disappeared during the conversion from OS 9 to OS X in the early 2000s, and many more vanished after the conversion from PPC to Intel in the late 2000s. Most likely, in a couple years there will be similar carnage.

We actually find this bad news to be rather cheering.  TurtleSoft has already outlasted many competitors, and having to slog through (metaphorical) knee-deep mud means a few more will be left behind. Already, QuickBooks for Mac desktop is officially doomed after May 2019. It will be interesting to see if AccountEdge (currently 32-bit) can make the switch. They may be surprised at how hard it is. Chances are good that there will be a lot more room for other accounting programs such as ours.

We keep that in mind, every time that Cocoa programming goes #%@⊗!# or %!$♣~#(øΣ or &U+1F4A9;.  Fortunately, we are still ascending the learning curve, and it keeps getting easier.

Dennis Kolva
Programming Director
TurtleSoft.com

.

You probably have had one of those days when you go to the garage to fetch a screwdriver, but the light is burned out. So you head to the kitchen for a new bulb, but they’re all gone. So you drive to the store to pick up more, but while you are there, you accidentally lock the keys inside your vehicle. You try to pry the door open with a credit card, but what you really need is a screwdriver.

Anyhow, it has felt that way with the tables in our new accounting software. They are a major part of the interface, showing rows and columns of info much like a spreadsheet.

Back in December, breakdown tables were just starting to display in a cute pop-out drawer on the side. It filled in the correct columns, but needed an overhaul to the layouts before proceeding further.  Before doing that, it made sense to get all of the mode-switching to work for everything, not just layouts. That led to still further rabbit holes.

After 7 weeks of digressions, we are now back in the garage (metaphorically speaking) to fetch a screwdriver for Goldenseal Pro.

Since tables are present in all 6 basic modes, it makes sense to do them all at the same time. Print and report tables are easiest.  They are now filling in data, and looking pretty good. We’re currently working on the small tables found in lists, and some accounts. Then we’ll futz with layouts, then finish off the breakdown tables found in estimates, material purchases, and other business transactions.  Last and most difficult are the ‘action’ tables in Reconcile, Pay Bills and similar commands. The current app has an entirely different way to create them. Getting it to be more similar to the other tables has always been on the to-do list. That will happen soon.  It will make setup easier for us, and will allow users to modify them (slightly).

In an attempt to get a completion estimate for Goldenseal Pro, we looked at the draw schedules in the programming contracts from a couple years ago. Unfortunately, those were based on which menu commands worked. The actual project is proceeding more ‘horizontally’ than ‘vertically’. The current work on tables is spread out in 3 different project phases. It’s a lot like the difference between a ‘room by room’ estimate, and an estimate based on categories of work. They both get to the same place, but it’s hard to compare them.

About half the work we have done so far has been on major improvements to the basic interface. Those don’t show on the draw schedules at all.

The original plan was to start with a duplicate of the existing app (because easier to spec it that way for subcontractors). Once we had a working version, we would have made improvements in later updates. However, now that our staff is programming the whole project, it’s far more efficient to design and build a better interface, right from the beginning.  Doing it that way is slower to get to the first release, but faster to get to a really good version.

Dennis Kolva
Programming Director
TurtleSoft.com

 

Our estimating software has its roots in an Excel spreadsheet started in Winter ’86. It was just a list of construction items and prices, with formulas to do math on them.  The first unit costs were the “rules of thumb” that we already used for our construction estimates.

The spreadsheet improved gradually, as we duplicated it for each new job. Its first big test was a $100K remodeling project in a log house that summer (about $250K today). There were many complications, so the estimate ran to 200+ line items. The work was so unusual that nobody else bid on it. Our price was significantly over their planning budget, but we got it anyhow.

It was the biggest project ever, for Turtle Creek Carpentry. We were nervous about the size, so we built another new spreadsheet to track expenses. It later grew into our current accounting software.

Real-time job costing was a roller-coaster. For the new log garage, the estimate had a *12/5 formula to convert square feet of wall to lineal feet of log. Unfortunately, it was zapped by a later copy/paste, so expenses were suddenly $4,000 higher than expected. Then, oops, interior paneling was listed twice. That put it back close to estimate.  Other errors turned up, but in the end, final costs matched the estimate within 2%.

The lessons learned from that job still apply to our current construction estimating software.

1). it’s possible to get surprisingly good accuracy, even when the data is imperfect. The trick is to split the project into small pieces, and calculate each separately. The small errors will nearly always cancel out. It’s important to avoid systematic errors (everything wrong in the same direction). However, that is much easier than getting everything perfect.

2). Having a detailed breakdown of every item is impressive. Later on, we won bids even as high bidder, just because the list was so complete. Detailed printouts are an excellent marketing tool. In those days, it wasn’t hard to look better than everyone else. Now, it’s almost a requirement.

3). Matching actual expenses to the estimate really helps improve accuracy. The better you track job costs, the more accurate your estimates become.

4). It’s important to group things. That first big estimate had a huge list of items with no subdivisions. It was overwhelming, and hard to see errors. We overlooked the doubly-listed paneling. So did the architect, and the client. Seeing subtotals for different categories is a good ‘sanity check’ that we added to later estimates. As a bonus, it’s much easier to track job costing by category, rather than by item. Then you don’t need to ask where every 2×4 went.

5). Don’t rely on hidden math. As the spreadsheets and software evolved, we gradually found ways to make the cost calculations more visible and obvious. It’s an ongoing process that we still are improving.

We seem to be thinking more about estimating basics lately, as work progresses on Goldenseal Pro. Some of that is because the rewrite stirs up ideas for how to improve the software. Some is because we still aren’t very good at estimating the time it takes for our programming work. Ideally, it would sure be nice to calculate in advance, exactly how long each new product or upgrade will take.

Anyhow, 4 of the 6 basic modes in Goldenseal Pro are now functioning moderately well, and the 5th is getting there. Still many small details to finish, but it’s progressing at a steady pace.

Dennis Kolva
Programming Director
TurtleSoft.com

We just added color lookup tables to Goldenseal Pro (the coming update to our accounting and estimating software). They are the last of the resources that needed updating.

Color lookup tables (aka CLUTs) are pretty much a vestige of 1990s computing. To save space, 8-bit colors were common back then. To choose an 8-bit color, you select from a palette of 256 choices, rather than click on a full 32-bit color wheel. 

In the current version of Goldenseal accounting software, we use an 8-bit color palette for text and graphics in data entry layouts, printed forms and reports.  The system CLUT is mostly bright colors, so we replaced it with a custom version that includes more pastels (for field backgrounds) and dark colors (for text and borders).

32-bit color is close to the limits for human vision, and it’s worth having for photographs and videos. However it’s overkill for tiny color blobs like text and field borders. For those, 8-bit is perfectly fine. For example, Microsoft Excel shows a limited palette of colors for text and cell backgrounds. It’s easier to use than the full color wheel.

However, these days it is easier to program the standard color-choosers, rather than write custom code to show a palette. Goldenseal Pro still needs to support 8-bit colors so existing layouts read in correctly, but we will convert them to 32-bit colors when saved in the new format. It does mean you’ll have more choices for colors, especially if you want bright ones.

As for resources, they are a design feature that was first made common in the early Macintosh. Resources store program data that can be changed without any coding. It means that programmers (or users) can switch text to a different language, change field details, or add keyboard shortcuts to menus, without needing to rebuild the source code.

Mac OS 9 and earlier used a program called ResEdit to modify resources. It let users “hack” app resources, so they could change certain details of their software. We also used resources to set up most of the interface for Goldenseal.

Unfortunately, there is no equivalent resource editor for Windows, nor for current Mac OS. To update resources in the current version of Goldenseal, we actually have to go back and run Mac OS 9 on ancient hardware.

Goldenseal Pro uses modern Cocoa and MFC resources. That means they are user-accessible again, in both Mac and Windows version. Users or developers can translate the text to a different language, fiddle with colors, or tweak a small detail for a data field. Most of the resources are simple text files, but some use XML (eXtended Markup Language, similar to the HTML language used for websites).

It takes some effort to change resources, but that is how it should be. We don’t want it to be too easy for inexperienced users to accidentally mangle something important within the software.

The update to Goldenseal Pro is a long slog, but it does bring significant improvements. Better colors and resources are just a small part of that.

Dennis Kolva
Programming Director
TurtleSoft.com

 

A couple weeks ago, a support call came in from a potential buyer of our construction estimating software. They were confused, because the math seemed wrong for one material line item in an Assembly. When we checked it in our copy of the Sample Company File, it definitely was wrong. The line item total should be equal to unit cost times quantity plus waste factor, and it wasn’t.

It took a while to investigate this problem, and I’ll get to that later.

First of all, you can do the following to fix things:

1. Choose Cost Items from the Costs menu.
2. Choose Find All from the Edit menu.
3. Choose Replace All from the Edit menu.
4. In the Replace popup field, choose Adjust by Percentage.
5. Type in a small percentage like .0001%. Or use a bigger number if you want to account for inflation.
6. Click OK.
7. Goldenseal will recalculate all Assemblies, and redo all the math correctly.

Actually, this adjustment fixes everything except for four items: all for unskilled labor in closet shelving. We still need to investigate why that is off. Right now, even after the Replace All update, it still calculates $6 to $12 too low per closet. Everything else is fine. There may be a reason why closets calculate that way, but if so, nobody here remembers why.

We did not find anything wrong in the code that calculates unit costs in Assemblies and Estimates. You also won’t see errors for materials if you’ve changed their purchase price, or if you used a percentage adjustment any time in the past. Those force the Assembly line items to recalculate.

Right now, we still don’t know exactly how the numbers got off in our construction estimating data. We have tried hard to duplicate the problem, but so far it never goes wrong in real time.

The Sample Company File has been around since the early, pre-release versions of Goldenseal. That’s why most of its contents have dates in 1998. We used it for daily testing. Back then, the file format changed frequently, so we exported the sample data to a text file, then imported it back into newer versions. It was faster than retyping the fake business records.

Most of the construction price data came from our older software (MacNail, HyperEstimator and BidMagic). Converting those to Cost Items and Assemblies required some hacking and export/import. As we improved the estimating process, there was more hacking and export/import. Then we moved data between the sample and starter files, which meant even more hacking and export/import. Lots of opportunities for errors to creep in.

Over the years we have discovered and fixed a few dozen unit cost problems. Users have also reported a few. I suspect that the rest of the data bugs have lingered there unnoticed since the late 90s or early 00s.

The errors are almost exactly balanced between positive and negative. In real world estimates, they probably canceled out. Most are just pennies, probably from rounding errors. The big ones are in obscure materials that we don’t update very often. Anyone actually using them probably entered a new price, which fixed the math.

Still, we sell data as well as software. It should be perfect. We are working on that now.

While testing the construction assemblies in our estimating software, it also seemed time to update the material pricing. In general, wood pricing is up, concrete is way up, while hardware and manufactured items are down slightly. There are still more prices to gather, but updated files will be available for download soon.

Digging around in our construction cost database stirred up some other issues that are worthy of discussion. I’ll cover them in a future post.

Dennis Kolva
Programming Director
TurtleSoft.com