--- Alex Rice <[EMAIL PROTECTED]> wrote: > create a mainstack "main" > add a field "news" with lot of text in it to card 1 > of "main" > create a substack "report" > add a report object to card 1 of "report" > in the report object properties select field "news" > of stack "main", > then click Apply > now report object magically turns into a field? (OK- > I assume that's > supposed to happen) > now resize the report object height to fit it's > content (several pages > tall) > resize stack "report" to fit the report object > (several pages tall) > open Report Builder on stack "report" and use > default settings > click Print Report > -- > what is output is: > 1 full page, with a the bottom line of text chopped > in half. margins OK > on page 1. > the second page is 75% empty space, with some text > at the bottom > running off the page. > it should have been 4 or 5 pages. > > > Alex Rice
Hi Alex, Coming back from a viral infection-enduced hiatus, and after having waded through a huge truckload of posts, I noticed that nobody replied to the above post -- so I figured I'd have a go at it. First of all, the report object acts as a kind of portal : the original object is cloned and placed on the card when you click the "Apply" button. If you resize the report viewer object, it will lose that size and formatting when you hit "Apply" again. When you use the menu to go to the next page, the report generator checks if there happens to be a field of the same name on the next card in the source stack. If so, the text from that field is put in the field in the report stack. When printing time comes, the report generator is supposed to try and print the updated card, and if it's too big, print it over multiple pages. However, the algorithm doesn't care if it's slicing a field in half ; it just divides up the card into slices the size of what fits between the header and footer. The header will be placed on the first page, the footer on the last page. And tt won't scroll any fields for you, either. If you're looking to print the text of a single field, revPrintField might be a better choice. In case you're feeling adventurous and want to learn more about the report generator inner workings, have a look at the 'revPrintBack' backscript. 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 ;-) Hope this gets you closer to a solution, 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
