Re: RE: FW: Keyword on DSPF entry field

["Mike Naughton" <mnaughton@xxxxxxxxxxxx>]

This may be a minor point, but it seems to me that the answer to whether
any key works "properly" depends on its intended function. I don't see any
reason to assume that the behaviors of Enter and Tab in the 5250 world
were chosen arbitrarily -- in fact, they make perfect sense (to me,
anyway).  The fact that you can use Tab to move from field to field on the
screen, whether you have retyped data in the fields or not,  can be very
handy (and can save a lot of retyping). Like many handy features,
sometimes it's not so handy, but I'm not sure it's reasonable to expect a
perfect solution. I don't think you want to disable Tab unconditionally
(how would users move around the screen?). So would it be only if another
key is pressed first? And then only if FE is specified? Maybe only for
numeric fields? Programmer choice (numeric/character/both)? It seems to me
that the solution you found perfect would likely irritate someone else
(after all, the solutions others are happy with seem to irritate you :-),
so how is IBM going to win?

In my experience, if you really don't want to validate your data back in
the program, then you leave yourself open to a host of potential problems,
of which the ones eliminated by disabling the Tab key would be only a
small subset. The sad, but inescapable, fact is that people will make all
kinds of mistakes, and the majority of coding in just about every program
that has a  user interface is for trying to identify and react to those
mistakes. At least, that's what I've found -- if anyone has discovered a
way around this, I'd love to hear it!

JMHO

rpg400-l@midrange.com writes:
>The fact that the Enter key works properly and the Tab
>key doesn't tells me it was a design choice made by the vendor,
>arbitrarily.


Mike Naughton
Senior Programmer/Analyst
Judd Wire, Inc.
124 Turnpike Road
Turners Falls, MA  01376
413-863-4357 x444
mnaughton@juddwire.com