cancelation of Del on input statement and date field storage(was: Re: doedit usage)
Bruce Easton
bruce at stn.com
Tue Oct 7 12:22:22 PDT 2008
Bruce Easton said Tuesday, October 07, 2008 2:56 PM:
> To: filepro list
> Subject: Re: cancelation of Del on input statement and date field
> storage(was: Re: doedit usage)
>
>
> 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
>
Well, first of all, let me state - this is under 05.0.14.
Now regarding just the edit issue, I did two more tests, both
of them writing to real fields, and here's the first one:
1 ------- - - - - - - - - - -
top If:
Then: end
2 ------- - - - - - - - - - -
@update If:
Then: pd="093108"
3 ------- - - - - - - - - - -
If:
Then: 5=pd; write
4 ------- - - - - - - - - - -
If:
Then: screen; goto top
This worked as expected. pd is undeclared and field 5
winds up being blank after the assignment.
And now a variation on my original code (using @update so
I could store the resulting date):
[Real field 5 is (8,mdy/).]
1 ------- - - - - - - - - - -
top If:
Then: end
2 ------- - - - - - - - - - -
@update If:
Then: input pd(8,mdy/) "Enter Date: "
3 ------- - - - - - - - - - -
If:
Then: pe(8,mdy/)=pd; 5=pe; write
4 ------- - - - - - - - - - -
If:
Then: screen; goto top
In this case, pe and real field 5 hold an invalid date
value. It's like the assignment of pe and field 5 says
that if the source comes from a date type field, it
must be OK, so assign it as is.
Bruce
Bruce Easton
STN, Inc.
More information about the Filepro-list
mailing list