cancelation of Del on input statement and date fieldstorage(was:Re: doedit usage)

[Bruce Easton]

Bruce Easton wrote Tuesday, October 07, 2008 3:42 PM:
> To: filepro list
> Subject: RE: cancelation of Del on input statement and date
> fieldstorage(was:Re: doedit usage)
>
>
> Bruce Easton wrote Tuesday, October 07, 2008 3:39 PM
> > To: filepro list
> > Subject: RE: cancelation of Del on input statement and date
> > fieldstorage(was:Re: doedit usage)
> >
> >
> > Bruce Easton wrote Tuesday, October 07, 2008 3:22 PM:
> > >
> > > 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 - use input popup - it doesn't have this problem -
> > since it is a popup, Del in this case does not have
> > a cancelation of deletion option for *nix like input has,
> > and processing continues where either the value can
> > be tested (or a test for BRKY IS obeyed), or the edit is
> > applied as expected resulting in a blank field (for a bad
> > date value).
> >
> > Bruce
> >
>
> Bruce - thanks  - the behavior seems inconsistent.  Thanks
> for the testing.
>
> Bruce

Yeah - it does - you're welcome.

Bruce