I want to have a command from my view model associated with F8, and don't know a great deal about input gestures. Must I wrap it in a routed command or is there another recommended way to do this?
Cheers,
Berryl
UPDATE
My original posting really had two pain points in them. The first was that prior to WPF 4 you couldn't bind a command directly to an input gesture or count on visual inheritance for the command's DataContext, and had to go through a CommandManager layer. That seems like the reason the MVVM Toolkit's CommandReference that NVM pointed out was useful, but now with WPF 4 this is fixed as the Command is an attached DP on the InputBinding, so all you need to do is something like:
<DataGrid.InputBindings>
<KeyBinding Command="{Binding MyViewModel.MyCommand}" Key="F8" />
</DataGrid.InputBindings>
The second pain point to realize is that binding an input gesture to a command is not the same as associating the textual representation of that gesture to a menu item. So I need to do something like:
<MenuItem Header="{x:Static s:Strings.MyHeaderString}" Command="{Binding MyViewModel.MyCommand}"
InputGestureText="F8"/>
I spelled this out in the hopes that someone will either tell me I've got something wrong (or right). Assuming this is the best you can do then it's down to how much DRYness you can get and how to do that while keeping strictly visual elements out of your ViewModels. You could do this either by having some properties on your Command (ie, KeyGesture, KeyModifier) or having the "F8" in a resource file I suppose, depending on how much you need to reuse something and your point of view. Also on how many input gestures you have for the command!
How do I associate a keypress with a DelegateCommand in Composite WPF?
This is your answer. Instead of Key="X" you should use Gesture="F8"
Related
I have a MenuItem Checkbox in my main window as well as in another two windows:
<MenuItem x:Name = 'FileMenu' Header = '_File'>
<MenuItem x:Name = 'EnableAutostart' Header = '_Enable Autostart' IsChecked="{Binding AutoStart, Mode= TwoWay}" IsCheckable="true" ToolTip = 'Enables the autostart.' InputGestureText ='Ctrl+S'></MenuItem>
I use it to define whether or not the script automatically starts on user logon (a function checks for the scheduled activity and sets the checkbox accordingly) and when clicked it enables or disables it.
Now what if I want to keep all the 3 different windows checkboxes synced?
I read a lot about binding but can't really get it working, I tried to set the binding on a bool "Autostart" and to set it true before showing the window but it does nothing at all.
How can I define a bool in my code and make it so that, whenever I change that bool, it reflects on all the menuitems checkboxes bound to it? (even if the other windows are yet to be created/shown)
I read about needing to make it a property... can I just make a class, set a property to it called something like "AutoStart" and it would work?
Thank you #bluuf, you kind of gave me a hint.
Anyway comes out i actually achieved to do a databind previously in my many tests but as you said, the INotifyPropertyChanged is not so easy to handle in powershell, or maybe it is?
Good guy Trevor Jones (link at bottom) explained an easy way and i did the last steps to understand it and apply it to my code. Thank you Trevor.
He basically explains that this one collection:
System.Collections.ObjectModel.ObservableCollection[Object]
Has an already implemented iNotifyPropertyChanged that works well in powershell, without adding c# classes.
You just create that collection, add your bool to it, and point the binding.source to it.
Trevor's article, actually read it, worth your time:
https://smsagent.blog/2017/02/03/powershell-deepdive-wpf-data-binding-and-inotifypropertychanged/
P.S. Trevor also points to this article which explains how to implement the c# class (and more), if anyone is interested:
https://www.ephingadmin.com/better-know-a-powershell-ui-50-shades-of-bindings-part-1/
I'm learning the MVVM pattern with a new(small) project, and I've one question about the way to invoke actions on our controller:
I saw many tutorial where they were telling us to use Command, implying to declare a RelayCommand, initialize it and create the action called by the RelayCommand.
In the other side, I've a colleague which said me that I can use the CallMethodAction with a trigger:
<i:Interaction.Triggers>
<i:EventTrigger>
<ei:CallMethodAction MethodName="Init" TargetObject="{Binding}" />
</i:EventTrigger>
</i:Interaction.Triggers>
For me, his approach has the advantage that I don't have to make some inits methods for commands(which may be never used).
So what am I missing? Why everybody use commands?
Commands are out-of-the-box solution and can be attached only to elements which implement the ICommand interface. On the other hand, event triggers can be attached to any event, what makes them more flexible. I follow the general strategy to use Commands where user interactions are involved (buttons, menus) and CanExecute pattern is needed. My commands are strictly connected to visual interface (provide caption, image source, etc.). I use CallMethodAction in any other situation when I want to get rid of code-behind.
Commands provide functionality for disabling in ViewModel code. That can be used to automatically disable e.g buttons bound to command. That's what makes Commands better. Besides, based on your logic you could just dynamically pluck another Command in the same slot and it will reroute the traffic from View, whereas in CallMethodAction you would have to write the rerouting logic in the called method, which would be ugly.
As you can see, it depends on what you try to accomplish and how complicated is your logic :)
I have these ViewModels: RecordViewModel, ComponentViewModel where RecordViewModel essentially is a container for several ComponentViewModels.
The display of these ViewModels is currently handled by DataTemplates that look something like this:
<DataTemplate DataType="{x:Type vm:RecordViewModel}" >
<ItemsControl ItemsSource={Binding Components} />
</DataTemplate>
<DataTemplate DataType="{x:Type vm:ComponentViewModel}" >
<TextBox Text={Binding Name} />
</DataTemplate>
What I wanted to provide now is a way to change the order the ComponentViewModels are displayed and to remove a certain ComponentViewModel from the list. I started out doing that by manipulating the DataTemplate of the ComponentViewModel and adding buttons that provided these functions (the click would then trigger a method on the ComponentViewModel that would (through a reference "Parent" to the RecordViewModel) call a method on the RecordViewModel to perform the operation (like component.Parent.DeleteComponent(this)).
The problem with this in my oppinion is that it is really the Record that should manipulate the Components position/remove a Component and not the Component itself.
So I thought about using an adorner that attaches to the RecordViewModel and renders the buttons to provide the functionality (remove, move up, move down) for each of the ComponentViewModels.
The problem however is that these adorners need to take a reference to a Control-derivate which they adorn (which was ok I would just bind to the ItemsControl in the Record-DataTemplate) however the problem appears when I want to show the buttons in the right position for each ComponentViewModel. I only have a reference to the given ComponentViewModels and not to their visual representation (the thing defined in the DataTemplate) so I have no way of knowing where to place the 3 buttons.
Is there a way to work around this? Or is it possible that for these requirements using ViewModels/DataTemplates is just not a good idea and should I therefore use Control-derivates/ControlTemplates?
Thanks in advance!
Coming up with wacky architectural hacks that you can employ to keep your view model elegant and simple is missing the point. The view model is the wacky architectural hack.
The only reason - seriously, the only reason - that the view model exists is to model the view. Does the view have buttons that trigger commands? The commands belong in the view model.
Thinking, "it's really the Record's responsibility to move Components" seems sensible on its face, but it's actually an indication that you're losing track of why you even created a view model in the first place. Does the Component view have a "Move Up" button? Then the Component view model needs a "Move Up" command that you can bind the button to. Because that's what the Component view model is for.
I'm being emphatic about this because this is the third or fourth question I've seen this week from WPF developers who seem to have gone down so deeply down the rabbit hole of the MVVM pattern that they've forgotten why it exists.
If your goal is to have a Command on the parent ViewModel that acts on an element of the child ViewModel, you can do this by using a RelativeSource binding on Command and passing the item as Command Parameter:
<DataTemplate DataType="{x:Type vm:ComponentViewModel}" >
<Button
Command="{Binding DataContext.RemoveCommand,
RelativeSource={RelativeSource AncestorType=ItemsControl}}"
CommandParameter="{Binding}"
Content="{Binding Name}"/>
</DataTemplate>
The RelativeSource binding will find the ItemsControl, so the DataContext property will be your RecordViewModel. The CommandParameter will be the individual ComponentViewModel, so your ICommand implementation would be:
DeleteComponent((ComponentViewModel)parameter);
it is really the Record that should manipulate the Components position/remove a Component and not the Component itself
As far as your model objects go, that's probably true. However, the ViewModels are all about presentation, and the buttons are kind of part of a Component's presentation. So I think it could be acceptable for the ComponentViewModel to have a reference to its parent RecordViewModel, to enable this scenario, even if it wouldn't be appropriate for the Component to have a reference to its parent Record.
But consider that, in your scenario, maybe the ComponentViewModel has too many responsibilities. It belongs to the collection (because it's mutating the collection), and it belongs to the element in the collection (because it's showing the Component's name in a TextBox). It sounds like it's this dual responsibility that's bothering you. So break it up. Make RecordViewModel contain RecordElementViewModels, each of which knows how to remove itself from the Record; and each RecordElementViewModel contains a ComponentViewModel. On the view side, it sounds like your UI would be composed the same way: an outer panel with a Delete button, and then another control or panel inside that, presenting the Component's properties.
Now, for the example you posted, where Component's view is just a TextBox, I wouldn't bother splitting the ViewModel into two parts. But for a more complex example, it might make a lot of sense.
To specifically answer your question about adorning:
You're getting into changing the way a DataTemplate-d element is laid out, which means you're not just layering an adorner on top of the element, you're actually wanting to insert a panel into the visual tree that imposes its own layout onto the DataTemplate (which becomes a child of the new panel). I'll admit that I haven't used adorners, but that doesn't seem to be what they're for.
The best way to do this, IMO, is to have your DataTemplate generate the parent panel, buttons and all -- which leads back to wanting the functionality on the ComponentViewModel, or perhaps splitting ComponentViewModel's responsibilities (see my other answer).
I am new to WPF and MVVM, and I am working on an application utilizing both. The application is similar to windows explorer, so consider an app with a main window with menu (ShellViewModel), a tree control (TreeViewModel), and a list control (ListViewModel). I want to implement menu items such as Edit -> Delete, which deletes the currently selected item (which may be in the tree or in the list).
I am using Josh Smith's RelayCommand, and binding the menuitem to a DeleteItemCommand in the ShellViewModel is easy. It seems like implementing the DeleteItemCommand, however, requires some fairly tight coupling between the ShellViewModel and the two child view models (TreeViewModel and ListViewModel) to keep track of the focus/selection and direct the action to the proper child for implementation. That seems wrong to me, and makes me think I'm missing something.
Writing a focus manager and/or selection manager to do the bookkeeping does not seem too hard, and could be done without coupling the classes together. The windowing system is already keeping track of which view has the focus, and it seems like I'd be duplicating code.
What I'm not sure about is how I would route the command from the ShellViewModel down to either the ListViewModel or the TreeViewModel to do the actual work without making a mess of the code. Some day, the application will be extended to include more than two children, and I want the shell to be as ignorant of the children as possible to make that extension as painless as possible.
Looking at some sample WPF/MVVM applications (Karl Shifflett's CipherText, Josh Smith's MVVM Demo, etc.), I haven't seen any code that does this (or I didn't understand it).
Regardless of whether you think my approach is way off base or I'm just missing a small nuance, please share your thoughts and help me get back on track. Thanks!
There are some inherent issues with Josh Smith's implementation of MVVM. Take a look at Ward Bell's post on the subject: http://neverindoubtnet.blogspot.com/2010/03/mvvm-josh-smiths-way.html. You may want to take a look at some alternative MVVM frameworks such as Caliburn that take a ViewModel first approach and break this coupling.
The RelayCommand is just a way to get a command in your ViewModel that can be bound to your View.
I think I would be inclined to step back from all of the different MVVM architectural variations and sample apps, and just use good old OOD. Why not have a ViewModel base class of some sort (ie, DetailsViewModelBase) for TreeViewVm and ListViewVm. Put a DeleteCommand in there with CanDelete and Delete methods that have as much implementation as the subclasses share (or abstract if none), and a SelectedItem as well. Then bind the SelectedItem to the controls similar to the xaml below:
<ListView AlternationCount="2" MinHeight="250" MaxHeight="400"
ItemsSource="{Binding Projects.View}"
IsSynchronizedWithCurrentItem="True"
SelectedItem="{Binding SelectedProject, Mode=TwoWay}"
behaviors:SelectionBehavior.DoubleClickCommand="{Binding PickCommand}"
ItemContainerStyle="{StaticResource listingRowStyle}"
>
The key bindings being SelectedItem and IsSynchronizedWithCurrentItem.
HTH,
Berryl
I found a blog post by Kent Boogaart that describes what he calls an ActiveAwareCommand. This seems to do what I was looking for, although I haven't yet tried it. A comment on the post mentions Prism's IActiveAware as having similar behavior.
I am trying to come to a working understanding of how databinding works, but even after several tutorials I only have a basic understanding of how databinding works. Thus this question might seem fundamental to those more familiar with silverlight. Even if it is trivial, please point me to some tutorial that deals with this problem. All that I could find simply solved this via adding the data binding on a parent page.xaml (that i must not use in my case).
For the sake of this example let us assume, that we have 5 files:
starter.cs
button1.xaml + codeBehind
button2.xaml + codeBehind
The two buttons are generated in code in the starter(.cs) file, and then added to some MapLayer
button1 my_button1 = new button1();
button2 my_button1 = new button2();
someLayer.Children.Add(my_button1);
someLayer.Children.Add(my_button2);
My aim is to connect the two buttons, so that they always display the same "text" (i.e. my_button1.content==my_button2.content = true;). Thus when something changes my_button1.content this change should be propagated to the other button (two way binding).
At the moment my button1.xaml looks like this:
<Grid x:Name="LayoutRoot">
<Button x:Name="x_button1" Margin="0,0,0,0" Content="{Binding ElementName=x_button2, Path=Content}" ClickMode="Press" Click="button1_Click"/>
</Grid>
But everthing that i get out of that is a button with no content at all, it is just blank as the binding silently fails.
How could I create the databinding in the context I described? Preferably in code and not XAML ;)
Thanks in advance
The chunk of documentation you need to read is this: XAML Namescopes
Your button1 xaml has a binding looking for an element with the name "x_button2". However in a real application there can be many controls which in turn have nested controls. All of these controls have all manner of UI elements some of which may have names.
It would be impossible to get anything done if all names throughout the entire application had be unique. Yet that would need to be true if it were for your button1 to be able to hunt down the existence of another control somewhere in the visual tree outside of that which it actually knows (its own xaml).
Hence each loaded Xaml document exists in its own "namescope" and the search for other elements with other names is limited to that "namescope".
The are various solutions to this problem depending on what you real requirements are as opposed to the simplified problem in your question.
Typically you give each of your controls a DependencyProperty to which the inner button Content property binds. In "MapLayer" as call it, could then bind the propert on one of your button controls to the other.