when field processing

[Jeremy Anderson]

I've tracked it down to not having "restart" in the @keyu label.  Once 
that was added in, things began behaving like I thought they should. 
Apparently @keyu doesn't always allow the processing to restart at the 
beginning of the input table, unless "restart" is explicitly called.
At the risk of boring everyone, I've left my updated code off this email.

Jeremy


John Esak wrote:

>  
>
>>-----Original Message-----
>>From: filepro-list-bounces at lists.celestial.com
>>[mailto:filepro-list-bounces at lists.celestial.com]On Behalf Of GCC
>>Consulting
>>Sent: Tuesday, August 10, 2004 4:54 PM
>>To: 'Jeremy Anderson'; 'filePro Mailing List'
>>Subject: RE: when field processing
>>
>>
>>
>>
>>    
>>
>>>-----Original Message-----
>>>From: filepro-list-bounces at lists.celestial.com
>>>[mailto:filepro-list-bounces at lists.celestial.com] On Behalf
>>>Of Jeremy Anderson
>>>Sent: Tuesday, August 10, 2004 11:52 AM
>>>To: filePro Mailing List
>>>Subject: Re: when field processing
>>>
>>>Rick Henderson wrote:
>>>
>>>      
>>>
>>>><>when save is executed, the input processing table runs
>>>>        
>>>>
>>>from the top
>>>      
>>>
>>>>until it his an end.
>>>>
>>>>something like the following might work. r
>>>>
>>>>
>>>>top if: @sn="ordchg";
>>>>then: form "Psliprpt";end
>>>>fin if:
>>>>then: end
>>>>
>>>>@wefXX
>>>>@wlfXX
>>>>
>>>>        
>>>>
>>>Yes, from the STN Filepro manual, I had gathered the same thing.
>>>What's confusing me, however, is that when I hit [esc], it
>>>never starts processing the input table at the top.  Instead,
>>>it appears to follow the @wlfXX processing, depending on the
>>>field I'm leaving, then goes to automatic processing.  I say
>>>this not from pure supposition, but from watching it in the
>>>debugger.  If I hit [esc] in field 67, then it processes
>>>@wlf67, goes to automatic processing, and then returns me to
>>>my record, having never executed the input table from the top.
>>>
>>>I'm seeing this behavior on both 4.05 on NCR MP-RAS, and on
>>>5.0.14 on Linux.
>>>
>>>Is the "end" in the @wlfXX statement preventing it from
>>>processing the table from the beginning?
>>>
>>>I'm calling dclerk with the following menu statement:
>>> /fp/dclerk MatUse -Sordchg
>>>
>>>is the -S flag which is being passed to dclerk somehow
>>>interfering with my attempts?
>>>
>>>I can't see anything in the prc.automatic table that would
>>>prevent the input table from being processed.
>>>
>>>I'm just plain confused.
>>>
>>>      
>>>
>>If you use the following code, the processing should go to the top of the
>>processing table.
>>
>>@wlfxx if:
>>     then: SAVE
>>
>>Now, I have an ending routine which asks "IS everything is
>>correct? (Y)es or
>>(N)o -> ".  The subroutine is simply called finish.
>>
>>If this is the last field to get data
>>
>>@wlfxx if:
>>     then: GOTO finish
>>
>>Finish if:
>>     Then:input popup("20","-1") y "IS everything is
>>correct?\n(Y)es or (N)o ->
>>"
>>       if: y = ""
>>     then:BEEP;GOTO finish
>>	 if: y = ""
>>     then:GOTO fix
>>	 if:
>>     then:SAVE
>>
>>Top of processing table
>>
>>	if: not finish
>>    then:GOTO finish	This traps someone saving the record before
>>finishing
>>and the drops to the ending routines.
>>
>>My preference is to keep the ending routines at the top of the
>>table, the @w
>>processing in the middle and any subroutines and the end.
>>
>>Richard Kreiss
>>GCC Consulting
>>    
>>
>
>Hi Richard,
>
>This code is a little strange. Maybe you quickly wrote it here by hand. But
>you can't test for y="" and go to different places on two different lines.
>Also the test at the top of the form test for "not finish" and there is
>nothing at the "finish" label to test against... Just dropping through
>finish with no test means this is superfluous or well not very logical.
>Maybe you should post the exact code here for him.
>
>John
>
>
>_______________________________________________
>Filepro-list mailing list
>Filepro-list at lists.celestial.com
>http://mailman.celestial.com/mailman/listinfo/filepro-list
>  
>


-- 
Jeremy Anderson			      jeremy (at) plunketts.net
IT Manager, Plunkett's Pest Control   Author, Multitool Linux