Re: Handling changing page lengths / 4GL reports

In article <1992Apr20.191438.7379@nas.nasa.gov>, jcarter@nas.nasa.gov (John R. Carter Sr.) writes: >Okay. For those of you who are way behind in updates, here's my rather >extensive method of printing to laser printers: > >reports.4gl: >{ > The technique here is to control the page format with variables. [ some serious 4GL code deleted ] There are some aspects of 4GL's report facility that I really like. The ability to have a report order different from the database search order has saved me a *lot* of work on several occasions. And, being able to call functions from within reports is very handy. However, some aspects of 4GL report syntax are a pain in the neck. One of the most irksome is being forced to specify the report size paramters at compile time, as we've been discussing in this thread. This has given us problems with laser printers at our site, also. But, before that, we were stymied when we wanted to be able to change the "page" length depending on whether a report was being sent to a terminal or a printer. Another facility that would really be nice would be the ability to modularize report code. How about some syntax like: report [main] rpt_name ( ... ) ... call rpt_func() ... end report report function rpt_func() ... end function I suppose I could turn this post into a full-blown wish-list, but I'll resist the temptation. Suffice it to say that with the world of laser printers, multi-font displays and resizable windows already upon us, I hope that Informix's designers are busily trying to make 4GL as much of a *FOUR* GL as possible. One more note: > FIRST PAGE HEADER >{ Initialize variables } > LET ff = ASCII 12 > [...] In releases prior to 4.1, a bug in 4GL page break processing sometimes caused the data displayed in a PAGE HEADER section to be from a previous row instead of the current one. This may have also occurred in some of the group processing. The fix installed in 4.1 was to delay the PAGE HEADER processing until the first PRINT, SKIP or NEEDS statement is executed in an ON EVERY ROW section (according to the 4.1 4GL Supplement, p. S-49 - S-50). I would tend to think that the fix is somewhat more generic, like maybe "don't do page headers till we're about to print the next report line." At any rate, if you're used to initializing report variables in a PAGE HEADER section as I sometimes do, you could be in trouble in 4.1. At least that's what the book says.... Well, actually the books says that a report that initializes variables that way may give different results under 4.1 from what it does under 4.0. To me, that's trouble. So, Caveat Programmor. Walt. -- Walt Hultgren Internet: walt@rmy.emory.edu (IP 128.140.8.1) Emory University UUCP: {...,gatech,rutgers,uunet}!emory!rmy!walt 954 Gatewood Road, NE BITNET: walt@EMORY Atlanta, GA 30329 USA Voice: +1 404 727 0648