Привязка кнопки к не статическому свойству

Question

Я хотел бы привязать свою кнопку к нестационарному свойству ICommand. Но, казалось бы, все примеры, которые я нашел, относятся только к статическим свойствам.

Например. Вот что я до сих пор знаю

<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> 

Вышеупомянутое связывание команд позволит мне привязать свойство статической команды. То же самое касается следующего;

<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> 

Так что мой вопрос: Так как мой данные-контекст уже установлен в другой класс, есть ли способ в WPF, чтобы связать команду с не статическим свойством?

Answer 1

Ссылка другой проект, содержащий ICommand,

Набор DataContext к вашему ViewModel,

Bind команды, как <Button Command="{Binding MyCustomCommand}" .../>, так как MyCustomCommand это имя свойства для команды, содержащейся в ViewModel.

Answer 2

Как я узнал? Откуда я это знаю? Это потому, что я волшебный? Ну, я, но это не говорило мне.

Это очевидно, потому что это то, что происходит, когда создается модель представления для управления их пользовательским управлением. Он закручивает привязку данных и вызывает все проблемы.

Подумайте об этом - есть ли в TextBox TextBoxViewModel? Есть ли TabViewModel? Или GridViewModel? Нет. Код, которым управляют ваши пользователи , как будто они являются управляющим.

Первое, что нужно сделать, чтобы исправить это, чтобы избавиться от этой модели просмотра. Переместите логику пользовательского интерфейса в кодовое имя пользователя. То, что происходит дальше, зависит от целей пользовательского контроля.

Если UC спроектирован как общий элемент управления, применимый к различным типам моделей просмотра, а затем выставляет на его поверхность DependencyProperties, для чего необходимо управление. Затем вы можете привязать их к вашим моделям просмотров.

Или, если ваш UserControl предназначен для инкапсуляции пользовательского интерфейса для конкретной модели представления (примечание - UC спроектирован вокруг модели представления, модель представления не предназначена для UC), то DataContext должен быть и вместо того, чтобы подвергать DP, с которыми связана модель представления, элементы управления в UC привязаны непосредственно к модели представления.

Примером первого типа элемента управления будет элемент пользовательского интерфейса, который отображает элемент в списке, список, содержащий модели просмотра разных типов с различными свойствами. Элемент управления содержит кнопки редактирования/удаления и отображает содержимое свойства, определенного в базовом классе, все из которых связаны с разными элементами разных моделей представлений. Информация отображения привязана к модели представления в списке, а команды кнопок привязаны к общей модели родительского представления.

Примером второго типа может быть редактор для определенного типа модели представления в приложении, который используется в разных местах.

Подводя итог, решение состоит в том, чтобы не делать то, что вы делаете. Обходные пути для сохранения вашей модели UC-специфики выглядят взломанными, как черт, - вручную подключая модели просмотра в коде, создавая псевдо-DataContext для хранения второй модели представления ... тьфу. Они все плохие, их следует избегать. Снимите модель просмотра вашего пользовательского элемента управления.