WPF Validation not firing initially for new Enitity creation

WPF Validation not firing initially for new Enitity creation

Old forum URL: forums.lhotka.net/forums/t/8573.aspx


Devman posted on Wednesday, February 24, 2010

Hi,

I have been looking a validation in general. I dont really want to add many PropertyStatus controls to my forms as this could take some time redesigning them/moving control around etc to get them to fit.

Instead i have been using the ValidatesOnDataError=True property on the control bindings for a visual queue for invalid properties. These seem to work well hover i have hit a problem.

I have a details form with a populated entity, also a new button.when i click the new button, the a function on the ViewModel is called which resets the Model (ie Model= EntityFactory.Create<T>() ). The new empty object is shown and the red boxes around the invalid textboxes/controls are shown, as I'd expect.

However, When I create a new  instance of the form and call this same function to set the model to a new Entity, the validation is not fired, No red boxes around invalid controls. Has anyone else experienced this?

Iv checked the broken rules collection for the Entity and this has been populated correclty. Its as if the UI needs to be forced to validate its controls initially.

Any help would be greatly appreciated.

Regards

David

 

 

 

Devman replied on Friday, February 26, 2010

Hi,

Just bumping this!!

Does anyone have any thoughts on this, I would have thought this is pretty standard behaviour that I'm trying to achieve.

I have a workaround, which is pretty ugly. On the forms loaded event i call OnPropertyChanged("Model") within the view model.This displays the red validation adorner and doesnt seem to casue any other issues  This seems to work but I would need to write this code for each form.

 

Regards

David

 

 

RockfordLhotka replied on Friday, February 26, 2010

It could be an order-of-events thing.

When are you establishing the DataContext and/or Model property value? In the view's constructor? That'd be too early. It should be done in the Loaded event handler, after the window/usercontrol has been fully initialized.

I don't know if that's the issue, but I know I've encountered similar things when I've accidentally used the ctor to do this sort of work.

Devman replied on Wednesday, March 03, 2010

Sorry about the delayed reply, I didnt get a notification of your post.

Anyway, order of events is certainly the issue here. I moved the setting of the DataContext into the Window/UserControl Loaded and I got the required validation adorners to appear.

However, New Problem!!

Since we populate our model asynchronously for existing entities, the validation adorners appear whilsts the form is populating, flickering on then off. This is not desirable behaviour.

Is there anyway to perform the validation/Set the datacontext when we know the data has returned?

Regards

David

ajj3085 replied on Wednesday, March 03, 2010

Regarding the flickering, could you bind ValidatesOnDataError to NOT IsBusy?

Devman replied on Wednesday, March 03, 2010

Andy,

In theory this approach sounds ideal, but in practice how do you do this? I didnt think you could have a binding nested within a binding.

<TextBox Text="{Binding Model.Name, ValidatesOnDataErrors=True}" />

In this situation I can only hard code ValidatesOnDataErrors=True.

Regards

David

 

 

 

ajj3085 replied on Wednesday, March 03, 2010

You're right, I forgot it was part of the binding, not a seperate element.  I'm not sure what you would do then.

RockfordLhotka replied on Wednesday, March 03, 2010

Devman

Since we populate our model asynchronously for existing entities, the validation adorners appear whilsts the form is populating, flickering on then off. This is not desirable behaviour.

I typically don't set the DataContext to an actual value until I have the value.

In other words, I leave it null until the data portal actually returns the object. The CslaDataProvider and ViewModel components both help you with this by not setting their Data or Model properties to anything but null until the object is actually there.

This typically means the UI renders without any validation or data - just the basic controls. And when the async object arrives it is bound and that's the point at which both data and validation appear.

That said, I don't use the built-in validation stuff, because it can't display multiple errors, or warning/information status messages, so I find it too limiting - all a matter of personal preference I guess Smile

Devman replied on Thursday, March 04, 2010

RockfordLhotka
This typically means the UI renders without any validation or data - just the basic controls. And when the async object arrives it is bound and that's the point at which both data and validation appear.
 

Ooops! There was a bug on my part which was creating a new entity in the VM constructor Doh!!  This was firing the validation, then the entity was replaced after the data portal fetch.Sorry about that.

Thanks for your time and efforts.

Cheers

David

 

RockfordLhotka replied on Thursday, March 04, 2010

Again, I don't generally use the validate on errors behavior. My guess is that it is validating on null ref errors in that first instance.

If your Model property is null, the binding would run against nothing right? So all the binding attempts would generate null ref exceptions - a type of error that might be displayed by the validate on errors?

Then when the Model is set to a real value, binding refreshes, and how has actual data, and an IDataErrorInfo interface, against which it can work, so no more null ref exceptions.

But that's just a guess.

Copyright (c) Marimer LLC