Conference iosg::all-in-1_v30

388.0. "pre and postprocessing giving different results" by COMICS::BARHAM (Norbert:) Wed Apr 01 1992 16:56

    ALL-IN-1 2.4
    
    I have a customer with an arguement form with certain fields which he
    wishes to protect dependent on values in other fields. e.g. if a field1
    contains a Y then postprocessing on filed1 does oa$frm_set_field field3, 
    to skip over field 2.
    We must also cater for landing on field2 from other fields, e.g. via
    backward tabbing, hence we need to preprocess field2 too.
    
    All sounds fine except the post and preprocessing functions in the
    following example are executed in the wrong order :-
    
    ;;.TYPE;;
    
    ARG /OVERLAY/HARD="Your arg form name"
    
    ;;FIELD_1;;
    
    /valid=oa$yn
    /post='display field_1 post_processed'
    
    ;;FIELD_2;;
    
    /pre='.if field_1 eqs "Y" then oa$frm_set_field field_3'
    /post='display field_2 post_processed'
    
    ;;FIELD_3;;
    
    /post='display field_3 post_processed'
                                        
    ;;FIELD_4;;
    
    /post='display field_4 post_processed'
     
    
    
    example : put Y in field1 (to skip over field2)
    We can arrive at field2 from anywhere. (tab forward/back etc). 
    We want to detect in preprocessing of field2 whether field2 data entry 
    is allowed. 
    If field1 is completed with 'Y' and we tab to field2 then the 
    cursor moves direct to field3 as required and it says 'field1
    postprocessed'
    Post processing has occurred but pressing tab again should show field 3
    postprocessing executed but actually displays 'field2 postprocessed'.
    
    Cursor now in field4, we have just executed field2 postprocessing. Now tab
    back to field3 and field4 postprocessing is executed ok. Tab back again 
    to field2 - cursor stays in field3 ok
    because preprocessing of field2 says move to field3 if field1 = Y, but
    the Display shows 'field3 postprocessed'. Back tab again, cursor is sent 
    back to field3 but this time 'field2 postprocessed' is displayed!
    
    What's going on ? Why does this example give different messages
    depending on where you arrive from ?
    
    Thanks
    
    Clive Barham
    UK CSC
                            

    
    As always, this is a popular question to which there seems to be no
    definitive answer.  Note 383 concerns this same issue.
    
    One method to do things like this is to redefining the TAB and BS 
    keys (and any others that apply) to do the checks (based upon the 
    field that you're on) and then positioning the cursor via 
    "OA$FLD_STAY fieldname".
    
    Your mileage may vary...
    
    Jack
    

        Interestingly, OA$FLD_STAY <fieldname> seems to behave the same as
        OA$FRM_SET_FIELD.  Of course, OA$FLD_STAY doesn't need to take a
        parameter, but I'll ignore that for the moment.
        
        The interesting thing about this is that I've never seen
        OA$FRM_SET_FIELD used in the product and OA$FLD_STAY is everywhere!
        (see any INDEX form)  And . . . OA$FLD_STAY is undocumented!
        
        Hmmph!
        
        _M

    mike,         
    
    APR vol 2 page 437 (ALL-IN-1 v2.4) has OA$FLD_STAY documented
    
    Regards,
    
    Andrew.D.Wicks

        Hmphh....  again...
        
        O.K., so it isn't alphabetically located after OA$FLD_SEARCH in the
        documentation AND it IS in the V2.4 index...
        
        But not in the V3.0 index...
        
        _M

And the the main reason for OA$FRM_SET_FIELD not being used in the product was
because it just did not work and OA$FLD_STAY did, when was it fixed (is it?).

	Ben