You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RelayCommand's automatically disables concurrent execution which is great. They also offer the option for a property to have the attribute [NotifyCanExecuteChangedFor(nameof(GreetUserCommand))] and the command to have [RelayCommand(CanExecute = nameof(CanGreetUser))] so that the command decides if it can execute based on a property changing.
What isn't possible (or at least would require a lot of boilerplate code) is: disabling commands while other commands are running. For example, say I have a few commands in a .NET MAUI application that open pages. Disabling concurrent execution prevents a user from repeatedly pressing one button to open multiple pages, but if they press the other buttons then it is possible several pages will open causing unpredictable bugs.
In the past, I've used an IsBusy property on base view models where commands have disabled if IsBusy is set to true. This maybe isn't necessary to achieve the goal, so maybe something else like allowing commands to be grouped together where they aren't allowed to execute if another command in the group is executing.
API breakdown
// has a downside where it can only disables execution with every other command that is running[RelayCommand(DisableConcurrentExecutionsWithOtherCommands =true)]privatevoidGreetUser(User?user){
Console.WriteLine($"Hello {user!.Name}!");}
// commands could be grouped in some way so that commands in a group never execute at the same time as each other[RelayCommand(DisableConcurrentExecutionsWithOtherCommands(nameof(ArbitraryUniqueGroupIdentifierA)))]privatevoidGreetUser(User?user){
Console.WriteLine($"Hello {user!.Name}!");}[RelayCommand(DisableConcurrentExecutionsWithOtherCommands(nameof(ArbitraryUniqueGroupIdentifierB)))]privatevoidSomeOther(User?user){
Console.WriteLine($"Hello {user!.Name}!");}
// if you didn't need to call "[NotifyCanExecuteChangedFor(nameof(GreetUserCommand))]" for every command you have on an "IsNotBusy" property, this would work too with the existing syntax[RelayCommand(CanExecute = nameof(IsNotBusy))]privatevoidGreetUser(User?user){
Console.WriteLine($"Hello {user!.Name}!");}// Maybe something like this which was in Prism where it can be applied after the command has been created
GreetUserCommand.ObservesCanExecute((()=> IsNotBusy);
// An attribute[ListenForPropertyChange(SourceProperty= nameof(IsBusy)]//Which would generate source like:overrideOnPropertyChanged(string propertyName){if(propertyName== nameof(IsBusy)){
OnPropertyChanged(nameof(DependentProperty));}}
OR// Something better entirely
Usage example
See API breakdown
Breaking change?
I'm not sure
Alternatives
This user behaviour is more rare than double tapping the same command/button, so it doesn't cause problems as often
Considered writing some reflection stuff and overriding IsBusy on every viewmodel but that would probably add too much boilerplate
Additional context
No response
Help us help you
No, just wanted to propose this
The text was updated successfully, but these errors were encountered:
Overview
RelayCommand
's automatically disables concurrent execution which is great. They also offer the option for a property to have the attribute[NotifyCanExecuteChangedFor(nameof(GreetUserCommand))]
and the command to have[RelayCommand(CanExecute = nameof(CanGreetUser))]
so that the command decides if it can execute based on a property changing.What isn't possible (or at least would require a lot of boilerplate code) is: disabling commands while other commands are running. For example, say I have a few commands in a .NET MAUI application that open pages. Disabling concurrent execution prevents a user from repeatedly pressing one button to open multiple pages, but if they press the other buttons then it is possible several pages will open causing unpredictable bugs.
In the past, I've used an
IsBusy
property on base view models where commands have disabled ifIsBusy
is set to true. This maybe isn't necessary to achieve the goal, so maybe something else like allowing commands to be grouped together where they aren't allowed to execute if another command in the group is executing.API breakdown
OR// Something better entirely
Usage example
See API breakdown
Breaking change?
I'm not sure
Alternatives
Additional context
No response
Help us help you
No, just wanted to propose this
The text was updated successfully, but these errors were encountered: