cancelation of Del on input statement and date field storage (was: Re: doedit usage)
Bruce Easton
bruce at stn.com
Tue Oct 7 11:55:42 PDT 2008
Bruce Easton wrote Tuesday, October 07, 2008 2:34 PM:
>
> Scott Walker wrote Tuesday, October 07, 2008 1:50 PM:
> >
> > I have a sort/select process.
> >
> > In an input statement, the user enters a Post Date in pd(8,mdy/)
> >
> > If they enter "09/31/08" the edit on pd will not take it.
> >
> > If they enter "093108" and press <del> ONE TIME, and then press <Enter>,
> > the "093108" is accepted and the processing moves on to the next line.
> >
> > Testing for @sk eq "BRKY" does not seem to prevent this since the last
> > @sk is really "ENTR".
> >
> > So I'm trying to use "doedit" as an extra check of the validity of the
> > date entered.
> >
> > I tried:
> >
> > dt=doedit(pd,"mdy/")
> >
> > Then I test to see if dt is blank, as I thought it would be since the
> > value of "093108" should not pass the mdy/ edit.
> >
> > But the value of dt shows "093108"
> >
> > Any suggestions?
> >
> > Scott Walker
> > RAM Systems Corp.
> > Email: ScottWalker at RAMSystemsCorp.com
> > Phone: (704) 896-6549
> > Web: www.RAMSystemsCorp.com
> >
>
> Well, Scott, this sounds about as strange as Barbara Walters announcing
> the opening of a Wawa in Walla Walla, Washington, so curiosity
> has the best
> of me.
>
> Thankfully, I don't see this happening on a screen where a real date field
> is involved. But I so see what you are seeing with the input statement -
> even in clerk. The clerk code I used is below and yields the
> same behavior
> that you are seeing. In the case below, what's alarming is that
> the invalid
> date value entered is passed on and assigned to the next dummy field "pe"
> (the show statement at runtime [after entering 093108, then a 'Del' then
> either 'N' or the Enter key] shows the value of pe to be 093108). Don't
> have any recommendations - and this behavior for the input statement seems
> bad to me. (Since the operator has canceled a [BRKY] operation, I would
> think filePro should re-focus the input field.) Also, I had no 'pd' nor
> 'pe' in any automatic processing that would have overriden the fields 'pd'
> and 'pe'.
>
> 2 ------- - - - - - - - - -
> @menu If:
> Then: input pd(8,mdy/) "Enter Date: "
> 3 ------- - - - - - - - - -
> If:
> Then: pe(8,mdy/)=pd
> 4 ------- - - - - - - - - -
> If: pe eq ""
> Then: goto @menu
> 5 ------- - - - - - - - - -
> If:
> Then: show "@Date entered is:"<pe
> 6 ------- - - - - - - - - -
> If:
> Then: exit
> ==============================================
>
> Bruce
So maybe someone can refresh my memory so that this doesn't look
bad to me. Two things seem wrong:
1. The assignment of an invalid date value to a date type
field resulting in storage of the invalid value, and
2. Cancelation of the Del key (for *nix) not re-focusing
an input statement.
Maybe this is the way it's supposed to be and I just forgot.
Bruce
Bruce Easton
STN, Inc.
More information about the Filepro-list
mailing list