Printing/Reports/Rabbits (Apr 6)

For the past month our staff has been testing the new accounting software with TurtleSoft data. It’s called “eating your own dog food”. Plenty of details are still unfinished, so it’s not yet ready for daily use. Sometimes progress takes minutes or hours. Sometimes it’s slower.

Last week we tried printing a sales receipt. The button just beeped. No code at all there, yet. Time to tackle another hard problem. Luckily, there aren’t many of those left.

Printing is complicated. There are different paper sizes. Landscape or portrait. Color or B&W. Printers vary in their dots per inch and printable margins. Every operating system has a way to talk with printers, but none are very easy. Our staff probably has spent a full programmer-year on the Goldenseal printing code, much of it just futzing with margins. Hopefully, Qt will be easier than previous frameworks, once we figure it out.

Most apps send users to Page Setup before they print. Let the OS and the user decide how it should look. After that, most apps have it easy: use the same code that draws on the screen, but send images to the printer instead.

Printing business forms is more complicated. They don’t look the same as what’s on the screen. They come in different shapes and sizes. A detailed estimate may have several pages of breakdowns, all coming from one record. Splitting lines of text between pages can be tricky. Mailing labels are the opposite: they may have 15 or 30 records on each page, without much wiggle room.

To handle all that, each printed form has its specs built in, set via Custom Layouts (Goldenseal) or the Layouts button (TurtleSoft Pro). That means you can just hit Print Forms, and get what you want. No need to visit Page Setup. Easier for you, but more complicated for us.

We decided to ease into printing by starting off with reports, rather than printed forms. Their print version matches what’s on the screen, so there are fewer ways to go wrong. We clicked the Reports button to see one. Oops, not much there. We set up the buttons and layout loading a year ago. But it still needed coding to fill in text and numbers.

Most of the reports show a table, with rows and columns of data. Report tables share some features with breakdown tables, which already work OK. But there are differences. Moving to Qt meant diving down into the base classes that apply to all tables. That’s yet another complicated bit of code.

We rewrote the memory storage in tables 5 years ago, as part of the Cocoa project. Our staff has gotten better at modern C++ since then. So, we spent a couple days refactoring the base tables. The new code does the same things, but with less risk of crashing or leaking memory. Tables now are less fragile, and easier to maintain. They still have room for improvement, but that can be a gradual process.

It has been bit of a rabbit hole. Going deeper and deeper. But, report tables now fill in text, so we are starting to ascend. Most likely it will take a few weeks to reach the surface. Get tables more solid, get reports fully working, then get them printing. Then print some forms…

Dennis Kolva
Programming Director
TurtleSoft.com

Author: Dennis Kolva

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