powerh-l Digest, Vol 3, Issue 10
David Morrison - Corporate
dmorrison at mcbrideelectric.com
Thu Aug 11 13:23:50 CDT 2005
Guy,
Hmmm... I thought that it will still be in FIELDTEXT if it's numeric, in the EDIT procedure.
David Morrison
McBride Electric
-----Original Message-----
From: powerh-l-bounces+dmorrison=mcbrideelectric.com at lists.sowder.com
[mailto:powerh-l-bounces+dmorrison=mcbrideelectric.com at lists.sowder.com]
On Behalf Of Guy Werry
Sent: Thursday, August 11, 2005 11:19 AM
To: powerh-l at lists.sowder.com
Subject: RE: powerh-l Digest, Vol 3, Issue 10
Actually, when the EDIT procedure executes, isn't it a case of the
distinction between alph and numeric has been made?
That is, if the field is alphabetic, then the input value resides in
FIELDTEXT; if the field is numeric (including type DATE), then the input
value resides in FIELDVALUE.
I realize that it's a small distinction, but I've been tripped up by small
things like this in the past.
So, at the INPUT procedure we just have the user input and it's stored in
FIELDTEXT. At the EDIT procedure we've made the alpha or numeric
distinction.
Guy L. Werry
Senior Systems Analyst
Hudson Bay Mining & Smelting Co., Limited.
-----Original Message-----
From: David Morrison - Corporate [mailto:dmorrison at mcbrideelectric.com]
Sent: Thursday, August 11, 2005 1:09 PM
To: roger32909 at bellsouth.net; powerh-l at lists.sowder.com;
powerh-l at lists.sowder.com
Subject: RE: powerh-l Digest, Vol 3, Issue 10
Roger,
It's documented that PowerHouse works that way. In INPUT procedures,
FIELDVALUE hasn't been set, yet; PH doesn't yet know if it's alpha or
numeric. By the time the EDIT procedure executes, FIELDVALUE HAS been set.
David Morrison
McBride Electric
-----Original Message-----
From: powerh-l-bounces+dmorrison=mcbrideelectric.com at lists.sowder.com
[mailto:powerh-l-bounces+dmorrison=mcbrideelectric.com at lists.sowder.com]
On Behalf Of roger32909 at bellsouth.net
Sent: Thursday, August 11, 2005 10:42 AM
To: powerh-l at lists.sowder.com; powerh-l at lists.sowder.com
Subject: Re: powerh-l Digest, Vol 3, Issue 10
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
> ***************************************
>
--
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
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.
--
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
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.
More information about the powerh-l
mailing list