home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / pascal / 4499 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  2.8 KB
  1. Path: sparky!uunet!decwrl!waikato.ac.nz!canterbury.ac.nz!lincoln.ac.nz!cachoo
  2. Newsgroups: comp.lang.pascal
  3. Subject: Re: Input validation standards (was Re: ... Inputing Real Numbers)
  4. Message-ID: <1992Jul22.171117.222@lincoln.ac.nz>
  5. From: cachoo@lincoln.ac.nz
  6. Date: 22 Jul 92 17:11:16 +1200
  7. References: <10529810.23.711265015@eng2.eng.monash.edu.au> <9978@vice.ICO.TEK.COM> <54370@mentor.cc.purdue.edu>
  8. Distribution: comp.lang.pascal
  9. Lines: 48
  10.  
  11. In article <54370@mentor.cc.purdue.edu>, pf@bilbo.bio.purdue.edu (Paul Furbacher) writes:
  12. > In article <9978@vice.ICO.TEK.COM>, bobb@vice.ICO.TEK.COM (Bob Beauchaine) writes:
  13. >>   I recently received email from a user of TVinp101 who mentioned a
  14. >>   question touched on in passing on this group:
  15. >>   What is the proper way to check the validity of an input in a
  16. >>   dialog box?  I don't have a copy of the CUI spec, but a poster
  17. >>   here as I remember mentioned that no input should be validated
  18. >>   until the user attempts to close the dialog.  My routines
  19. >>   currently trap keystrokes that change the focused view and
  20. >>   validates the input right on the spot, but I made
  21. >>   no attempt to trap mouse initiated focus changes.  As I
  22. >>   contemplate an upgrade, I would like to resolve this issue before
  23. >>   I release a new version.
  24. > 
  25. > 
  26. > I had wondered about this, too.  In deriving an  input validation for 
  27. > descendents of TInputLine (hadn't seen Bob's unit on garbo), the 
  28. > question of whether to trap loss-of-focus caused by the mouse
  29. > arose.  Surveying many programs which do and do not conform 
  30. > to CUA standards, it appears that none do this.  I tried 
  31. > various schemes for doing this, but it seemed too difficult to 
  32. > implement (but I was much less experienced with TV at 
  33. > that time).
  34. <...>
  35. > though few implement this.  Could it be that mouse  events
  36. > in event-driven systems are handled in such a way as
  37. > to make this more difficult to implement, therefore, the path
  38. > of least resistance is taken time-after-time?  It seemed 
  39. > difficult to trap the loss-of-focus caused by the mouse 
  40. > in TV.  Since I made my compromise, I haven't 
  41. > thought/worried about it since.
  42. > 
  43. > In terms of the mouse and *most* (not all) operations, 
  44. > my advice is "use the  keyboard".  For many users, that's 
  45. > a novel idea.
  46.  
  47. Excuse my ignorance, I don't know what CUA standards are. But concerning
  48. input validation in TV, I've found it convenient to use the cmReleasedFocus
  49. broadcast command. This command is issued everytime a view losses focus,
  50. whether through keyboard or mouse action, this command informs TDialog that 
  51. it should give focus to a different view. So my approach is to create a
  52. TSmartInputLine whose HandleEvent responds to cmReleasedFocus (this command
  53. is broadcast back from the dialog to all its subviews), if the Event.InfoPtr
  54. is equal to @Self, then the input line 'knows' that it should validate itself.
  55. Makes sense?
  56.  
  57. Oscar
  58.  
  59.