tags:

views:

44

answers:

2

Since this is so long and prolapsed and really doesnt ask a coherent question:

1: what is the proper way to implement subproperties of a primary object in a viewmodel?

2: Has anyone found a way to fix the delegatecommand.RaiseCanExecuteChanged issue? or do I need to fix it myself until MS does?

For the rest of the story...continue on.

In my viewmodel i have a doctor object property that is tied to my Model.Doctor, which is an EF POCO object. I have onPropertyChanged("Doctor") in the setter as such:

       Private Property Doctor() As Model.Doctor
            Get
                Return _objDoctor
            End Get
            Set(ByVal Value As Model.Doctor)
                _objDoctor = Value
                OnPropertyChanged("Doctor")
            End Set
        End Property

The only time OnPropertyChanged fires if the WHOLE object changes. This wouldnt be a problem except that I need to know when the properties of doctor changes, so that I can enable other controls on my form(save button for example). I have tried to implement it in this way:

Public Property FirstName() As String
        Get
            Return _objDoctor.FirstName
        End Get
        Set(ByVal Value As String)
            _objDoctor.FirstName = Value
            OnPropertyChanged("Doctor")
        End Set
    End Property

this is taken from the XAMLPowerToys controls from Karl Shifflet, so i have to assume that its correct. But for the life of me I cant get it to work.

I have included PRISM in here because I am using a unity container to instantiate my view and it IS a singleton. I am getting change notification to the viewmodel via eventaggregator that then populates Doctor with the new value. The reason I am doing all this is because of PRISM's DelegateCommand. So maybe that is my real issue.

It appears that there is a bug in DelegateCommand that does not fire the RaiseCanExecuteChanged method on the commands that implement it and therefore needs to be fired manually. I have the code for that in my onPropertyChangedEventHandler. Of course this isnt implemented through the ICommand interface either so I have to break and make my properties DelegateCommand(of X) so that I have access to RaiseCanExecuteChanged of each command.

+1  A: 

2: Has anyone found a way to fix the delegatecommand.RaiseCanExecuteChanged issue? or do I need to fix it myself until MS does?

Use Josh Smith's RelayCommand instead of the DelegateCommand. It fixes the issue with CanExecute commands not being raised, and doesn't leak memory like the DelegateCommand:

"It delegates the event subscription to the CommandManager.RequerySuggested event. This ensures that the WPF commanding infrastructure asks all RelayCommand objects if they can execute whenever it asks the built-in commands."

Bermo
yep, I decided to go that route. Heck I may even dump prism altogether for MEF...hehe thanks
ecathell
A: 

About 2: There is no bug to fix by Microsoft, since it is by design that you have to explicitely tell the command to re-evaluate itself. Of course you may disagree with their decision.

If you want to have the DelegateCommands re-evaluate whenever RaiseCanExecuteChanged is fired, see http://compositewpf.codeplex.com/Thread/View.aspx?ThreadId=47338

Daniel Rose