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
TurtleSoft.com

Author: Dennis Kolva

Programming Director for Turtle Creek Software. Design & planning of accounting and estimating software.