$totpage on reports

Author: gianni.sandigliano@unifacesolutions.com (gianni)

Hi Unifacers, A Uniface Developer I am in contact with was asked from a customer to write in each page of a somehow "critical" report something like "Page Y of X", where X is the total number of pages the whole report will have at the end. He came to me asking: - is it supported from Uniface a function giving back the total number of pages a report will generate? My answer: NO, AFAIK as of today. - is there anyhow a tricky way to solve it, avoiding to answer NO to the customer? My answer: are you using occurrences/field vertical expansion in your report? Yes! The only solution I can imagine is to run the report twice with same params: the first time to a virtual device just to get the total number of pages generated the second time effectively to generate the report output but this solutions could lead to effective errors/problems: 1) With lengthy reports new occurrence could be inserted matching chosen params between first and second execution 2) Each output device should have a virtual one coupled with EXACTLY same setup (NOT an acceptable request to sysadmins!) We agreed to tell NO to the customer (BTW: it is never a simple decision!) It is very probable/possible this request was already asked before; I remember to have lightly discussed with ULab this same issue many many years ago (U6/U7 times, 20 years or more ago...). My memory is telling me: "If you do not solve an issue today it will come back to you later" Anyhow: Am I missing something? Is there an alternative way to look at this request? Gianni P.S. @ULab: wishlist is going to be reopened sooner or later?

14 Comments

  1. Hi Gianni, how about printing to a Postscript-File with Header-Info "Page: %%$PAGE / $$$Totalpages$$$". You can load the file and replace $$$Totalpages$$$ with the actual number of pages, save the file and convert to a pdf.   Regards Norbert


    Author: Lauterbach (norbert.lauterbach@infraserv.com)
  2. Hello I did exactly what Gianni wrote you need to  print to a virtual printer with exactly the same driver, otherwise the length of pages are not the same multiple run for counting number of lines with rules like :  not having a comment on 2 pages for example So I had to create for each printer, the virtual one with a null port   Dominique


    Author: mpservices (mps59@orange.fr)
  3. Thanks Norbert and Dominique for your replies. @Norbert: an idea to work on! I feel it's like "to shot a sparrow with a cannon" but it is a powerful idea... Implementing a Postscript post-processing could be useful in more cases. @Dominique: :-) what about two worries we had: - are you NOT facing the possibility the database is changed between first and second execution? - how sysadmins has reacted to your request? Gianni


    Author: gianni (gianni.sandigliano@unifacesolutions.com)
  4. Hi Gianni, the change in the database doesn't matter when you  run the 2 prints against the same hitlist. In the GFG of the header frame, just copy $page $running_page$ = $page X_pagecountText = $concat($page, " / ", $totalPages$) For sure you have to reset individual counters etc. before starting the second print: retrieve $totalPages$ = 0 call init_counters() print "myVirtualPrinter" $totalPages$ = $running_page$ setocc "mainentity",1 call init_counters() print "myRealPrinter"   HIH, Uli


    Author: ulrich-merkel (ulrichmerkel@web.de)
  5. sorry for the typo: it's frame gets focus (FGF) for the HEADER or TRAILER


    Author: ulrich-merkel (ulrichmerkel@web.de)
  6. ulrich-merkel said Hi Gianni, the change in the database doesn't matter when you  run the 2 prints against the same hitlist. In the GFG of the header frame, just copy $page $running_page$ = $page X_pagecountText = $concat($page, " / ", $totalPages$) For sure you have to reset individual counters etc. before starting the second print: retrieve $totalPages$ = 0 call init_counters() print "myVirtualPrinter" $totalPages$ = $running_page$ setocc "mainentity",1 call init_counters() print "myRealPrinter" HIH, Uli  

    Hi Uli, correct... but only if print instruction is executed using "A" as second parameter (explicitely o implicitely); if print instruction is using "C" as second parameter hitlist is not saved between first and second execution. Anyhow, thanks for your input! Gianni


    Author: gianni (gianni.sandigliano@unifacesolutions.com)
  7. Hi Gianni, thank you for pointing to this "C" sideeffect. IIRC, the "C" drops the hitlist after the COMPLETE print is done. It's NOT that there is a line-by-line discard working together with a stepped hitlist saving memory. So in fact there is no real benefit using the "C". But adding the "A" on both prints will make the code better; I will enhance my example according to your contribution, Uli


    Author: ulrich-merkel (ulrichmerkel@web.de)
  8. 1) data modified : hopefully,  I only have the problem with invoice printing, the invoice is generated before, so the print process is only printing otherwhise I would have problems   2) I m working in environnments where I give the pre requisite functionnalities, so they don't really have the choices if they ask me for this kind of functionnalityCoolCool Dominique


    Author: mpservices (mps59@orange.fr)
  9. A few years ago I had to go to Switzerland and early in the morning I went there to write down the road 
    (there was still no google maps) I came back and set off again to reach my destination following my own directions. 
    This seems to me the meaning of this discussion on the pages number in printing ...
    Cool
    

    Author: TheAleph (mail@gandg.it)
  10. a few years ago, I speak of the early 90s, I found myself in a company that made long prints in continuous format, 
    it worked like this: they processed the print, stored the number of pages, put the sheets in print and reworked printing 
    only the words "pag. X of XXX "in the trailer, my comment was: but it is not easier to print on the last page " End printing XXX pages."? 
    And so it was.  Wink

    Author: TheAleph (mail@gandg.it)
  11. @TheAleph: CoolCoolCoolCoolCoolCool Gianni


    Author: gianni (gianni.sandigliano@unifacesolutions.com)
  12. Hi Roberto, as Gianni mentioned, it's for "critical" reports, The customer demands the "page n of nn" as this is the way this is done since decades. In most of our worlds customer requirements have to be delivered even if the tool makes implementation harder. Let's say the printout doesn't show "End printing XXX pages" for whatever reason (pages lost?) how do we know how many pages are missing ? How does a recipient of the report KNOWS that he has to watch for "End printing XXX pages" And why printing "End printing XXX pages" on page XXX; a simple "**** End of Report ****" is good enough.


    Author: ulrich-merkel (ulrichmerkel@web.de)
  13. I went through my dusty project notes from the 1990s: instead of $totpages (Gianni mentioned that it is a pretty old open wish), we used a textfield X_NEXTPAGE in the TRAILER reading "report continues on next page" In the LeavePrintedOccurence of the main entity, we had the code: if ($next("pkfield") = "")  ; there is no next occurence any more as PKfields are not null    X_NEXTPAGE = "report completed" endif So we have on each page a status info "continues/completed" and all in one print loop. Just another way to indicate to the reader (together with the pagenumber) that he has a "complete" report, HIH, Uli


    Author: ulrich-merkel (ulrichmerkel@web.de)
  14. Of course I was joking yesterday, it was such a day Laugh.
    historically, for me, the most applied solution is to print in the header  "page XX" and in the trailer "follow on page (nextpage) " .... 
    or "end of print" on the last page.
    Have a nice day, my friends.  WinkWink

    Author: TheAleph (mail@gandg.it)