[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

383.0. "/PRE field qualifier and OA$FLD_xxx functions" by HOTAIR::MADDOX (DIGITAL Alien) Wed Apr 01 1992 01:14

I've looked in the previous conferences and found on topic in 
OLD_ALL-IN-1_VOL_1 which specifically addresses my problem but I have 
hopes that someone has come up with something cleaver or that the way
ALL-IN-1 handles /PRE qualifiers has changed since 16-JAN-1985.

I'm attempting to skip fields based on the contents of other fields in
an entry form.  I have two fields which have similar /PRE instructions
which should position the cursor past both of them if another field is
blank.  It appears looking at a trace that the /PRE on the first field 
is being executed and positioning the cursor on the next field, but the
/PRE is not being executed on that field.

Is there some way to force the /PRE on the second field to be dispatched?
I can't simply do an OA$FLD_STAY fieldname because this form is called
from different scripts with various /FIELDS="blah, blah, blah" and my 
named data has no way of knowing which fields should be available to the
user at the time.

The note which I did find said:
 
 Note 706.1 

> Trying to do field movements using the OA$FLD_xxx functions while in
> field PRE or POST processing will cause unpredicatable responses.  

Has the story changed?

Joe
T.RTitleUserPersonal
Name
DateLines
383.1Use a SCRIPT script with a {TAB} in itSHALOT::WARFORDRichard Warford @OPA DTN 393-7495Wed Apr 01 1992 05:0212
    No things haven't changed. You still cannot really use the OA$FLD_xxx
    functions in /PRE_FUNCTION and I thought /POST_FUNCTIONs reliably. It
    will almost always result in ALL-IN-1 getting confused about something.
    
    The only real alternative is to issue a SCRIPT script command inside
    the /PRE_FUNCTION. The script called would have a single {TAB} in it.
    So when it got time to do data entry on the field, it would act
    just like a user had pressed the tab key to skip the field. Of course
    you then have to make sure that your validation, if present, handles
    leaving the field blank - which is a trick in and of itself!
    
    Rick
383.2What problems?UTRTSC::BOSMANWe're just sugar mice in the rainWed Apr 01 1992 08:4820
    Hi,
    
    Well, I've made many applications using OA$FLD_PREV and OA$FLD_NEXT to
    skip a particular field and never, ever had problems with that.
    
    But, ofcourse, if it is officialy stated that it could cause problems
    who I'm I to say that it couldn't give problems in another situation.
    
    Sjaak.
    
    prototype:
    
    ;;SPECIFIC_FIELD;;
    
    /PRE_FUNCTION = '
     .IF {key-pressed} EQS "TAB" AND {condition} THEN OA$FLD_NEXT \
     .IF {key-pressed} EQS "BS"  AND {condition} THEN OA$FLD_PREV '
    
    Or something like this. Unfortunatly I don't have a working example on
    this system right now.
383.3Plug for OA$VAL_INVALIDAERO::TALLETTJust one more fix, then we can ship...Wed Apr 01 1992 09:4114
    
    	I have done it too and found I needed a new function OA$VAL_INVALID
    	to set a field invalid after ALL-IN-1 had validated it. So I put
    	the function in V3.0 (an advantage of working in engineering!).
    	If you don't use this function, then you can screw up the
    	validation by backspacing and entering.
    
    	There is also a problem with empty field validation. If you allow
    	an empty field at any time, then you need /OPTIONAL, but with
    	that, your validation won't get called if its blank, so you have
    	to ALWAYS allow blank.
    
    Regards,
    Paul
383.4Since you guys brought it up...HOTAIR::MADDOXDIGITAL AlienWed Apr 01 1992 19:3428
Okay,

Are you guys telepathic, or what?

Rick and Paul both mentioned another problem I have (unrelated to .0 I
thought).  Can I use /VALID to test whether I want a field left blank or
not?  Paul, I presume your OA$VAL_SET_INVALID function would do the trick
but I don't have 3.0 yet.

I'm aware, as Paul mentioned, that if I put a /OPTIONAL on the field my 
/VALID will not be executed if the field is left blank and if I don't put
a /OPTIONAL the user can never leave the field blank in spite of my /VALID
qualifier.  Is there some trick I don't know?

My current approach is to put a /POST form qualifier on the form and test
all the various conditions which I can't test with /VALID field qualifiers
and do a FORM ./BEGIN=field if a field is blank which shouldn't be, but this
is very cumbersome.

Re: .2

I have used the /PRE='.IF condition THEN OA$FLD_NEXT' succesfully as well, 
but if the field to which I am OA$FLD_NEXTing to has a /PRE on it it is not
invoked.

Thanks,

Joe
383.5No, I don't know eitherAERO::TALLETTJust one more fix, then we can ship...Wed Apr 01 1992 20:1211
    
    	After doing this sort of thing several times, I reached the
    	conclusion that you should avoid using /PRE and /POST for
    	field validation as it is VERY hard to get the desired effect.
    	Spend the time trying to get /VALID to do the job.
    
    	Having said that, I never did figure out how to get around the
    	/OPTIONAL stuff without using /PRE and /POST.
    
    Regards,
    Paul
383.6Sure it can be done...carefullyTRCOA::HALSEYI'd rather be sailing!Fri May 01 1992 00:1323
    Sorry for the late response, but as mentioned in other notes, I'm
    catching up.
    
    I tackled a similiar sort of problem before.  I had to bounce to one
    of several fields depending on what value was being given from
    somewhere else.
    
    If you execute your OA$FLD_STAY with a GET OA$FUNction, then you can
    provide a variable value (provided by your calling script?) for the
    field name.  Immediately after that call though, still in the /PRE
    code, call a miniature little SCRIPT script (as mentioned in .1),
    with the difference that it does a {TAB}{BS}.  This bounces you into
    the field officially, and execute the appropriate /PRE code.
    
    There will likely be a few more complications that are presented here,
    but this is a working basis.
    
    /PRE='GET OA$FUN="OA$FLD_STAY " #FLDNAME "\SCRIPT DOATABBS"'
    
    It may be late, but I hope it helps anyway.
    
    Bob Halsey, Toronto SWS