Path: utzoo!attcan!uunet!jarthur!nntp-server.caltech.edu!mustang!topgun!lll-winken!uwm.edu!rpi!dali.cs.montana.edu!milton!blake.u.washington.edu!dlarson
From: dlarson@blake.u.washington.edu (Dale Larson)
Newsgroups: comp.sys.amiga.tech
Subject: Re: GUI Style Question
Message-ID: <9480@milton.u.washington.edu>
Date: 18 Oct 90 13:04:59 GMT
References: <8973@milton.u.washington.edu> <1990Oct12.053232.22478@nas.nasa.gov> <635@incstar.uucp>
Sender: news@milton.u.washington.edu
Organization: The Evergreen State College,  WA
Lines: 28

In article <635@incstar.uucp> lhotka@incstar.uucp (Glamdring) writes:
>In article <1990Oct12.053232.22478@nas.nasa.gov>, 
>         smithwik@pioneer.arc.nasa.gov (R. Michael Smithwick -- FSN) writes:
>> So make sure to read the gadgets buffer and never assume the user hit the 
>> CR.
>
>My solution (this is the question part of this post...) is to always keep track
>of which field was most recently activated (GADGETDOWN) and to perform the
>field processing code on GADGETDOWN messages if the newly activated gadget
>doesn't match the last activated gadget.  Is this the best way to do this?  It

That looks like somewhat of an unnecessary pain.  If you have several string
gadgets, hitting return in one of them should move you to the next.  There
should be no need to touch the mouse.  Doing field processing code only on
[RETURN] and before going on to the next record makes your life easier. 
Hitting return each time makes the user's life easier.  So document that fact
and encourage him or her by not doing field processing unless [RETURN] is
hit or at the end of the record (and if you find an error in field processing
at the end of the record, tell the user about [RETURN] again).  

Hopefully C/A will soon have a style manual giving us clear direction on 
"the correct" way to do many things like this in a very user-friendly way.  

If we're lucky, GadTools 2.1 (or whatever) will support a list of string
gadgets which take care of activating each other since that would make
things even simpler.
--
-Dale Larson  (dlarson@blake.u.washington.edu)