dummy value changing in @wbrk1, but not a numeric or subtotal field!

[Brian K. White]

This one wasted half a day for me so far.

I have a report that wants to send a fax and/or email during @wbrk1


The structure of the report processing is like this:

-----top-----
if: cnum ne 1
then: gosub nprtf
then: cnum = 1
then: print
27: then: end
28: @wbrk1:
then: print
then: printer flush ; printer reset
then: system "d" < iv
then: end
@once:
then: x = rand("-1")
then: cnum = ""
then: end
then: declare cnum(6,.0,g), prtfile(255,*,g)
nprtf:
then: 
iv(255,*,g)=getenv("PFTMP"){"/burst_"{@fi{@rn{@qu{@id{1{"_"{rand(){".pcl"
then: system noredraw "umask 0 ;>" < iv
then: printer reset ; printer file iv ; printer type "hplaser"
then: return
-----bottom-----


There are auto and selection processing as well but shouldn't matter to the 
issue I'm about to describe.


When I run this report, the value of iv changes between line 27 and 28.
It changes in a way that I can't imagine being correct under any 
circumstances even IF iv were a subtatalable field which appeared on the 
output format (neither of which is true)

what happens is, in the debugger, stepping through the lines one at a time 
(no breakpoints),
- I arrive at a new record, @rn shows 2525
- the customer number in field 1 doesn't match the saved value in cnum, so 
it does the gosub
  the gosub defines a new value for iv,
  action msgbox iv in the debugger shows:
    /pix/anro/tmp/burst_goinput252504root100013_24140.pcl
  and the file is created as expected
report processing main body processes the record
the file gets some data in it
at the end of main body processing for the record (line 27),
  msgbox iv still shows the same string with 24140
  in the debugger, a single enter key
now on line 28,
  nothing happened in between 27 and 28
  now msgbox iv shows a new string
    /pix/anro/tmp/burst_goinput252504root100013_595.pcl

@rn 2525 didn't change, customer number 100013 didn't change, (either in the 
string or in the debugger displaying the fields directly)

The only thing that changed in the string was the random number, and the 
string as a whole changed in a way that as far as I can tell could/should 
only happen if the gosub was run again, because the new string is shorter 
than the previous, yet it was assembled & concattenated correctly as if the 
a{b{c{rand(){d were executed again.

nprtf is not run again, at least not at that point, because, aside from the 
debugger saying so, the new filename does not exist either.

The new, wrong filename in iv in @wbrk1 is different and random each time 
@wbrk1 is reached.
It happens at every @wbrk1.
There are no records that do work as expected or that result in a valid 
system command.

1) as far as I can tell this is incorrect behaviour. I fill a variable with 
a string value and the string value changes without me changing it. If this 
were a numeric value subject to subtotaling that would be different.

2) if I replace "iv" everywhere with "prtfile" then it all works as expected
the value of prtfile does not change when stepping from line 27 to 28
it only changes when processing encounters nprtf

This could be a really useful feature if known and documented, though I 
would wish for a way to avoid it and still use a small variable in case I 
wanted iv to appear on the report format.
As it happens, since I don't need iv to appear on the report, it's no 
problem to just use a long variable instead of a short one.
The right way to embed dynamic content in a static string intentionally as a 
feature might be to do it the same way as elsewhere in fp, as in \GZ \KY \I 
etc...

fp 5.0.14 linux
effects dreport & rreport equally

Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!