We are working in AREV 3.12. I've looked in our manuals and in this discussion area but couldn't find any help. We have a program that will gnerate a report either to the screen, to a file or to the printer. The thing is that the header part of the report generated by the R/List HEADING seems to be our problem. The text for the different parts of the header is pulled from a row and several different columns within the row. The text gets into the row by way of a user typing it in thru a window.

The problem we are having is that certain headers are casuing what looks like problems. In looking at things, the problem headers have more lines than what is displayed on the AREV MS Window. For us that is 25 lines displayed to the monitor.

What we are seeing is that we display the report to the screen and all we see is the last 25 lines of the header. Hitting the Enter key doesn't seem to do anything. But if I hold down the Enter key, every so often I'll see a flash where something different is displayed. As I continue to hold down the Eneter key and see more flashes, I figure out that occasionally the very top of the header is being displayed but with different page numbers. So at this point I can only conclude that things are working correctly, they just appear to be broken.

Is there a maximum number of lines that the HEADING can or should have? Does anyone have any words of wisdom on how to deal with very large amounts of text or large number of lines within the HEADING of an R/List statement?

My first thoughts are that we may need to either restrict the amount of text a user can intially enter or truncate the text as it's being loaded into the HEADING. For what we are trying to do, I would rather not restrict the amount of information that can be displayed in the HEADER (or more acurately the information entered into the columns that the header pulls from). Is there any other options that I might want to consider?

Thanks for your time.

Michael Slack

If you let users key text into what will become the header, you have to filter out certain keystrokes:

The lower case quote (') which can cause all sorts of strange things since the HEADER is enclosed in double quotes nees to be trapped. For example O'LEARY will case a stray linefeed and the L in LEARY will get lost. A double-quote will cause problems since it will terminate the header and then the remainder of the header text will cause a command error.

You can fix some of these by:

SWAP "'" with "`" IN ( BACKWARDS APOSTROPHE)…

SWAP '"' WITH ' ' IN …

HEADER lines that are too long will NOT wrap. I limit user input strings in HEADERS to 60 characters for just that reason, since I often need a trailing Page Number.

HTH

Don M.

My first reaction is, why would anybody want that much information in the headers?

The users are allowed to enter information themselves. Is the information they are entering used for something else besides headers on reports? If so, I'd suggest using two fields instead of one – reserve one for headers only. Headers are usually abbreviated and are expected to be abbreviated.

A summary page could be generated either at the start of the report or at the end which explains the headers in more detail if required.

Hello Voctor:

I came to the same conclusion late last night.  I was just to close to the problem when I wrote my query.  I'm going to see about moving as much of what is now the header into the body of the report.  Then the remaining header information will probably be restricted to some max size so the total header will never get out of hand again.

Don: We've run into the situation where someone entered in a single quote (') and things got wacky after that in the report.  I'm going to see what I can do about finding and swaping out a single quote (') with two single quotes ('') so the header will interpet them correctly.

Thanks for your help.

Michael Slack

Michael,

Don is of course right .. that is one of the things we discussed as I was leaving .. but remember .. it is not necessarily that the user entered a ' but that the text in the header that follows.

For example .. i think one of the bugs we had was the header was 'L and this was followed by LOAD or something similar .. this really cause the header to see a 'LL which gave us 2 lines.

Something similar with D where the header was 'L followed by character D which I believe, if i memember right (it was 3 months ago) caused a line and date then the rest of the word.

I think actually, what I had wanted to do with that report, was to rewrite the 'header' bits and actually print out properly.

dsig@sigafoos.org

Actually, the place that really caused us problems was when a customer or business name was used as a BREAK-ON and being inserted in the HEADER's value. In this case, I had to create a symbolic for the name that explicitly checked for the apostrophe and swapped it with a backward apostrophe ('`'). Otherwise, the whole thing can become data dependent. Any text that can be used in a BREAK-ON construct with the value going into the HEADER can cause this. I've also had customers use wierd punctutation in @ID that can cause the same kind of problems.

Don M.

problem is I believe the routine he is talking about .. I wrote

After the first problem came up I had expected to rewrite the routine and do it proper .. but time ran out

dsig@sigafoos.org

DSigs Radio Free Oregon

The problem we are having isn't connected with a single quote (') and then an "L" or a "D" or anything else. Actualy, one of the headers we had a problem with didn't have any single quotes in at all (that was one of the very first things I checked). As far as I can tell, there isn't anything wrong with the routine. The problem is that there is too much text that is being stuffed into the header. There is more lines in the header than can print out in a 25 line AREV screen. Thus by the time the header is done printing out, it has already tripped the systems need to print the header because its gone past the line count where it says the screen is full, it needs to print another one and it needs to print another header for the new screen.

Basically, what we've found is another flavor of the endless loop. So, I'm going to look at is moving some of the data from the header to the body of the report. Then see about making sure the remaining header information can't get out of hand either. At the same time, I'm going to see about protecting the header from the stray single quotes that the user might enter into the row that the header text is made of.

Thanks for everyones help and input.

Michael Slack

I dont thing there are other solutions than increase the screen row count or decrease the header rows:)

Just for the sake of argument, have you tried using a different video display mode setting in the workstation environment that increases the row count on the screen?

For example (from Sysprog): Options | Workstation | Display Environment | Video Display Parameters | Video Display Mode set for VGA50

Bill

Michael,

Yeah .. that is one of the reasons I wanted to re-write it. It was a hack to get a report quickly .. would be much better to build the 'additional' header info and just print at the beginning of each page .. sorry about that

dsig@sigafoos.org

DSigs Radio Free Oregon

Hello Bill:

Yes, I've run the report in question on a 50 line AREV window and I haven't had any problems.  The thing is that setup is a special for me, I've created the INI and BAT to allow me to do that.  But our standard for our users is 25 lines and I don't see use changeing that.

Thanks,

Michael Slack

I don't think I'd do that either. I've seen wierdness on some desktops when the display resolution is changed to 50 lines. This is particularly true with some video cards. Suddenly start to get memory conflicts that become very hard to resolve / troubleshoot.

Don M.

View this thread on the forum...