when field processing

[GCC Consulting]

> 
> GCC Consulting wrote:
> >  
> > 
> > 
> >>-----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.
> 
> This is not true.  It does not execute automatic processing 
> after the when processing unless there is no input processing 
> and the very end of the record processing is done in add mode.
> 
> Logic is as follows:
> 
> for add mode:
> 
> automatic - input
> 
> In the input part - you have levels that are determined by 
> the WHEN, @entsel, @once, @done, @key, @menu, call and chain.
> 
> In update mode:
> 
> automatic - input - automatic
> 
> If I press ESC in a field with WLF processing, it will do the 
> following:
> 
> WHEN processing for that field
> INPUT processing from the top
> AUTOMATIC processing - if the INPUT processing hit an END.
> 
> Nancy
>   I say
> >>this not from pure supposition, but from watching it in the 
> debugger.
> 
> Only way that is true is if there was no INPUT PROCESSING in 
> that file.
> 
>   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?
> 
> NO THE END statement is the correct way to finish a WHEN 
> process.  Also SCREEN, ESCAPE, SKIP, END, (think that is all)
> 
> >>
> >>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?
> 
> -s is setting the screen name
> 
> >>
> >>I can't see anything in the prc.automatic table that would 
> prevent the 
> >>input table from being processed.
> >>
> >>I'm just plain confused.
> >>
> 
> Put a msgbox in each section and try it.  You will see what 
> is happening.
> > 
> > 
> > If you use the following code, the processing should go to 
> the top of 
> > the processing table.
> > 
> > @wlfxx if:
> >      then: SAVE
> > 
> 
> I try to use this sparingly.  I do not like to be forced to 
> move to a given field to SAVE the data.  If my customer hits 
> ESCAPE anywhere on the screen, you need to verify the data 
> and allow them to continue or return to complete the data, 
> not just on field XX.

That's why at the top of the table I verify that they have gone to the finish
routine.

Normally I verify the required data as it is being entered. Acceptable values
are check either thru programming or with field edits. I have yet to figure out
how to keep the, from making stupid errors.  Entering an incorrect customer code
or a wrong quantity.

However, I stop the user from leaving the record by requiring that they verify
each screen before continuing.  I have had apps with up to 10 screens of data
needing to be entered.  Each screen required a response and all of the required
fields were check for a value entered prior to displaying the next screen.   The
user does have the ability to move forward and back through the screens. 

My fix routine allows direct entry to a field or fields needing to be corrected
without having to move thru all of the fields again.

Richard Kreiss
GCC Consulting 


 
> 
> > 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
> 
> Why not let finish be in the INPUT part of the table?
> 
> This looks very confusing.
> 
> > 
> > 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
> > 
> > 
> > _______________________________________________
> > Filepro-list mailing list
> > Filepro-list at lists.celestial.com
> > http://mailman.celestial.com/mailman/listinfo/filepro-list
> > 
> 
> 
> --
> Nancy Palmquist
> Virtual Software Systems
> PHONE: (412) 835-9417			Web site:  http://www.vss3.com
> 
>