unclear on the concept, or major report printing bugs?

[Jan Schenkel]

--- Alex Rice <alrice at ARCplanning.com> wrote:
> 
> On Tuesday, July 22, 2003, at 02:04  PM, Jan
> Schenkel wrote:
> > You'll see in that backScript that you can trap
> the
> > 'revChangePage' message in your source stack and
> > update the data in a field dynamically with say,
> the
> > content of a field in a database ?
> > Hooking up revChangePage with revDBQueryGoToRecord
> > sounds like a very interesting plan to me ;-)
> >
> Jan, I'm trying to visualize this usage.
> revPrintBack sends 
> revChangePage when it advances from one card to the
> next. So on your 
> report layout stack you would have several cards.
> The report viewer 
> field would be grouped into a background and put on
> each card. you 
> would handle the revChangePage and adjust the scroll
> of the field with 
> long text (or update it's text with a db result). Is
> this the concept 
> you have in mind?
> 
> I have attempted to do this, and when I do
> "revPrintReport" from the 
> message box, I get
> 
> Message execution error:
> Error description: print: card or stack must be open
> to print it
> 
> However, my report layout card with the report
> viewer object is open 
> and selected. What am I missing here?
> 
> I feel like the Report Printing stuff in Rev 2.0 is
> going to be useful 
> eventually but it sure is a heck of a challenge
> figuring out how to use 
> it!!
> 
> It sure would be nice if someone could post a demo
> of the Report 
> Builder / Report View tools onto the User
> Contributions pages at 
> runrev.com
> 
> Alex Rice
> 

Hi Alex,

First of all, I couldn't agree more : a good demo
would go a long way towards opening it up ; the good
people at Revolution HQ insist that all the parts are
there to build wonderful reports ; but the absence of
a sample stack leaves us all scratching our heads.

Now to get back to the topic at hand ; it seems I was
a bit too quick when I suggested to hook revChangePage
to revDBQueryGoToRecord, unfortunately.
Upon digging some more in the backScript, I discovered
that's not the way this is supposed to be used --
perhaps it was anticipated this way and for reasons
unknown postponed to a later version.

To return to how the printing engine works with the
viewer object, I should point out that the report
stack will have only a single card (very important)
and this card is updated with data from the viewer
source objects, and then printed ; then the viewers
are updated again, and the same card is printed, with
the new data.

This means that in order to print a report with data
from a database, we need to :
- create a stack that will hold the data, placing the
fields and grouping them into a background
- create a report stack where we layout things
carefully, link to the fields in our data holder stack
- create a header and footer stack if applicable
- execute a query and fill up the data holder stack,
creating card after card and filling it with data from
the cursor
- from the look of things, you'd better update the
cREVReport["maxcards"] custom property of the viewer
objects as well with the number of cards of your data
holder stack
- then print the report ; the report generator will
print page after page, renewing the content of the
viewer objects with data from the holder stack.

To be honest with you, this seems like one heck of a
detour. So if I'm misreading the backScript, I'd sure
like to know. In fact, I'd love to be wrong.

Jan Schenkel.

=====
"As we grow older, we grow both wiser and more foolish at the same time."  (La Rochefoucauld)

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com