powerh-l Digest, Vol 3, Issue 10
roger32909 at bellsouth.net
roger32909 at bellsouth.net
Thu Aug 11 12:42:09 CDT 2005
May God bless all of you, Joe, Ken and Lorry. All your solutions work!
Here is what we ended up using (which seems to work find in tests):
;dummy procedure to force EDIT if user skips entry:
PROCEDURE INPUT INVOICE-DATE OF VENDOR-INVOICE-HEADER
BEGIN
IF FIELDTEXT = ""
THEN LET FIELDTEXT = "0"
END
I find it odd that INPUT documentation says to use FIELDTEXT
while the EDIT documentation says to use FIELDVALUE for a date field. However, when I tried
using FIELDVALUE in INPUT, it did not work. However, FIELDVALUE works
just fine in the EDIT procedure.
Roger
>
> From: powerh-l-request at lists.sowder.com
> Date: 2005/08/11 Thu PM 01:00:28 EDT
> To: powerh-l at lists.sowder.com
> Subject: powerh-l Digest, Vol 3, Issue 10
>
> Send powerh-l mailing list submissions to
> powerh-l at lists.sowder.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.sowder.com/mailman/listinfo/powerh-l
> or, via email, send a message with subject or body 'help' to
> powerh-l-request at lists.sowder.com
>
> You can reach the person managing the list at
> powerh-l-owner at lists.sowder.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of powerh-l digest..."
>
>
> Today's Topics:
>
> 1. RE:Re: EDIT procedure for fields in cluster? (Ken Langendock)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 11 Aug 2005 09:42:38 -0400
> From: "Ken Langendock" <Ken at Langendock.com>
> Subject: RE: Re: EDIT procedure for fields in cluster?
> To: <powerh-l at lists.sowder.com>
> Message-ID: <000b01c59e7a$89e67df0$5502a8c0 at KenLangendock>
> Content-Type: text/plain; charset="us-ascii"
>
> 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.
>
>
>
> ------------------------------
>
> --
> = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> 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.
>
>
> End of powerh-l Digest, Vol 3, Issue 10
> ***************************************
>
More information about the powerh-l
mailing list