1

I would like to bind my button to a non static ICommand property. But it would seem all examples I've found are only relevant to static properties.

For example. Here's what I've managed thus far

<Button Grid.Column="1" HorizontalAlignment="Right" Background="{DynamicResource Accent}" Margin="80,0"
        DataContext="{TemplateBinding LogoData}"
        Command="{Binding Source={x:Static materialMenu:SideMenu.OpenSidebar}}">
    <Path Data="{Binding}" Stretch="Fill" Fill="White" Width="24" Height="24" HorizontalAlignment="Center" VerticalAlignment="Center" />
</Button>

The above command binding will only let me bind to a static command property. The same goes for this next one;

<Button Grid.Column="1" HorizontalAlignment="Right" Background="{DynamicResource Accent}" Margin="80,0"
        DataContext="{TemplateBinding LogoData}"
        Command="materialMenu:SideMenu.OpenSidebar"
        CommandParameter="{Binding}">
    <Path Data="{Binding}" Stretch="Fill" Fill="White" Width="24" Height="24" HorizontalAlignment="Center" VerticalAlignment="Center" />
</Button>

So my question is: Since my data-context has already been set to another class, is there any way in wpf to bind a command to a non static property?

Offer
  • 630
  • 2
  • 11
  • 28
  • Where do you declare your `ICommand`? – Hamlet Hakobyan Dec 05 '15 at 15:30
  • @HamletHakobyan It's been declared in another Project within the same solution. – Offer Dec 05 '15 at 15:37
  • Ok, where do you create the command. – Hamlet Hakobyan Dec 05 '15 at 15:41
  • @HamletHakobyan That's in a ResourceDictionary. It's mostly just a template xaml with no .cs file for code behind. – Offer Dec 05 '15 at 15:46
  • Sweet baby Jesus you've created a ViewModel for a UserControl, haven't you? *Haven't you?!?!* –  Dec 07 '15 at 16:01
  • @Will not exactly. Someone else did. I downloaded the source code and now I'm trying to integrate it. Not very easy without documentation so you get questions like this. Call me non the wiser but if the point of MVVM is to have no code behind then why bother with it? – Offer Dec 07 '15 at 22:15
  • MVVM != no codebehind!! MVVM = business logic separated from UI logic, allowing you to easily test both layers. There's also the hypothesis where you can reuse your view models elsewhere, but that's pretty much nonsense, as I've never seen it successfully done. Codebehind is good for UI logic. Also, MVVM makes synchronization of state between the view and view model/business logic ***much simpler***. You don't have to manually configure bindings--you just declare them. It's a ton of code you don't have to write and maintain. –  Dec 08 '15 at 15:12

2 Answers2

0

Reference another Project containing ICommand,

Set DataContext to your ViewModel,

Bind command as <Button Command="{Binding MyCustomCommand}" .../> , as MyCustomCommand is the property name for the command contained in ViewModel.

AnjumSKhan
  • 9,647
  • 1
  • 26
  • 38
0

How did I know? How did I know it? Is it because I'm magic? Well, I am, but that didn't tell me.

It's obvious because this is what happens when one creates a view model to control their user control. It screws up databinding and causes all types of trouble.

Think about this--does the TextBox have a TextBoxViewModel? Is there a TabViewModel? Or a GridViewModel? No. Code your user controls like they are a control.

First thing to do to fix this is to get rid of that view model. Move UI logic into your user control's codebehind. What happens next depends on the goals for the user control.

If the UC is designed to be a generic control, usable against different types of view models, then expose on its surface DependencyProperties for what the control needs to operate. You can then bind these to your view models.

Or, if your UserControl is designed to encapsulate UI for a specific view model (note--the UC is designed around the view model, the view model isn't designed for the UC), then the DataContext should be the view model, and instead of exposing DPs to which the view model is bound against, the controls within the UC are bound directly to the view model.

An example of the first type of control would be a UI item that displays an element in a list, the list containing view models of different types with different properties. The control contains edit/remove buttons and displays the contents of a property defined in a base class, all of which are bound to different elements of different view models. Display info is bound to the view model in the list, and button commands are bound to a common parent view model.

An example of the second type would be an editor for a specific type of view model in your application that is used in different locations.

In summation, the solution is to not do what you're doing. The workarounds for keeping your UC-specific view model are hacky as hell--manually hooking up view models in the codebehind, creating a pseudo-DataContext to hold the second view model... ugh. They are all bad and should be avoided. Ditch your user control's view model.