4

I have a user control written in C# & WPF using the MVVM pattern.

All I want to do is have a property in the bound ViewModel exposed to outside of the control. I want to be able to bind to it and I want any changes to the property to be picked up by anything outside the control that is bound to the exposed value.

This sounds simple, but its making me pull out my hair (and there is not much of that left).

I have a dependency property in the user control. The ViewModel has the property implementing the INotifyPropertyChanged interface and is calling the PropertyChanged event correctly.

Some questions: 1) How do I pick up the changes to the ViewModel Property and tie it to the Dependency Property without breaking the MVVM separation? So far the only way I've managed to do this is to assign the ViewModels PropertyChanged Event in the Controls code behind, which is definitely not MVVM.

2) Using the above fudge, I can get the Dependency property to kick off its PropertyChangedCallback, but anything bound to it outside the control does not pick up the change.

There has to be a simple way to do all of this. Note that I've not posted any code here - I'm hoping not to influence the answers with my existing code. Also, you'd probably all laugh at it anyway...

Rob

OK, to clarify - code examples:

usercontrol code behind:

   public static DependencyProperty NewRepositoryRunProperty = DependencyProperty.Register("NewRepositoryRun", typeof(int?), typeof(GroupTree),
                                                                new FrameworkPropertyMetadata( null, new PropertyChangedCallback(OnNewRepositoryRunChanged)));
    public int? NewRepositoryRun
    {
        get { return (int?)GetValue(NewRepositoryRunProperty); }
        set
        {
            SetValue(NewRepositoryRunProperty, value);
        }
    }

    private static void OnNewRepositoryRunChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        if (e.OldValue != e.NewValue)
        {

        }
    }

    public GroupTree()
    {
        InitializeComponent();

        GroupTreeVM vm = new GroupTreeVM();

        this.DataContext = vm;

    }

Viewmodel (GroupTreeVM.cs)

   private int? _NewRepositoryRun;
    public int? NewRepositoryRun
    {
        get
        {
            return _NewRepositoryRun;
        }
        set
        {
            _NewRepositoryRun = value; 
            NotifyPropertyChanged();
        }
    }
Rob Marsh
  • 549
  • 5
  • 22
  • Please post your (relevant) code. – dymanoid Jan 27 '15 at 16:37
  • 6
    Hair loss question probably belong to some other site - do we have Beauty.SE? Maybe your CRT monitor is killing you. Please switch to paper. Alternatively edit out non-programming related text from your post ... – Alexei Levenkov Jan 27 '15 at 16:38
  • Oh lawd, you've gone and created a ViewModel for your UserControl, haven't you? –  Jan 27 '15 at 16:48
  • [This post by jerry nixon](http://blog.jerrynixon.com/2013/07/solved-two-way-binding-inside-user.html) sheds a lot of light about two way binding inside and outside of user controls. – Corcus Jan 27 '15 at 16:50
  • @Will Yes, and I can't see a way around it if I want to break all the contents of my mainwindows tabs into more manageable chunks of code. I've just been following what has ben recommended by MVVM advocates on other sites... – Rob Marsh Jan 27 '15 at 16:52
  • 1
    I have no idea what you're talking about. WPF does not support hair, or lack of it, and I don't see any XAML or C# code in your post. Close-voting. -1 – Federico Berasategui Jan 27 '15 at 16:52
  • 1
    @Corcus oh, ffs, that one. Here's a hint: `(this.Content as FrameworkElement).DataContext = this` is about the dumbest thing you can do. Simply use `Binding.ElementName` to reference properties defined on the root. –  Jan 27 '15 at 16:52
  • @HighCore It's pretty clear he created a VM to use within his UserControl. Easy to fix that by not doing it. –  Jan 27 '15 at 16:55
  • @RobMarsh You can and you will get around it. Easily. And nobody who uses WPF professionally would ever tell you to create a ViewModel for your UserControl. It prevents you from using them as intended. They shouldn't have any logic, they should only be displaying information. –  Jan 27 '15 at 17:02
  • (notice how you didn't explicitly state you had gone and done it, yet I instantly knew what was going on, because you are having exactly the issues everybody has when they try to create view models for their user controls. I'm not magic, I've just been there before. No, strike that, I'm magic. Do what I say. Or I'll magic your peen off.) –  Jan 27 '15 at 17:04
  • @Will I'm not denying I have done it - and as someone who is trying to pick up WPF and MVVM after years in Winforms I'm certainly not going to say sorry for doing something that looked logical at the time...! Given that you are the first person I've come across who has said don't do it like that and the control is already there in that state, splitting out the ViewModel from the usercontrol isn't a possibility. This may make your eyes bleed, but I need a way to get it working in its current structure.. I'll certainly try your method in a future project to see if its less painful. – Rob Marsh Jan 27 '15 at 17:25
  • 1
    Okay, keep hitting yourself in the head with a hammer. It's your head, after all. Also, POOF, no more peen. Enjoy sitting down to pee. –  Jan 27 '15 at 17:28

2 Answers2

12

And now for my weekly "don't do that" answer...

Creating a ViewModel for your UserControl is a code smell.

You're experiencing this issue because of that smell, and it should be an indication that you're doing something wrong.

The solution is to ditch the VM built for the UserControl. If it contains business logic, it should be moved to an appropriate location in another ViewModel.

You should think of a UserControl as nothing more than a more complex control. Does the TextBox have its own ViewModel? No. You bind your VM's property to the Text property of the control, and the control shows your text in its UI.

Think of UserControls in MVVM like this--For each model, you have a UserControl, and it is designed to present the data in that model to the user. You can use it anywhere you want to show the user that model. Does it need a button? Expose an ICommand property on your UserControl and let your business logic bind to it. Does your business logic need to know something going on inside? Add a routed event.

Normally, in WPF, if you find yourself asking why it hurts to do something, it's because you shouldn't do it.

Community
  • 1
  • 1
  • 1
    Great answer. It took me a while to realize this myself. One caveat: When using a UserControl as a "sub-view" (or even its own view), its own VM can make sense. – BradleyDotNET Jan 27 '15 at 17:43
  • I agree with you completly. If you mess with UI in code behind, .... you are doing it wrong. – user853710 Jan 27 '15 at 20:56
  • 1
    some more rules for usercontrols: if you have dependency properties in it, you should never set the DataContext to self and you should not have a "own" Viewmodel for the Usercontrol. then Binding within your usercontrol to the DP should always be with Elementname or relativeSource. – blindmeis Jan 28 '15 at 08:01
  • @Will - What if every View in the application needs to display the logged in user, does that mean every View Model in the application needs a Username property so that this UserControl can bind to it? – O.O Oct 21 '15 at 22:45
  • @O.O nah. Every view should extend a base view class with the appropriate properties. If a view model requires that a user be logged in, it would be helpful if the code that logs the user in (and records such) is available to all VMs. Why would you put that in a control? That's goofy. Don't be goofy. –  Oct 22 '15 at 00:21
  • @Will I wouldn't put that logic in a user control, I would put it in the usercontrol's view model as it's a view model's job to hold state for the view. Aren't you essentially just talking about a global vm or something? – O.O Oct 22 '15 at 15:24
  • @O.O The VM's job is to interpret user input and change the state of the application. The view is responsible for its own state. There's plenty of different, correct, ways to do this. If you still have a question about it, it might be worth an actual question. –  Oct 22 '15 at 15:29
0

Perhaps I've misunderstood, but it seems like you're trying to use binding in the code behind?

public MyUserControl()
{
    InitializeComponent();

    // Set your datacontext.

    var binding = new Binding("SomeVMProperty");
    binding.Source = this.DataContext;

    SetBinding(MyDependencyProperty, binding);
}
Derrick Moeller
  • 4,808
  • 2
  • 22
  • 48