home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sys / mac / hypercar / 3286 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  2.4 KB

  1. Path: sparky!uunet!dtix!darwin.sura.net!jvnc.net!yale.edu!yale!gumby!destroyer!ncar!ncar.ucar.edu!hpoppe
  2. From: hpoppe@ncar.ucar.edu (Herb Poppe)
  3. Newsgroups: comp.sys.mac.hypercard
  4. Subject: Validating Data Entry in a Field: Conclusion
  5. Message-ID: <1992Aug28.215657.18269@ncar.ucar.edu>
  6. Date: 28 Aug 92 21:56:57 GMT
  7. References: <1992Aug18.202825.24625@ncar.ucar.edu>
  8. Sender: news@ncar.ucar.edu (USENET Maintenance)
  9. Organization: National Center for Atmospheric Research
  10. Lines: 34
  11.  
  12. In article <1992Aug18.202825.24625@ncar.ucar.edu> hpoppe@ncar.ucar.edu 
  13. (Herb Poppe) writes:
  14.  
  15. > I need to ensure that a user correctly enters data into a field. I want 
  16. > the selection point to remain in the field until a correct value is 
  17. > entered. HyperTalk allows me to trap user attempts to "escape" the field 
  18. > by typing TAB or RETURN or ENTER. However, I see no convenient way to 
  19. trap 
  20. > the user's clicking a button, in another field, or in the card, thus 
  21. > leaving an invalid value left in the field. Have a missed an obvious (or 
  22. > not so obvious) approach to this issue?
  23.  
  24. Thanks to all who replied via e-mail and netnews postings. My conclusion 
  25. is that there is no straightforward way of doing what I wanted.
  26.  
  27. I found I was getting all wrapped up in this issue, and forgetting that I
  28. was creating a "throw-away" stack to answer a particular question.  So,
  29. rather than insisting on "doing it my way", I took the advice of someone
  30. who suggested an approach used in the Valid Entry Package, a stack written
  31. by someone at Apple that is available on the Developer CDs.  Basically, if
  32. the field is in error at closeField/exitField time, replace the data the
  33. user entered with the previously entered value (presumably correct).
  34. Since what I was entering were long bit strings, I didn't want to adopt
  35. exactly this approach, since it meant retyping in that long string of
  36. bits.  Instead, I set the style of the text to italic as a reminder
  37. that the data was in error.  Also, I just blanked those (locked) fields
  38. whose values were derived from the incorrect value.  Also, the fields have
  39. a keyDown handler which checks for errors that can be determined when a
  40. character is typed, and discarding that character after a warning alert.
  41. This reduces the errors that are reported at closeField time.
  42.  
  43. Herb Poppe                 National Center for Atmospheric Research (NCAR)
  44. hpoppe@ncar.ucar.edu       1850 Table Mesa Dr.
  45. (303) 497-1296             Boulder, CO  80303
  46.