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
_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution
