new problem with FORM...(helllllp!!!) :)
Fairlight
fairlite at fairlite.com
Tue Jul 10 07:40:10 PDT 2007
Hullo,
Okay, let me explain in detail what I'm dealing with so it has the context.
Originally, the developer had screen-based processing whereby if you press
a key while on a record, it grabs that person's name from field 1, does
a lookup for their name, and getnext's through their records populating
dummy fields for a form. When it gets 11 filled (maximum per section on a
two-section page) records, the next getnext is checked to see if it matched
the name or not. If it does match (ie., there are more for that name), the
form is printed via a call to FORM, and it fills the variables for the
first new row on the next page, then loops back up and does the whole thing
through the 11th entry again (including the one that was "left over" that
triggered the loop.
That whole thing performs correctly.
Now, I'm trying to take this out of a screen-based context, use the same
processing, but do it entirely from the command line.
I was warned about the inability to use FORM from @once and @menu. So,
after talking with John Esak last night in the fP Room, I decided my best
bet was to do the following:
1) Have @once processing that executes only once (I set a global dummy
field to prevent it from executing the rest of @once if it's already been
set). This processing does a lookup - to the file for the name. This is
just so that I'm sitting on a record. I was told you must be sitting on a
record to use FORM, so this accomplishes that criterion. I also get the
value of the name prior to this. Currently with getenv() but that'll
change to raw file I/O with a readline() in the final version. I'm testing
the basics here. At this point, once I'm sitting on a record, I use end on
@once to let that processing end, which I'm told should take me right to
@entsel status.
2) I use @entsel for the rest of the processing--all the rest that was
already here (everything except these first 5 lines of code) is all wrapped
in @entsel, and I have an exit instead of an end in one place where it
should actually end, so that the whole run of the program terminates.
All logic from the original is in @entsel.
Now comes the problem: the last page is always dropped. The pages that
print are in order, have correct totals, everything is fine. But the last
page is dropped entirely no matter what we do.
If we take the 5 lines out (and the @entsel label) and have my new
processing called directly from where the developer calls his original, the
last page is not dropped. If I put them in, the first x-1 pages print, but
not the total x pages when I run it directly from the command line.
We're doing this to a file, but we also just tested directly to a printer.
It has no bearing on it whatsoever. The last page is dropped in my
rendition no matter what the destination.
Here is what I added:
@once:fz eq "1":end:
:fz ne "1":fz(2,.0,g)="1":
::nm(60,*,g)=getenv("FL_NAME_FIELD"):
::lookup - k=nm i=a -nx:
::end:
@entsel: [rest of processing is the same as the original, including final end]
Now, I've tried adding a "printer flush" after the call to form. No joy.
I've tried inserting msgbox lines after each getnext and I -do- see records
that are vanishing on the last page. They actually are getting processed
from the looks of it. I've tried changing to formm with no difference in
behaviour. I've tried printer flush before exit. No joy.
No matter what I do, that last page is vanishing.
We even upped the amount of records I had so that there should be 4 pages
instead of 3, and instead of printing 2, it printed 3. Still one shy.
What about that whopping five lines of code and sticking the rest of the
processing in @entsel is making this act flaky? Since this processing is
the processing for the form (ie., "billcgi" and we're calling inside it
FORM "billcgi"), I thought that might be a problem, but if it prints at
all, it should be printing all pages. It's not just printing one page,
it's printing all but the last page, period.
My command line for this has been:
dclerk database -z billcgi -s0
Whatever's up, as I said (but to be clear), it's related to the @once
block, and/or the presence of @entsel. If that's taken out and used
verbatim, it works fine in place of the normal "bill" form in
screen-triggered processing. I just have -no- idea what is causing this
discrepancy.
If anyone can help save what's left of my sanity by telling me how to fix
this, please do. It feels like I'm doing everything right but there's
some hidden limitation I'm not aware of that's killing this. I'm -so-
close...both to getting it finished and losing my mind, depending how many
iterations of trial and error I've gone through. :)
Thanks in advance,
mark->
--
Fairlight-> ||| WARNING: This medication is not | Fairlight Consulting
__/\__ ||| recommended for people that are |
<__<>__> ||| living. | http://www.fairlite.com
\/ ||| | info at fairlite.com
More information about the Filepro-list
mailing list