I previously posted the following:

Strange behavior in R/LIST report .. doesn't matter if its done in OR_VIEW or directly to printer. When done in OR_VIEW, the page numbers display correctly. When printed, they only print on the first page. Subsequent pages don't display the HEADING or FOOTING items either.

Any ideas???

Don M.

I'm really stuck on this one ..

Don,

It's that see-thru ink again!! Numbers on pages 2, 3, ets, are printed with see-thru ink!!!

Sorry. Assume that joke is long worn out.

I have no idea, but what happens if you do your report from Report Builder? (Doesn't Report Builder use OR_VIEW?)

- Oystein -

Oystein ..

The first thing I checked for was See-Thru-Ink. Printed it to a disk file just to check. Sure enough .. write-only memory.

I don't get the same thing when I run the report to R/LIST in AREV 3.12. I generated the BASIC+ code and examined it carefully. The page overflow should work but …. Also, the @LPTRHIGH variable is set properly at 60. The wierd thing is that it appears perfectly correctly in OR_VIEW but if the "Print" button is clicked then there's no numbers or header or footer after the first page. If I send it directly to the printer (bypassing OR_VIEW) I get the same wierd behavior. Absolutely stumped!!! My only option is probably to code the thing using OIPI but .. that makes it hard to modify (as you can well imagine). R/LIST works much easier in this case.

Thanks, though.

Don M.

Don-

Is this still happening in 4.1?

Mike

This is how it has "not" worked properly for me in OI 16.

Is it being improved for OI 4? Don't know.

I rewrote important reports into OIPI. What fun that is. However, S/List won't work here since it is incompatible with OI16 and OIPI Pro.

Dave

Will check and see; however, since it happens in my primary app which is in OI-16, it really doesn't matter too much since it's unlikely that I can wholesale upgrade my users.

Don

Don,

I have never been able to get it to work for me within OpenInsight. Quite a while ago, I figured it out to be the actual "PRINT" statement. The "PRINT" statment, appears, to not update the current line counter.

My work around was to use PRINT_INIT, PRINT_TEXT, PRINT_END, PRINT_SETHEADER, etc. I created my own reporter window, and passed script to it. Since all I want is simple text reports (no grahpics) with headings columns and total lines, it works great for me.

Don,

I've always wondered if that See-Thru-Ink is totally transparent, or more like a wet T-shirt or something.

(I asked about Report Builder because it uses OR_VIEW too (?), meaning you might learn something from its success or failure.)

Is there anything you want me to try for you in my OI16 (3.7.1 or 3.6.1)?

- Oystein -

Don,

Hadn't read the responses from Richard and Dave when I replied. They seem to say you'll have to give up on OR_VIEW.

Wish I could help you. In one of my apps I actually have a simple OIPI-based reporter that can do e.g columnar reports from a pseudo-graphical description, but it's limited to 10 pt Courier New, one header line, no footer and no page numbering. I figure you'd have too much trouble modifying it to your own needs, being someone else's code, with comments and messages in a foreign language, etc, etc. I don't know why I mention it.

- Oystein -

Oystein ..

Thank you for your kind offer. I think that this behavior is sporadic since other reports which use OR_VIEW seem to work as expected. My suspicion is that the processing of multiple LIMIT clauses is the culprit since there are also spurious BREAK-ON items which shouldn't belong either. This isn't a problem in AREV (any version after 2.12, anyway). What is so confounding is that it is different on the screen in OR_VIEW than on the printer. It seems to me that all OR_VIEW does is do a callback procedure which captures the output that would be directed to the printer.

]]I've always wondered if that See-Thru-Ink is totally transparent, or more like a wet T-shirt or something

iNow let's not let THAT dog out to run. It's notable for biting you in the a**./i

Don M.

Don,

LIMIT is something I've never used.

I assume one can avoid using LIMIT if the LIMIT criteria (comparison or range) are restricted to a small and finite set. Then one can define symbolic fields (one for each criterion) doing the work of LIMIT, and use the symbolics instead of LIMIT on the original field. But I guess you aren't that lucky.

- Oystein -

Mike ..

Yup.

BTW .. Here's the Sentence:

PAT, PAYCODE and SCHEDDATE are Multi-Valued

LIST SCHEDULE_HISTORY WITH SCHEDDATE FROM "03/01/91" TO "03/24/91"

AND WITH PAYCODE EQ "MEDA" "TI19"

BY PAT BY PAYCODE BY SCHEDDATE

LIMIT SCHEDDATE FROM "03/01/91" TO "03/24/91" AND LIMIT PAYCODE EQ "MEDA" "TI19"

AND LIMIT PAT NE ""

BREAK-ON PAT "'LUUV'" JUSTLEN "L#7" COLHEAD "CLIENT "

BREAK-ON PAYCODE "'LUV'" JUSTLEN "L#10" COLHEAD "PAY SOURCE"

SCHEDDATE JUSTLEN "L#8" COLHEAD "DATE "

STIME JUSTLEN "L#6" COLHEAD " SCHED"

ETIME JUSTLEN "L#6" COLHEAD "TIME "

SCHEDACTCODE JUSTLEN "L#5" COLHEAD "ACT "

TOTAL ELAPSED_HRS1 STARTTIMEACTUAL JUSTLEN "L#6"

COLHEAD "ACTUAL" ENDTIMEACTUAL JUSTLEN "L#6" COLHEAD "TIME "

ACTIVITYACTUAL JUSTLEN "L#5" COLHEAD "ACTUAL"

TOTAL ELAPSED_HRS2

ID-SUPP

The problem is that the earlier version of S/List didn't support multiple LIMIT clauses (no LIMIT stack) so we can either use R/LIST or code the report ourselves using OIPI or somesuch.

Anyway .. Don't know what the good answer can be

Don M.

Oystein ..

Back in the olden days, that's exactly what we had to do because LIMIT was not implemented. We used @USER variables with tags to do this in symbolics. I'd hate to have to resort to doing this again since multi-valued symbolics when sorted take a looooooot of time and the processing overhead is foul too:

READNEXT @ID,Which_Value …

Then the symbolics are extracted like

NEWSYM={SYM} .. etc.

Then it also goes through the standard setup to setup levels for the REMOVE statement which extracts single-values ahead of the Multi-Value processing place. The problem is that when you do the READNEXT (above), the multi-valued variables are already single-valued. But, they may have other system delims to deal with (@TM, @SVM, etc.). Then, and only then, does the LIMIT clause come into play.

Anyway .. I'd hate to have to go through THAT again.

Don M

View this thread on the forum...