What’s the right way to get my viewmodel to trigger a custom lookup control to throw up a modal dialog that essentially represents that lookup viewmodel? The custom lookup control’s data context is that of the parent record view model. The lookup control also has another DependencyProperty that has it bound to a lookupviewmodel property on the parent record view model and this represents a sub lookupviewmodel.
METHOD 1) I currrently use an event on the lookupviewmodel that the custom control knows to listen for.
METHOD 2) I tried throwing a validation exception within the setter of the property on the lookupviewmodel that the lookup control’s text propery is bound too. Then I hooked the ErrorEvent in the custom lookup control. But it seems that if the user “corrects” the value from within the dialog while in this event, the original value sticks. And worse, even after I call Validation.ClearInvalid, another ErrorEvent still fires that somehow adds the error back. So everything works here in the sense that all the viewmodels have the correct data, it’s just that it seems like the textbox is ignoring that the bound text property has changed on the underlying data source when inside an ErrorEvent. So it seems like I can’t correct an error while inside the processing of that error?
Another sub issue within method 2 is that Validation.ClearInvalid doesn’t remove the red error border. I had to manually clear the ErrorTemplate too. Is that right?
I’d like to find a way to use natural error handling within the control to get it to throw up the modal dialog.
This isn’t what you use events for. Events exist to facilitate decoupling: the object raising the event shouldn’t know or care what the object(s) listening to it are doing. You’re expecting an event to be able to change the value of a property from inside the property’s setter – or worse, your event handler is calling the very property setter that’s raising the event that it’s handling, which means that you have to do something pretty hackish to avoid a stack overflow.
Your description isn’t very clear (you’re describing both the problem you’re having and the non-working solutions you’re trying at the same time, which is confusing), but it sounds like what you’re trying to do is something more like:
The problem is that you don’t want to have code in your view model that throws up a dialog, since that creates a view model that can’t be tested outside of your WPF application.
The answer in this case is to use dependency injection. Create an interface called
IDialogService:Now add this property to your view model:
The above code becomes:
Create a dialog service for use in your WPF application that actually throws up the dialog and gets the result. When you instantiate your view model in your application, do this:
Thus, in your application, the property setter will put up the dialog and get the result exactly as you expect it to.
For your unit tests, create a mock dialog that looks like this:
You can then write a test like:
The above is really more a sketch of a solution than a solution – depending on how your application uses dialogs, you may need a lot more features than what are sketched out here. If you take a look at MVVM frameworks you’ll find that a lot of them implement dialog services of one kind or another.