Conference iosg::all-in-1_v30

    How about:
    
    	;;PROJ_START_FORE;;
    
    /GET=OA$DATE_NBS::2/BLANK
    
    OR 
    
    /GET=OA$DATE:2 OA$DATE:2:3 OA$DATE:2:6/BLANK
    
    Rick
    

    Thanks for the reply. The date field is defined as 99/99/99 and
    naturally the default value is zeros. the system does not see this as
    blank, as far as I can tell.
    
    Dave Kinney

>    I have the current named data on the entry form:
>    
>    ENTRY/MODE=UPDATE/HARD='WHITE SHEET MANAGEMENT SYSTEM'
>    /PRE='IF OA$ENTRY_FORM_MODE EQS "1" THEN GET PROJ_START_FORE =
>     OA$DATE:2 OA$DATE:2:3 OA$DATE:2:6'


Do you mean, '.IF OA$ENTRY_FORM_MODE...'?  Notice the period.

If this doesn't fix it, try:

     ENTRY/MODE=UPDATE/HARD='WHITE SHEET MANAGEMENT SYSTEM'
    /PRE='.IF PROJ_START_FORE lt 1 THEN GET PROJ_START_FORE =
     OA$DATE:2 OA$DATE:2:3 OA$DATE:2:6'

Pleasant coding,

Joe

    Interesting thing about this is that when you call an entry
    form/mode=add and the form is painted leaving you on the key field and 
    you test entry_form_mode at this point, before the key is entered, it
    is equal 0. After the key is entered and you hit a return, then the
    mode is evaluated and is changed to 1. Therefore, if you test for it, you
    have to do it on the next non key field as say a pre function, not as a
    form pre function under type
    
    I guess I would had hoped/assumed that the mode would be evaluated on the 
    form call since I am being specific about the mode right in the syntax or 
    at least some time prior to the pre functions being evaluated.
    
    So thanks to Cathy and Tim at Atlanta, we put the if as a pre function
    on the next field, a get_save on the date field, and a get on the
    Create call from the menu. 
    
    Dave Kinney

	Although I haven't tested this, I would suspect that if you called the
entry form with a /SAVE_START, and specified the key of the record, then your
/PRE would have worked.  You have to remember that invoking an entry form with
the FORM function causes the entry form to be processed twice -- once to get the
key, and once to process the entire record.  Since there is already some special
processing done on that first pass (such as a /FIELD=keyfield, so that only the
key field is processed), I would not be surprised that there are other unusual
things going on as well.  Also, keep in mind that the mode of the form is not
determined until *between* the two passes -- that is, *after* it has gotten the
key, and *before* it processes the entire record.  (To verify this, call the
form in UPDATE mode, and note when you are prompted for the mode...)

	F

Frank,

When you realize that an entry form is processed twice the behavior does
make sense.  I would argue though, that since the first pass is only to
get the key, the /PRE form qualifier should not be dispached until the
second pass.  If someone wanted a /PRE invoked during the first pass, he
could make it a /PRE field qualifier on the key field.

The problem with puting a /PRE field qualifier on some other field is that
it's possible that field is not always included in the /FIELD list when
the form is called.

Others might of course think this would be unatural behavior, and it's 
probably impossible to change the behavior at this point without breaking
lots of existing applications.

Perhaps, as a wish, we could have a /PRE_KEY form qualifier and a
/POST_KEY form qualifier.  (The /PRE_KEY would of course not be necessary
since it would behave the same way as a /PRE form qualifier does now.)

Just a thought,

Joe