🚀 go-pugleaf

In article <1992Dec16.161057.11842@midway.uchicago.edu>, srao@quads.uchicago.edu (Shanta Rao) writes:
|> 
|>  As in other standard dialog(s), the only way to exit is by choosing "OK" or
|>  "CANCEL" buttons, at the beginning i was taking care of updating all the 
|>  fields in the dialog as soon as the user hits OK, but then i realised that
|>  (s)/he might not want to use all the fields in the dialog -- right? 

Mmmmm, I would say that the only way to exit a dialog box (assume a modal,
DialogBox(), dialog) is by calling EndDialog().  You can call this function
anywhere, in response to any message, but it certainly is conventional to do
so in response to the OK or Cancel pushbuttons.

As far as reading/using all the fields in the dialog, assuming that you have
initialized them during WM_INITDIALOG with the current values, if the user
hasn't changed them then why not just get all control values at IDOK time,
it shouldn't make any difference.

I don't think you'd really save anything by keeping track, on a control
by control basis, of what the user may have actually changed in order to
save time during IDOK processing.  This assumes that you don't need to
do some kind of monster processing to validate input from the controls.

There are reasons to track control changes on a real-time basis -- if you
want to perform input validation sooner than at IDOK time, or changes to
one control affect the status (enabled/disabled, shown/hidden, etc.) of other
controls in the dialog.


|> 
|>  I have tried the following: for a edit control type when the one tries to
|>  change the value (EN_CHANGE message) i set the flag, but apparently this flag 
|>  being set every time i enter the dialog -- why is this happening? 'm i missing
|>  something ? What should i do if user clicks in that region?

You are probably calling SetDlgItemText() for the edit control while
initializing the dialog.  This causes a change to the control text and it
promptly notifies you that this happened.  One common way to work around
this is to have a static flag in your dialog procedure that you set while
processing the WM_INITDIALOG message and then clear when done.  When you
process the EN_CHANGE notification, first examine this static flag.  If it
is set then ignore the notification, otherwise set your other flag to
indicate a change.

This may seem like a hack, but I'll bet it's fairly common -- I use it in
a couple of places (I don't know what exactly that says about it, though :-)


|>  
|>  Hope the problem is clear. If anybody have any ideas/ suggestions for this,
|>  please send me an e-mail

This seemed general enough to follow-up to on the net.



----------------------------------------------------------------------------
Tom Brown               |  "She turned me into a newt...
PE Nelson Systems       |                                  ... I got better"
twbrown@pe-nelson.com   |                    Monty Python and the Holy Grail
----------------------------------------------------------------------------