- Rocko Bonaparte
- Posts: 39
- Joined:
Your preferred RelayCommand implementation
I'm still new to WPF and have been surprised to hear about the peculiar culture of it. In this case, I'm talking about the various ways people implement some things for it that are surprisingly not included in a default way like RelayCommand.
I was dabbling in Visual Studio with a project first, and I started using this RelayCommand:
https://www.c-sharpcorner.com/UploadFil ... nd-in-wpf/
I have a lot of buttons and use that RelayCommand to bind commands to run when the buttons are pressed.
The problem with integrating with NoesisGUI comes down to CommandManager in the CanExecuteChanged handler:
This isn't found when building in Unity. What I gathered from other posts on here is that Noesis has something like CommandManager but doesn't expose it. For what it's worth, I can stub out the handlers and just have them do nothing. It seems to not harm my project, but I suspect it harms some optimizations. Other people have their own RelayCommands they rely on so I just figured I'd ask what you are using instead.
I was dabbling in Visual Studio with a project first, and I started using this RelayCommand:
https://www.c-sharpcorner.com/UploadFil ... nd-in-wpf/
I have a lot of buttons and use that RelayCommand to bind commands to run when the buttons are pressed.
The problem with integrating with NoesisGUI comes down to CommandManager in the CanExecuteChanged handler:
Code: Select all
public event System.EventHandler CanExecuteChanged
{
add { CommandManager.RequerySuggested += value; }
remove { CommandManager.RequerySuggested -= value; }
}
-
sfernandez
Site Admin
- Posts: 2983
- Joined:
Re: Your preferred RelayCommand implementation
Hi, in our samples we use this implementation: https://github.com/Noesis/Tutorials/blo ... Command.cs
Regarding CanExecuteChanged our commands code doesn't rely on CommandManager to update UI so there was no need to expose the class to C#. You can just leave it as a simple event and raise it when CanExecute changes to notify the UI.
Regarding CanExecuteChanged our commands code doesn't rely on CommandManager to update UI so there was no need to expose the class to C#. You can just leave it as a simple event and raise it when CanExecute changes to notify the UI.
- Rocko Bonaparte
- Posts: 39
- Joined:
Re: Your preferred RelayCommand implementation
So it took something like three months for this to actually roll around and bite me in the butt!
I am manipulating some button enable states via a binding to some bools in their view models. The effect would inconsistently apply and it came down to CanExecuteChanged. I was still using a fairly typical RelayCommand implementation's CanExecuteChanged. The inconsistency came from stubbing out the add/remove implementations that originally used a CommandManager. I had to switch to the DelegateCommand implementation and lean on RaiseCanExecuteChanged().
I am manipulating some button enable states via a binding to some bools in their view models. The effect would inconsistently apply and it came down to CanExecuteChanged. I was still using a fairly typical RelayCommand implementation's CanExecuteChanged. The inconsistency came from stubbing out the add/remove implementations that originally used a CommandManager. I had to switch to the DelegateCommand implementation and lean on RaiseCanExecuteChanged().
-
sfernandez
Site Admin
- Posts: 2983
- Joined:
Re: Your preferred RelayCommand implementation
The problem was then that you didn't raise CanExecuteChanged in your own implementation, right?
And when you started using DelegateCommand and calling RaiseCanExecuteChanged on the appropriate moment, the buttons enabled state behave fine, is that correct?
And when you started using DelegateCommand and calling RaiseCanExecuteChanged on the appropriate moment, the buttons enabled state behave fine, is that correct?
Who is online
Users browsing this forum: Ahrefs [Bot], Google [Bot] and 92 guests