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

  1. Path: sparky!uunet!van-bc!rsoft!mindlink!a347
  2. From: John_Miller@mindlink.bc.ca (John Miller)
  3. Newsgroups: comp.sys.mac.hypercard
  4. Subject: Re: Validating Data Entry in a Field
  5. Message-ID: <14612@mindlink.bc.ca>
  6. Date: 26 Aug 92 23:06:31 GMT
  7. Organization: MIND LINK! - British Columbia, Canada
  8. Distribution: world
  9. Lines: 110
  10.  
  11. In article <1992Aug18.215256.1379@ncar.ucar.edu> hpoppe@ncar.ucar.edu
  12. (Herb Poppe) writes:
  13. >> If I'm not mistaken (I haven't tried this) the exitField handler
  14. >> does what
  15. >> you want. It is called every time the cursor leaves the field,
  16. >> *even* if the the field data is unchanged.
  17. >
  18. > The problem is that there is no way (that I have found) to force
  19. > the cursor back into the field using the closeField (or exitField)
  20. > handler. It seems to me that I am going to have to trap every
  21. > mouseUp sent to the card or button and every openField sent to
  22. > other unlocked fields as a result of clicking outside of the
  23. > field in error. That handler (in the card) will have to check
  24. > if there is an error pending in a field. If there is, it will put
  25. > the insertion point back in that field. If not, it will send a
  26. > "myMouseUp" message back to the target of the mouse click.
  27. > Similarly for openField.
  28.  
  29. Gadzooks!  You're right!
  30.  
  31. I've been using code something like this to check for errors:
  32.  
  33. on closeField
  34.   if me is not a number then
  35.      answer "Gimme numerics or gimme death!"
  36.          select char 1 to 1000 of me
  37.   end if
  38. end closeField
  39.  
  40. This works great when the user moves around with the
  41. Tab key.  (Notice I am *not* trapping tabKey directly.)
  42. I never realized it didn't work when the user used the
  43. mouse to exit the field.  I used to think that HyperCard
  44. included "special case" code to handle this type of
  45. error checking, but now I guess it is just a fluke
  46. based on the way that the Tab key and select command
  47. code is implemented.
  48.  
  49. Trapping openField is not going to work:  selecting
  50. the other field in openField doesn't "stick"
  51. either.  (Actually selecting field 1's text in
  52. field 2's openField handler seems to stick if you
  53. start with no field selected, but not if you start
  54. with field 1 selected:  strange.)  You could try a
  55. transparent button that covers everything that you
  56. would show and hide/reclick, but then your cursor
  57. would not change properly over fields without even more work.
  58.  
  59. You might try something like:
  60.  
  61. on closeField
  62.   global errorRecovery
  63.  
  64.   if me is not a number then
  65.     answer "I simply can't handle this junk."
  66.     put "select char 1 to 1000 of" & the name of me into errorRecovery
  67.   end if
  68. end closeField
  69.  
  70. and then in the card/background/stack
  71.  
  72. on idle
  73.   put hadError() into dummy
  74. end idle
  75.  
  76. function hadError
  77.   global errorRecovery
  78.  
  79.   if errorRecovery is not empty then
  80.     do errorRecovery
  81.         put empty into errorRecovery
  82.         return true
  83.   else
  84.     return false
  85.   end if
  86. end hadError
  87.  
  88. You may still have to checks into some mouseUp handlers
  89. that would check whether hadError() was true or false.
  90.  
  91. A 'go to card x"' could be added to the errorRecovery
  92. commands to trap moves to other cards, if the idle
  93. handler is high enough in the hierarchy.
  94.  
  95. It will be a lot of work to trap every event that
  96. can cause the field to be deselected to ensure
  97. that the data is always validated.  (For instance,
  98. you would have to trap Command-Q to prevent the
  99. user from quitting with invalid data. Or: a "start
  100. using this stack" would also be necessary if you
  101. are planning on trapping clicks on background
  102. stacks as well. Very messy)  An approach
  103. I favour is to check for errors at two times:
  104. closeField and within whatever handler actually
  105. has to use the data.  This allows detecting errors
  106. immediately when the user makes a change while
  107. allowing the user to then ignore the error
  108. by exiting the field without further changes
  109. (to go to a help stack or perhaps to quit and
  110. try again later with the local expert who
  111. understands this picky computer).  Your
  112. data processing scripts then rechecks for
  113. validity to protect itself.
  114.  
  115. ______________________________________________________________________
  116. John Miller                      (604) 433-1795
  117. Symplex Systems                  internet:  john_miller@mindlink.bc.ca
  118. Macintosh Consulting and Software Development
  119. ______________________________________________________________________
  120.  
  121.