Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!src.honeywell.com!msi.umn.edu!cs.umn.edu!kksys!orbit!incstar!lhotka
From: lhotka@incstar.uucp (Glamdring)
Newsgroups: comp.sys.amiga.tech
Subject: Re: GUI Style Question
Message-ID: <906@incstar.uucp>
Date: 1 Nov 90 00:11:47 GMT
References: <9480@milton.u.washington.edu> <1990Oct25.212714.26909@unislc.uucp> <10109@milton.u.washington.edu>
Organization: INCSTAR Corp, Stillwater MN
Lines: 74

> I just do not see how processing the contents of
> a string gadget every time the cursor is removed from it is necessary and
> desireable.  In your example of updating a record you don't need to hit
> [RETURN] under my scheme -- all string gadgets should be checked at the end
> of that record (i.e. closewindow or a NEXT RECORD gadget or whatever).  It's
> just that any sanity checking or whatever would not be applied until you hit
> [RETURN] or indicated that it was time to go on to the next record.  While

The package I am working on (hence my original question) is such that the
various editor and transaction screens have a large number of fields (some
upwords of 30...).  Many (MANY) of these fields not only require various bits
of sanity checking, but also access a database to get data to load in some of
the other fields on the screen.  It is very likely that the user will skip
around the screen a lot, especially if changing an existing set of data, as all
the fields will be filled in already.

While you can argue that the user can fill in a field, press return and then
use the mouse to select another field, this seems to be an unnecessary
condition to place upon a user.  After all, I am dealing with users who call
terminals 'computers', monitors 'TVs', etc...  It is vital that the screens be
VERY userproof...

> you can argue that you'd like immdiate sanity checking on updates, I will 
> reply that:
> 
> 1)  Such immediate checking isn't very helpful since you're probably
> only changing one field before going to the next record anyway.

You appear to be assuming simple record editing screens, where I am actually
dealing with complex transaction screens...

> 2)  It is easier for the user to use [RETURN] to move to the next string
> gadget for most opperations, so the user should be encouraged to do so.
> and

agreed - this is the case during data entry on a new or partially filled in
screen.  However, you mustn't overlook the possibility that a user is modifying
a screen which was already filled in and there are a few scattered fields to
change...

> 3) [RETURN] should move the cursor to the next string gadget, but activating
> another gadget should not.  

Obviously using the mouse to activate another gadget should only activate the
chosen gadget.  On the other hand, your program did not recieve a GADGETUP
message so it may not have processed the field you just left.  This is the crux
of my problem.  I *really* want to process that field the user just left, as it
may affect the contents of the field just entered and I want to make sure that
any defaulting, etc gets done before the user enters more information.

I have written a nice one page routine which keeps track of the GadgetID of the
last gadget and calls a ProcessGadget procedure if the most recently activated
gadget is different (whether that activation be via a RETURN moving to the next
string gadget or the mouse moving to some arbitrary field).  This appears to be
working pretty well but feels more like a workaround than an elegant
solution...

> The complexity introduced by several different
> ways of processing string gadgets does not at all seem called for by or
> supported by the operating systems and is getting close to, if not exceeding
> the threshold of what is reasonable to expect from programmers.

On this point I can only say that I firmly believe that if the user is
inconvenienced by some lack of effort on the part of the programmer then the
programmer did not do the job properly.  I have seen the effect of trying to
market software which worked as long as the user did everything perfectly - bad
move...  Users *always* screw things up if it is possible to do so.  I most
certainly do when I am being a user!! :-)
 ______________________________________________________________________
/ Rockford Lhotka				INCSTAR Corp	       \
| Systems Administrator				PO Box 285	       |
| incstar!lhotka@uunet.uu.net         		1990 Industrial Blvd   |
\ 612/779-1701					Stillwater, MN 55082   /
 ----------------------------------------------------------------------