If the first field of the cluster is "//" then the cluster assumes no
entry, then all required fields are no longer required (hence the
warning message). The only way that I know of stopping a user from
passing a field that is required is to let it equal itself.
In the case of a DATE field;
1) If your date format is YYYYMMDD then the syntax would be:
IF 0 EQ SIZE(FIELDTEXT) AND &
NOT FINDMODE ; ignore this if you are FINDing or SELECTing
[and DateField OF Filename NE 0] ;optional if you default the date
before getting here
THEN LET FIELDTEXT = ASCII(DateField OF Filename)
2) If your date format is MMDDYYYY then the syntax would be:
IF 0 EQ SIZE(FIELDTEXT) AND &
NOT FINDMODE ; ignore this if you are FINDing or SELECTing
[and DateField OF Filename NE 0] ;optional if you default the date
before getting here
THEN LET FIELDTEXT = ASCII(DateField OF Filename,8)[5:4] &
+ ASCII(DateField OF Filename,8)[1:4]
This code inputs the value already in the field back into itself,
tricking the input procedure into thinking the user entered the value
again. Your edit procedure will now invoke and you will not destroy what
was there on other occurrences of the cluster.
Ken
From: powerh-l-bounces+ken.langendock=rogers.com at lists.sowder.com
[mailto:powerh-l-bounces+ken.langendock=rogers.com at lists.sowder.com] On
Behalf Of roger32909 at bellsouth.net
Sent: August 11, 2005 8:24 AM
To: Murray Scholz
Cc: powerh-l at lists.sowder.com
Subject: Re: Re: EDIT procedure for fields in cluster?
Nothing we have tried prevents user from skipping a date field that is
2nd or more beyond the first field on a cluster line.
If we put REQUIRED, we get:
"*W* The operator can skip this or other required fields on the same
record." The VALUES option is likewise ignored.
If we put an ERROR message in an INPUT procedure, to be sure the ERROR
message is displayed, but the screen is then locked with no further
prompt for the date. If we put a WARNING message in an INPUT procedure,
to be sure the WARNING message is displayed, the zero from the
Enter/return is accepted, and the prompt goes to the next field on the
line.
If we put a silent field after the date, we received a message that
"This field must be a date," but the screen is then again locked with no
further prompt for the date.
Yes, if the user does enter something in the field, the EDIT procedure
does then execute.
Apparently the only solution is to test this field in a PREUPDATE
procedure to prevent updating of zero in a date field.
>
> From: Murray Scholz <murray.scholz at abri.une.edu.au>
> Date: 2005/08/09 Tue AM 02:11:48 EDT
> To: roger32909 at bellsouth.net
> CC: powerh-l at lists.sowder.com
> Subject: Re: EDIT procedure for fields in cluster?
>
>
> Have tried it here (vms and 710G1) , and seems to invoke edit
procedure all OK.. see this
> little example, which works just fine for both fields
>
> screen aaa
> file parameters occurs 19 times
> title " Lst-Used Lst-Used Extra" at 2,1
> title " Key Number Num Date Numeric Description
Other-Info" at 3,1
> draw 4,1 to 4,80
> skip to 5
> align (1,,4) (,,10) (,,20) (,,29) (,,42) (,,62)
> cluster occurs with parameters
> FIELD PARAM-KEY OF PARAMETERS
> FIELD LAST-USED-NUM OF PARAMETERS
> FIELD LAST-USED-NUM-DATE OF PARAMETERS
> FIELD EXTRA-NUMERIC OF PARAMETERS
> FIELD PARAM-DESCRIPT OF PARAMETERS for 1,19
> FIELD OTHER-INFO OF PARAMETERS for 1,18
> cluster
> ;-------------------------------------
> procedure edit last-used-num of parameters
> begin
> if last-used-num of parameters = 0
> then error "Cannot use ZERO..."
> end
> ;-------------------------------------
> procedure edit extra-numeric of parameters
> begin
> if extra-numeric of parameters = 0
> then error "Cannot use ZERO..."
> end
> ;--------------------------------------
> build
>
> Don't forget, that the edit procedure is only invoked if the user
actually enters some data
> into the field (ie. if the just skip through the field, , probably
leaving the data-item with
> value zero, then the edit procedure does NOT get invoked.)
>
> There are a number of ways around this, eg. making the field required
, or even resorting to
> something like...
> procedure input fieldx
> begin
> if fieldtext = "" and fieldx = 0
> then let fieldtext = "0"
> end
>
> which will force the processing into the edit procedure.
>
> Regards
> Murray Scholz
> Agricultural Business Research Institute
> University of New England
> Armidale NSW 2351 Australia
> Email murray.scholz at abri.une.edu.au
>
> roger32909 at bellsouth.net wrote:
>
> > PH 7.10G on OpenVMS.
> > We have a screen with a cluster of some nine fields arrayed
horizontally, e.g.
> >
> > Field1 Field2 Field3, etc.
> > 09
> > 10
> > 11
> > 12
> >
> > We are trying to prevent entries of zero for date and quantity
fields.
> > However, it appears that an EDIT procedure only works for Field1.
EDIT procedures for subsequent fields appear to have no effect for one
can easily enter zero and continue. Of course, we can test for this in
a PREUPDATE procedure, but we would like to give immediate feedback to
the user. Is there something special that needs to be coded in EDIT
procedures for fields in a cluster without their own ID?
> >
>
>
>
--
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Mailing list: powerh-l at lists.sowder.com
Subscribe: "subscribe" in message body to
powerh-l-request at lists.sowder.com
Unsubscribe: "unsubscribe <password>" in message body to
powerh-l-request at lists.sowder.com
http://lists.sowder.com/mailman/listinfo/powerh-l
This list is closed, thus to post to the list you must be a subscriber.