Re: catch 22
Irv, I understand what you are saying but I basically disagree with that
approach (that was the way it was back in 1960 with IBM 3270 stuff). For
example on a customer entry screen you don't know what the valid entries
could be until you know who the customer is(i.e some demand PO's others are
only COD, and so on). I would also think it would be irritating to a user to
enter an entire form and not fuss at them at the point of entry but have a
bunch of edit errors blown back at him.
Never the less, I'm getting the drift...
thanks...
...george
----- Original Message -----
From: "Irv Mullins" <irvm at ellijay.com>
To: "EUforum" <EUforum at topica.com>
Sent: Thursday, August 16, 2001 12:23 PM
Subject: Re: catch 22
> >
> On Thursday 16 August 2001 10:53, George Walters wrote:
> >
> > I have onLostFocus set in order to edit an input field when tab'ed away
> > from or mous'ed away from. I also have an 'abort' button if the user
gives
> > up on the screen. The problem is that the onLostFocus event gets
processed
> > before the button press and my program tries to edit the left field. So
I
> > guess i'd like to get the button press event before any other events. Is
> > this possible? Or how can I handle this?
>
> I think Derek mentioned this earlier, but I'll put it in my own words:
>
> Since in Windows (or other GUI) the user can enter data in whatever
> order they like, validating an entry at the time of entry is a bad idea.
> Validation and/or rollback should be done on completion of the entire form
> (screen) at the time the user clicks the "OK" or "Cancel" button.
>
> Trying to validate one field when the contents of the other fields can
> be changed is fruitless.
>
> In addition, it is generally a poor idea to have much validation going on,
> anyway. The normal "windows way" is to, whenever possible, limit the
> user to only those options that are valid, thru drop-down menus,
> checkboxes, radio button choices, calendars, etc.
>
> Regards,
> Irv.
>
> >
> >
>
>
|
Not Categorized, Please Help
|
|
