Okay, Chris you're absolutely right.
I tried Chris' code and indeed it works without doing a POST for the Messagebox. This left me a bit off my feet, I've been coding the itemchanged since 1992 ... :s
So then I tried with numeric fields with format thinking that maybe a format or editmask might make a difference.
No luck, it still works perfectly.
Then I wondered why during all the years I've been seeing similar problems and I think I know what's going on here:
A lot of people (including companies I worked for), use some kind of an ancestor for the dw control and lots of times they / we code an "AcceptText()" command in the losefocus event of the datawindow to make sure all values are being validated, etc.
So I've added that (an AcceptText() ) to the losefocus event and now I can reproduce the problem that Ashutosh is experiencing:
The Messagebox makes the losefocus do an AccepText() and that's makes the "return 2" lose track of it's buffer values.
So if there's an AccepText() anywhere in the itemchanged itself or most probably in the losefocus event ....
take that out and it will work the way Chris describes.
I you cannot or don't want to take out the AcceptText, then choose my workaround of doing an Post of the Messagebox or the other described method of first saving the original value.
I've added a very small app that reproduces the problem with the AcceptText() in the losefocus()
HIH.
The Messagebox makes the losefocus do an AccepText() and that's makes the "return 2" lose track of it's buffer values.
So if there's an AccepText() anywhere in the itemchanged itself or most probably in the losefocus event ....
take that out and it will work the way Chris describes.
I you cannot or don't want to take out the AcceptText, then choose my workaround of doing an Post of the Messagebox or the other described method of first saving the original value.
I've added a very small app that reproduces the problem with the AcceptText() in the