home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / os / mswindo / programm / misc / 4288 < prev    next >
Encoding:
Internet Message Format  |  1992-12-16  |  3.3 KB
  1. Path: sparky!uunet!lax.pe-nelson.com!lax!twbrown
  2. From: twbrown@PE-Nelson.COM (Tom W. Brown)
  3. Newsgroups: comp.os.ms-windows.programmer.misc
  4. Subject: Re: controls in dialog boxes
  5. Message-ID: <716@lax.lax.pe-nelson.com>
  6. Date: 17 Dec 92 00:20:58 GMT
  7. References: <1992Dec16.161057.11842@midway.uchicago.edu>
  8. Sender: news@lax.pe-nelson.com
  9. Organization: PE-Nelson
  10. Lines: 60
  11.  
  12. In article <1992Dec16.161057.11842@midway.uchicago.edu>, srao@quads.uchicago.edu (Shanta Rao) writes:
  13. |> 
  14. |>  As in other standard dialog(s), the only way to exit is by choosing "OK" or
  15. |>  "CANCEL" buttons, at the beginning i was taking care of updating all the 
  16. |>  fields in the dialog as soon as the user hits OK, but then i realised that
  17. |>  (s)/he might not want to use all the fields in the dialog -- right? 
  18.  
  19. Mmmmm, I would say that the only way to exit a dialog box (assume a modal,
  20. DialogBox(), dialog) is by calling EndDialog().  You can call this function
  21. anywhere, in response to any message, but it certainly is conventional to do
  22. so in response to the OK or Cancel pushbuttons.
  23.  
  24. As far as reading/using all the fields in the dialog, assuming that you have
  25. initialized them during WM_INITDIALOG with the current values, if the user
  26. hasn't changed them then why not just get all control values at IDOK time,
  27. it shouldn't make any difference.
  28.  
  29. I don't think you'd really save anything by keeping track, on a control
  30. by control basis, of what the user may have actually changed in order to
  31. save time during IDOK processing.  This assumes that you don't need to
  32. do some kind of monster processing to validate input from the controls.
  33.  
  34. There are reasons to track control changes on a real-time basis -- if you
  35. want to perform input validation sooner than at IDOK time, or changes to
  36. one control affect the status (enabled/disabled, shown/hidden, etc.) of other
  37. controls in the dialog.
  38.  
  39.  
  40. |> 
  41. |>  I have tried the following: for a edit control type when the one tries to
  42. |>  change the value (EN_CHANGE message) i set the flag, but apparently this flag 
  43. |>  being set every time i enter the dialog -- why is this happening? 'm i missing
  44. |>  something ? What should i do if user clicks in that region?
  45.  
  46. You are probably calling SetDlgItemText() for the edit control while
  47. initializing the dialog.  This causes a change to the control text and it
  48. promptly notifies you that this happened.  One common way to work around
  49. this is to have a static flag in your dialog procedure that you set while
  50. processing the WM_INITDIALOG message and then clear when done.  When you
  51. process the EN_CHANGE notification, first examine this static flag.  If it
  52. is set then ignore the notification, otherwise set your other flag to
  53. indicate a change.
  54.  
  55. This may seem like a hack, but I'll bet it's fairly common -- I use it in
  56. a couple of places (I don't know what exactly that says about it, though :-)
  57.  
  58.  
  59. |>  
  60. |>  Hope the problem is clear. If anybody have any ideas/ suggestions for this,
  61. |>  please send me an e-mail
  62.  
  63. This seemed general enough to follow-up to on the net.
  64.  
  65.  
  66.  
  67. ----------------------------------------------------------------------------
  68. Tom Brown               |  "She turned me into a newt...
  69. PE Nelson Systems       |                                  ... I got better"
  70. twbrown@pe-nelson.com   |                    Monty Python and the Holy Grail
  71. ----------------------------------------------------------------------------
  72.