Jump to content


- - - - -

&$EOF


4 replies to this topic

#1 Guest_Sam_*

Guest_Sam_*
  • Guests

Posted 23 July 2002 - 05:53 PM

Hi all,
In a report that consists of one LR I have two control breaks. The first one is on the file key and the second is on EOF. I do not want to show the header used in the first control break if the end of file is reached.
I guess I need to DSEL in the logic before of the first control break, but the value of &$EOF is always equal to “A”! Should not the value change when EOF is reached?
Or is there some other variable I can check to find out whether the end of file is reached or not?
Thanks,

#2 jcduym

jcduym

    Member

  • Members
  • PipPip
  • 35 posts

Posted 24 July 2002 - 08:33 AM

Hi,

The value of &$EOF is not 'A', that is the value contained in the value variable of &$EOF: the value is either 'on' or 'off', being a flag. You can test it with BITON/BITOFF.

Thus to suppress the header, you can use this test to deselect the first CB.
If all else fails, you can always try to FNEXIT. . . .

Best of luck.

#3 Richard Bassett

Richard Bassett

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 696 posts
  • Location:Rural France

Posted 24 July 2002 - 09:23 AM

On the contrary, I don't think there is a bit you can test using BITON/BITOFF to see if you are at end-of-file. &$EOF is a string value whereas BITON/BITOFF/ENABLE/DISABLE require numeric arguments.

The value 'A' may be completely irrelevant - I think the &$EOF variable exists merely for use as a 'label' to specify end-of-file control breaks.

Surprisingly (and I'd be very happy to be corrected), it seems to me there is no way for a programmer to tell EOF has been reached when processing lower-ranking control breaks.

More generally, there's no way to know the most significant control break which will be processed 'this time around' (ie: how 'major' this break actually was).

What's needed is a system variable called something like @CB_LEVEL which identifies the MOST significant (highest ranking) control break which is actually triggered. That or its equivalent doesn't exist as far as I know.

It's a very good question Sam and seems like a shortcoming in the language. You're not having much luck are you :)

You could try using CB 'next' header/logic for your minor control break ('next' means it appears BEFORE the corresponding data) and suppressing it the first time around. Of course, if your break may well need to show data for the PRECEDING iteration and you'll have to preserve the data yourself temporarily, it's ugly I'm afraid..
Nothing's as simple as you think

#4 Andy Jones

Andy Jones

    Member

  • Members
  • PipPip
  • 41 posts
  • Gender:Male

Posted 24 July 2002 - 05:47 PM

Hi Sam,

Your first control break will always trigger when the value of the key variable changes.
By the sounds of it, you are reading single key records and understandably have concluded that when PROIV reads what you know is the 'last' record, PROIV will also know it is at End-Of-File.

However, this is not the case!
When each record is read, PROIV will complete a full pass of the timing cycle for this record: Read, CB's, Print data, Write. When CBs are triggered it is still processing the current record and doesn't know at that point if it will have another record to process or not.
Why doesn't it know? Well for example, there may be a DSEL on an after read logic which decides whether a record is processed or excluded. Because of this, the 'last' record may not actually be the final one on the file/selection!

It is only once PROIV finds no more records to read that it definately knows the 'end of file' state has occured - so you will never get a control break on your key and on EOF at the same time.

It sounds a little odd to me that you don't want the CB for your final record - maybe if you can give us some more detail on why that is we can offer another solution!

BTW, if you do want to prevent CBs from happening, you probably want to use DSEL_CB() for a single CB, or DSEL_ALL_CB() for that and lower CB's in the 'Before CB' logic, and not DSEL.
Also, as far as I know &$EOF is just a variable to use in CB's and you cannot test its value for change in logic. If you do want to do some specific logic dependant on EOF, do it in 'after cb' logic for a CB on this variable, or in LS exit logic.


HTH,

Andy
Nothing is foolproof to a sufficiently talented fool...

Don't learn from your own mistakes - it's safer and more entertaining to learn from the mistakes of others!

Just because you can, it doesn't mean you should!

#5 Guest_Sam_*

Guest_Sam_*
  • Guests

Posted 24 July 2002 - 07:46 PM

Hi,

Thank you all for the info. I sure learned new things about how Control Breaks work that I did not know in the past.
I did manage to fix the problem but I do not really know whether it is the ideal way or not.
That is how I did it:
LOGIC AFTER FILE NO ERROR of the primary file of LR:
IF IR.JDATE # @DATE THEN DSEL EXIT;
$IR.NUM = IR.NUM

LOGIC BEFORE CB
IF IR.NUM # $IR.NUM THEN DSEL;

In response to Andy, the reason for deselecting the first control break is that I am also using Vertical Total in the first control break, which is being displayed twice at the end of the report.

Thank you,



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users