DependencyProperties in ViewModels

Aug 5, 2010 at 4:41 PM
Edited Aug 5, 2010 at 6:57 PM


Sorry, I think I must be missing something obvious - so pls excuse me. I have a view model inheriting from PropertyChangedBase to access the NotifyOfPropertyChanged call. But I also need to add some DependencyProperties (and inherit from DependencyObject or something) to gain access to the GetSetValue calls since the underlying control  in the view (a richtextbox) doesn't support binding.

AFAICS I could

  1. inherit from DependencyObject and implement INotifyPropertyChanged manually
  2. somehow set/get the dependency property value manually
  3. put the dependencyproperty in the code behind - i was hoping to avoid this since I wanted access to some of the properties via the viewmodel

What is the best way to do this?




Aug 5, 2010 at 10:13 PM

I'm not sure I understand what you  are trying to do. I don't recommend using DependencyObjects for ViewModels. Can you clarify a bit?

Aug 6, 2010 at 7:09 AM


I think I need to get a better grasp of dependency properties.

Basically, in the view, the underlying control is a rich text box which has non-dependency properties which I want to wire up into the view model. Basically I was wondering what the methodology should be for wiring up caliburn.micro to these non-dependency properties. 



Aug 6, 2010 at 9:51 AM

When I happen to interact with "simple" properties in the view or with strange controls not supporting binding, I usually choose one of these approach (in order of personal preference, but context is also very important):

1) "Poor-man binding": from the view code-behind, subscribe to VM PropertyChanged event and react to the change of an opportune property (VM is tipically accessible from view through DataContext property, which also raises events when it is changed, so you can easily subscribe and unsubscribe)

2) "Custom IResult": write a custom IResult and call it using coroutine tecnique in VM; the IResult.Execute method (called by infrastructure) has access to the view, so you can find your control by name and do whatever you need.

3) "MVP approach": define an interface to be implemented by the view (in code behind), then use it from VM leveraging IViewAware interface to access the view



Aug 6, 2010 at 10:11 AM
Edited Aug 6, 2010 at 10:17 AM

Marco, very helpful - thx.

Is there any reason why you shouldn't use a proxy-type approach? For example, since the RichTextBox CaretPosition is a simple property, I could create a dependency property in the code behind which itself gets updated on the TextChanged event and then bind to that that property from the VM.  Given the options you've mentioned above, I'm wondering if this approach isn't quite right.

Many thx again.



Aug 6, 2010 at 1:26 PM

It's a very good solution as well. 

You could also take a step further and create an attached property or a Interactivity behavior to reuse it in multiple views without adding a dependency property in every view.

Aug 6, 2010 at 1:50 PM

ooo ... that sounds good! I'll have to think about that one!

Thx again