Upon adding a new LU to verify correct data, the report stopped printing legible reports...the alignment was messed up. It would seem that by adding this LU I've somehow have changed the FONT characteristics of this report. If I remove the LU, or the call to the LU, it prints fine. Unfortunantly, though, that is not an option as the verification is a new requirement.

If I include the code @RPTOPT = '4 lp0' in the calling function the report prints fine on the printer we have in our office, but not on the users printers.

I've tried to search for topics, here on proivrc, that would detail all the commands for @RPTOPT, but have not found anything that says what the commands do. (ie. What does the 2 and the 9 do in the following commands: @RPTOPT = '2,laserprinter' or @RPTOPT = "9,\computer name\printer share name").

If anyone knows the link to any posting, or if anyone could respond with the answer to what the printer commands do, it would be a great resource to have all the answers on one posting.

Also, if anyone has any inking to how to solve this problem with my report, I thank you in advance for any help you could send my way.

Sorry...typo.


Also, if anyone has any inkling to how to solve this problem with my report, I thank you in advance for any help you could send my way.

The document that covers printing from PROIV is called "Principles and Practices" and is defined in chapter 8.

With regard to your particular issue, I would hazard a guess that it is because the LU that is being called is a local subroutine within your report function. When such an LU is introduced it is still within the report and as such the development tool defines a dummy field for the LU. When the records for the LU are processed there is the very real chance that there maybe output of that field. This is especially significant when defining reports that have an output type of XML, as the "dummy" field can form part of the XML output stream (unless you set it to be otherwise). I would suggest that you create a global function for your check that is an update and call it from the report. This should resolve your issue.

The way that I have found to get around this is to enable the &#@SUPDETF before the call processes any output (in the default logic of the LU for example) and then disable it after the LU (the exit logic works).
Damian