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

Nancy Palmquist nlp at vss3.com
Tue Jul 10 11:22:19 PDT 2007


Fairlight wrote:
> 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->
Mark,

We are doing a very similar thing in the new stuff I have been working on.

We had the same issue.

I added a SLEEP "200" to give it time to write the FORM to the spooler.

The last lines read:


────────────────────────────────────────────────────────────────────────────────
  64  -------   -   -   -   -   -   -   -   -   -   -   -   -
        ◄ If: 'overlay forms printing
        Then:
  65  -------   -   -   -   -   -   -   -   -   -   -   -   -
        ◄ If:
        Then: printer type "laser4si"
  66  -------   -   -   -   -   -   -   -   -   -   -   -   -
        ◄ If:
        Then: gosub doauth  'this prints a form
  67  -------   -   -   -   -   -   -   -   -   -   -   -   -
        ◄ If: loglevel ge "2"
        Then: logtext "-----     Line 61 @keyG about to frmspec"
  68  -------   -   -   -   -   -   -   -   -   -   -   -   -
        ◄ If:
        Then: gosub frmspec '  this prints a form
69  -------   -   -   -   -    -   -   -   -   -   -   -   -
        ◄ If: loglevel ge "2"                               ◄
        Then: logtext "-----     Line 63 @keyG about to misform" ◄
  70  -------   -   -   -   -   -   -   -   -   -   -
        ◄ If:                                                ◄
        Then: gosub misform        'this prints a form          ◄
  71  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
        ◄ If: skipchk      'this updates some markers                 ◄
        Then: gosub finque;gosub wrtque                               ◄
  72  -------   -   -   -   -   -    -   -   -   -   -
        ◄ If:                                           ◄
        Then: call "binprt"          ' this prints a form           ◄
  73  -------   -   -   -   -   -   -   -   -  -   -   -   -   -   -   -
        ◄ If:                                                         ◄
        Then: sleep "200" 'slow it down 2 sec between records that print ◄
  74  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   - 
   -   	If:                                                           ◄
        Then: write;end                                               ◄

I think the process finishes which closes all output and the last page 
has not been written to the print queue when it finished.

Nancy

-- 
Nancy Palmquist 		MOS & filePro Training Available
Virtual Software Systems	Web Based Training and Consulting	
PHONE: (412) 835-9417		   Web site:  http://www.vss3.com


More information about the Filepro-list mailing list