🚀 go-pugleaf

> 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   /
 ----------------------------------------------------------------------