Strange behaviour on DelegateCommand

Nov 12, 2008 at 5:58 PM
Hi

I have created a command like:

DelegateCommand<string> myCommand = new DelegateCommand<string>(OnMyCommandExecute, OnMyCommandCanExecute)

myCommand is bound to a Button.

I can see that OnMyCommandExecute and OnMyCommandCanExecute is executed,,,
I expected that the button should be disabled when the OnMyCommandCanExecute returned false,,, but the button is enabled regardless of what OnMyCommandCanExecute returns...

Any tip how to debug this,, or what to think about,,, will make me happy..  :)

//lasse
Nov 17, 2008 at 3:19 PM
Thoughts:

Check that the Command links through to the Execute method correctly so you know the link from button to Command is complete.
Breakpoint the CanExecute method to ensure it's being called.
Remember you need to call myCommand.RaiseCanExecuteChanged()  if you want the button to requery the CanExecute method for a new value.
Check there's no styles with triggers which might be overriding your enabled value?

Martin  
Dec 3, 2008 at 9:38 AM
Hi,

The big problem is that DelegateCommand<T> doesn't invokes the canExecuteMethod handler after executed!
IMHO this is a must behavior. It is not reasonable to call RaiseCanExecuteChanged after executing every command,
Also, RaiseCanExecuteChanged should be executed again for all other command based on the state that was changed.

Using routed commands, WPF automatically invalidates the visual tree commands on every input event. This is a great mechanism, and I think that it should be added to Prism.

Tomer
Jan 22, 2009 at 3:05 AM
Edited Jan 22, 2009 at 3:10 AM
Tomer,
  I'm running into this same exact issue when trying to setup some menuitems with DelegateCommand commands.
  I think that you nailed the issue, and hope that they look into this for drop 10, as this is a must.
  I think in my case, I'm going to revert to a regular WPF RoutedCommand, handling it in the view code behind and then the calling a method on the presenter to do the actual handling. Little bit of extra code, but can't see any reason it won't work for now.
Jeff
Jan 22, 2009 at 11:28 AM

Hi

 

Perhaps you might find these thread by Julian Dominguez, developer of the Prism-v1 & Prism-v2 projects, useful. In it, he explains the reason for this behavior of Delegate Commands.

 

Having considered this, if routed commands do suite your needs you should use them.

 

Please let me know if this helps.

 

Damian Schenkelman

http://blogs.southworks.net/dschenkelman
Jan 27, 2009 at 1:27 AM
For whatever it's worth to anyone who comes across this thread, I noticed inconsistent results using the following:

         CommandManager.RequerySuggested += (s, e) => FileNewCommand.RaiseCanExecuteChanged();

On the other hand, I noticed very consistent results calling RaiseCanExecuteChanged() on the DelegateCommand instance at the appropriate time
Jan 27, 2009 at 4:49 AM
Hi Kona,

  I have the same problem, at first I thought I did something wrong and rechecked all code.
 But it looks like CommandManager.RequerySuggested += (s, e) => FileNewCommand.RaiseCanExecuteChanged(); does not work all the time.

 Maybe someone can share some light on this ?

Regards,
Calin

Jan 27, 2009 at 1:26 PM

Hi Kona/Calin,

 

Are you having issues with the timing of the command’s execution? If so, that could be because unless the commands are in the UI Thread they will be enqueued and executed asynchronously.

 

If this is not your scenario, please send some more information so we can look further into this.

 

Hope this helps,

 

Damian Schenkelman

http://blogs.southworks.net/dschenkelman
Jan 28, 2009 at 12:40 AM
well, my particular issue was that even though the CanExecute method was being called, the UI elements didn't seem to be getting the property enabling / disabling to reflect it.
I would literally run the application one time, and it worked as expected, then run it again without any code changes, and it didn't work as expected (menu items didn't enable / disable consistent with the CanExecute method return value).

I might be missing something, but the whole "Suggested" part of the event name gave me some doubt as to its consistency as well (like I'm suggesting you update the element, but you don't have to if you are busy with something else).
Feb 2, 2009 at 4:17 PM
seems to work fine for me, raising the "

RaiseCanExecuteChanged

"

, didnt try the other solution as I couldnt make out what it was!!