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

[Scott Walker]

-----Original Message-----
From:
filepro-list-bounces+scottwalker=ramsystemscorp.com at lists.celestial.com
[mailto:filepro-list-bounces+scottwalker=ramsystemscorp.com at lists.celest
ial.com] On Behalf Of Bruce Easton
Sent: 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



Bruce,

If this is the way it's supposed to be then goooood lordy.  It explains
how over the years I occasionally get some invalid data in a field.

it's an input statement using a variable with a date edit

if fp accepts the data entered and moves forward, then damn it,
shouldn't it be a valid date?

Granted this does not happen often...the user must first enter an
invalid date, then the user must press the <del> key only once (not the
normal twice to cancel), then the user must press <Enter>

I should have stated that this is in 5.0.14 rclerk & rreport.

I also tried it with 5.6.01 rclerk and get the same results.

The code is very simply:


	If:	
	Then:	input pd(8,mdy/)"Enter Post Date: "

	If:	@sk eq "BRKY"
	Then:	exit

	If:
	Then: show"@Value of pd: "&pd


If they enter a post date of "09/31/08" fp does not allow it since it is
an invalid date.

If they enter a post date of "093108  "  and press <Enter>, fp does not
allow it since it is an invalid date.

If they type "093108  " and press <del> once, then press <Enter>, fp
takes the invalid date, does not format it, and
shoves it into pd, so the value of pd shows as "093108  ".  Not a valid
date & not a valid date format.  Fp is losing itself when they press
<del> then enter.

I've figured out how to test for this, I just don't think I should have
to.  I think this is a bug.