--- Alex Rice <[EMAIL PROTECTED]> 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 _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
