WPF PropertyStatus Request

Wokket posted on Wednesday, November 11, 2009

G'day guys,

I'm playing with WPF in an attempt to get over the huge learning curve, and getting back into the CSLA space at the same time.

I've rigged up a demo BB customer object, with a cross property validation rule, via the AddDependantProperty mechanism.

This rule fires beautifully, however the PropertyStatus control does not update when the dependant control is altered, as it listens for PropertyChanged only on the property it's attached to:

private void source_PropertyChanged(object sender, PropertyChangedEventArgs e)
{
if (e.PropertyName == _bindingPath || string.IsNullOrEmpty(e.PropertyName))
UpdateState();
}


This is entirely reasonable from a performance point of view, but does cause hassles with the cross-property rules.

To my mind, the PropertyStatus control (or at least the validation rules part of it, I haven't played with the Auth/Busy stuff) really needs to be listening to an event off the Broken Rules collection, rather than property changed... as it's really the Broken Rules state it's reflecting.

I had a quick play with various combinations of:

ChildChanged
ListChanged (too hard to quickly get access to the required info, may be a chance though)
AddingNew (never seemed to fire)
RemovingItem (fired prior to the item actually being removed, and so state was left unchanged)

While ListChanged was a pretty average event to handle (with just the old/new list indexes to play with), it may be sufficient for our needs. If we update the BrokenRule state on every Rule collection change we will definately stay in synch, but at the extra cost off all the controls keeping in synch, rather than just the one.

Removing the BrokenRule state update from PropertyChanged should offset the extra cost of updating all the PropertyStatus controls at once though, as it saves each control potentially updating itself per-keystroke, even though there's no change in rule.

I'd imagine rule changes on average occur far less frequently than property changes... the question is whether the number of PropertyStatus controls * number of rule changes
Food for thought, I'll keep playing.

Cheers,
Tim

RockfordLhotka replied on Wednesday, November 11, 2009

WPF handles PropertyChanged events differently from Windows Forms. As you can imagine from history, CSLA follows the Windows Forms model by default today.

You need to set a config switch to tell CSLA to use the Xaml model for PropertyChanged. This is ApplicationContext.PropertyChangedMode - set it once as your app starts up (like in App.xaml) and you should be set. Or you can set it in your config file with the CslaPropertyChangedMode key.

RockfordLhotka replied on Wednesday, November 11, 2009

I should also point out that the default for PropertyChangedMode will switch to Xaml in CSLA .NET 4.0. I'm sure that'll cause a few bouts of forum threads as Windows Forms performance tanks when people forget to set the value, but such is life.

(that's the thing - Windows Forms works either way, it is just less efficient with the Xaml option; while WPF only works with the Xaml setting)

Wokket replied on Wednesday, November 11, 2009

Thanks for that Rocky.  I obviously missed that setting in the demo code I was copyin^H^H^H^H^H learning from.

Tim

RockfordLhotka replied on Wednesday, November 11, 2009