Printing Hell

[Dar Scott]

On Jan 25, 2005, at 3:01 PM, SimPLsol at aol.com wrote:

> Kevin wrote:
> "It is perfectly possible to print anything you may want to, including
> complex reports."
>
> Where do we find the recipe for multi-page reports based on a source 
> stack
> with scrolling fields? Headers? Footers?

Jacque mentioned revPrintText as example.

However, report printing can be richer than that.

I have wandered over to the following style.  I use a stack library to 
print out a particular kind of report (such as a form letter, automated 
newsletter, ledger sheet, exam, badge, etc.).  On the cards of that 
library, I put smart report components with notes on how to maintain 
them.  The exact representation and sometimes position of the component 
is controlled by custom properties.  An example might be a footer.  The 
stack library uses a substack for report layout with page-size cards.  
The substack asks the library for components, creates instances and 
specializes them.  Often only a single page (card) is used in the 
layout stack, sometimes repeatedly for the same report.  The substack 
or pages have custom properties that control the layout.  Some are 
design-time and are normally only changed in the IDE.  The rest are 
layered by abstractness.  The layout is driven by the more abstract 
stack properties and a few page properties.  I make heavy use of 
setprop.  To keep from repeatedly redoing the layout each time I change 
a property with the stack library, I use a recursive lock property.  If 
I change a property with the IDE (with no locking), part or all of the 
layout is redone immediately--this helps me in layout changes.  This 
all creates a dataflow or descriptive layout.  I can change the number 
of columns for something or change some margins and poof! I can see the 
change.  There is little difference in design-time properties (eg page 
margins) and run-time properties (eg title).  I often use printer-res 
images and resize them a little as needed.  I usually have a mode 
switch that makes the layout invisible in normal usage, but visible in 
development and testing.  (I make heavy use of setprop and got myself 
into trouble when I didn't check the target, so take care with those.)  
When the library is no longer needed or is saved, it cleans up the 
layout pages to keep the library stack from containing old reports.

Almost all of the report generation in this style is the bubbling of 
info through setprops.

Now all this is a lot more work than canned report generation and for 
many uses an overkill, but it supports (in my experience) Kevin 
Miller's statement.

Of course, this does not address concerns of printer setup & their 
preferences as well as Unicode issues.

I realize that is not quite a recipe, Paul.

Dar

**********************************************
     DSC (Dar Scott Consulting & Dar's Lab)
     http://www.swcp.com/dsc/
     Programming Services and Software
**********************************************