CommandParameter is null when call CanExecute method at first time

[chenyj796]

• .NET Core Version: (3.0.0-preview-27122-01)
• Windows version: (windows 10)
• Does the bug reproduce also in WPF for .NET Framework 4.6.1?: Yes

Problem description:

I have a TestCommand as below:

public class TestCommand : ICommand
{
    public event EventHandler CanExecuteChanged;

    public bool CanExecute(object parameter)
    {
        return true;
    }

    public void Execute(object parameter)
    {
    }
}

and then I use it in a xaml file:

<Button Content="Test" Command="{StaticResource testCommand}" CommandParameter="abcdef"/>

Actual behavior:
At first time the CanExecute method is called, the parameter's value is null。
If I change the XAML property's order as below, the parameter's value is abcdef (that's ok):

<Button Content="Test" CommandParameter="abcdef" Command="{StaticResource testCommand}"/>

Expected behavior:
The parameter's value is not null at each time, regardless of the XAML order

Minimal repro:

[bhood-zorus]

I'm having uncomfortable flashbacks to when I first learned of this ☹️

I'm not sure anything can be done about this. XAML properties are assigned sequentially, and I doubt that's negotiable. This would probably require some kind of hack in the XAML reader.

[brian-reichle]

@brandonhood, or the button could just defer the call between BeginInit and EndInit?

[chenyj796]

In my opinion, the XAML equals to the codes:

var button = new Button
{
    Content = "Test",
    Command = ...
    CommandParameter = ...
};

and the CanExecute method will be called by some methods such as Load ...

[brian-reichle]

The .NET framework version of the xaml parser honours the ISupportInitialize interface (which is implemented by FrameworkElement), so its actually more like this:

var button = new Button();
((ISupportInitialize)button).BeginInit();
button.Content = "Test";
button.Command = ...
button.CommandParameter = ...
((ISupportInitialize)button).EndInit();

[weltkante]

@brian-reichle but that would have to be done for every control to which you can attach a command, otherwise you have only fixed it for an individual case and all other controls still behave differently

[edit] the implementation proposed in #1179 avoids this issue by implementing it in a central helper method PresentationFramework.dll!MS.Internal.Commands.CommandHelpers.CanExecuteCommandSource(System.Windows.Input.ICommandSource commandSource) so I retract that concern.

[stevenbrix]

I agree that this behavior is incorrect. I think something like this should be pretty straightforward to do. FrameworkElement has an OnInitialized override that Button should be able to invoke the command from. However, we don't know who is currently depending on the current behavior, so this is something that we can look into fixing after the initial release of .NET Core 3.

[vflame]

This issue been around for a while. The easiest fix for now is to change the order so that CommandParameter appears before Command but order should not matter.

Related: https://stackoverflow.com/questions/335849/wpf-commandparameter-is-null-first-time-canexecute-is-called

[MichaelVach]

I would like to propose a solution for the Button and MenuItem cases mentioned in the linked Stack Overflow question above.

Looking at stack trace that leads to the bug for the Button case

StackTrace leading to ICommand.CanExecute Bug.txt

we see that the error occurs in the
PresentationFramework.dll!MS.Internal.Commands.CommandHelpers.CanExecuteCommandSource(System.Windows.Input.ICommandSource commandSource)
method

The idea is to delay the execution of this method until the WPF elements are initialized. See the above linked commit 0c6b967 for the details.

[MichaelVach]

The attached test project can be used to verify the proposed solution.

CommandCanExecuteProject.zip