new problem with FORM...(helllllp!!!) :)

[Bruce Easton]

Mark Luljak wrote Tuesday, July 10, 2007 10:40 AM:

>
> 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.
>
[..]

Mark - unless I'm missing something, I don't see anything wrong with
your five new lines, but I have a few questions.

Are you sure that a final form command is executed after the last
set of data is assigned to dummy fields?

Based on your command line above, a default automatic table might run
with this  - if it is, what kinds of things are happening in there?

Is there anything in the original code (the portion you are still using)
that is controlling the current record pointer?

In the original code, based on screens, is there any special switching
of screens that is different for the last set of data found?


Bruce

Bruce Easton
STN, Inc.