Hi Andy,

 thank you for your answer. It seems that the value of the CausesValidation property has no effect to the Control. As soon as I enter a number out of the valid range, the control still blocks the cancel button. The only way to close the form is using the close button (X)..

 PS: Wuhuuu, at least my line feeds in my posts seem to work when using the IE7 instead of Google Chrome

oscarmorasu said:

However I think a new property "(bool) ValidateOnLeave" can be added in a future release so that the validation runs inside the OnLeave (when ValidateOnLeave = true) or inside the OnValidating (when ValidateOnLeave = false). By default this property has to be true in order to not break existing applications. In my scenario I would change that property to false and I should get the behavior I expect.

This seems reasonable, and it may be possible. But I can't say for sure why the control is using OnLeave instead of OnValidating right now. There may be some very good reason for this which prevents the control from doing the validation in the OnValidating.

Thanks for looking into this problem Mike.

I'm already working with support on this issue. I agree with you  the validation logic can't be relocated from the OnLeave to the OnValidating method.

However I think a new property "(bool) ValidateOnLeave" can be added in a future release so that the validation runs inside the OnLeave (when ValidateOnLeave = true) or inside the OnValidating (when ValidateOnLeave = false). By default this property has to be true in order to not break existing applications. In my scenario I would change that property to false and I should get the behavior I expect.

I'm not entirely sure, but this doesn't seem right to me.

The Validation of the UltraNumericEditor seems to be based on the OnLeave message, rather than the Validating event. So it will fire any time you try to leave the control, regardless of whether or not the control you are going to causes validation.

This may have been done for a reason, I can't say for sure. And it may not be possible to change this now without breaking existing applications. But I think it needs to be looked into.

I'm going to foward this thread over to Infragistics Developer Support so they can look into it.

Hello,

I'd appreciate the input from Infragistics.

I think validation should be skipped when there's a control with CausesValidation = false. It's hard to believe other developers haven't run into this problem before.

What I describe above is the expected behavior or there's a bug?

Hello,

I'm using version 9.1.20091.2012 and I have this same problem. Changing the RetainFocus property to false inside the ValidationError event handler is not an option because I want the focus to remain on the control if the user clicks Ok.

I'm attaching a test project. Open it and clik the start button. Change the value of the numeric editor to 0 (which is invalid) and try the following tests:

1) If you click Ok the ValidationError raises. That is correct.

2) If you hit Enter the ValidationError raises. That is correct.

3) If you hit ESC the ValidationError raises. That is incorrect. Also the dialog remains open. That is incorrect

4) If  you click the Cancel button  the ValidationError raises. That is incorrect, but anyway the dialog is closed. That is correct. Note: The mouse click has to be really fast or the dialog won't close.

5) Now the odd part. If you hold the mouse on the Cancel button (do not click, just push and hold the left mouse button ) the ValidationError raises and also the dialog remains open. Both behaviors are incorrect.

I think the ValidationError should not be raised if the button closing the form is set to CausesValidation = false. Also the behavior in cases 4) and 5) is very odd. Can someone confirm that I'm not out of my mind?

Thanks.