setting pointer location

[Alan Gayne]

On Friday, December 27, 2002, at 04:32 PM, Rob Cozens wrote:

>  How would you handle data maintenance (as opposed to new data entry), 
> where there are many fields on the screen, but the user may need to 
> change only one or two?  I do this by having each field's title icon 
> respond to mouse messages when the operation mode is "Edit" rather 
> than "New."
>

Hi Rob,

My approach is fairly similar, but with a few variations.  Typically, I 
will use locked fields with shared text as my "labels".  I prefer these 
to standard label fields, mostly to have better control over their 
appearance.  Typically, these will have a different background color 
(say light grey) while the data field might be pale yellow (but deeper 
when "active").

Since the user will generally click on either the field itself or the 
the label, the handler for the data field would, in its most basic form 
be:

on mouseUp
	if the sharedText of the target is false then askMeTheQuestion
end mouseUp

Since most of my data fields are grouped for logical reasons, I usually 
need only 1 such handler per group.

Each label field might have a handler such as:

on mouseUp
	askMyFriend "myfield","name"
end mouseUp

with the following handler usually in the stack script:

on askMyFriend whichFriend,fldRef
   if fldRef is "name" then
     send "askMeTheQuestion" to fld whichFriend
   else
     send "askMeTheQuestion" to fld id whichFriend
   end if
end askMyFriend

To add yet another level of redundancy, I will typically attach a 
"popup" menu (see my "roving popup" demo stack at the RunRev site in 
the user contribution section) to the "master" label of each logical 
grouping which will also allow (if that is MY intent) any or all of the 
fields in the group to be edited.  A "master" label might be something 
like "CUSTOMER'S ADDRESS", while the individual labels might be "House 
#", "Street", "PO Box", "City", "State, and "Zip Code"

As I've said, these are the basic script forms involved.  If desired, I 
can easily set up as many levels of protections or intent queries (i.e. 
"do you REALLY want to change this information") as necessary to 
prevent unauthorized or inadvertent entry, changes or deletions to the 
data.  This approach eliminates virtually all "Oops!  I accidentally 
hit delete" losses of data.  I've used this basic technique extensively 
  in Hypercard since 1987 and I've found it to be both simple to 
implement and extremely protean in it's application for data entry 
situations.

I don't think you'll find it necessary, but if you still need to see a 
"real world" implementation, contact me off-list and as soon as I get a 
chance I'll throw a small demo stack together for you to look at.

Regards to all,
Alan