[NathanDrake2406]

What does the pull request do?

Makes NativeMenuItem query CanExecute again when its CommandParameter changes, so IsEnabled matches the current parameter.

What is the current behavior?

NativeMenuItem queries Command.CanExecute(CommandParameter) only when Command changes. If CommandParameter is assigned afterwards, IsEnabled keeps the result for the previous parameter.

This is the cause of #21914. When the application DataContext is set before AvaloniaXamlLoader.Load, a Command binding resolves at the moment it is applied. A CommandParameter written as a property element is assigned after that:

<NativeMenuItem Header="Int Parameter" Command="{Binding IntParameterCommand}">
  <NativeMenuItem.CommandParameter>
    <x:Int32>123</x:Int32>
  </NativeMenuItem.CommandParameter>
</NativeMenuItem>

The item calls CanExecute(null). A command such as RelayCommand<int> returns false for a null parameter, and the item stays disabled. When the DataContext is set after the XAML is loaded, the parameter is already present when the command arrives, so the item is enabled.

A string parameter is not affected, because RelayCommand<string> accepts null.

What is the updated/expected behavior with this PR?

Scenario	Before	After
Command set, then CommandParameter set to a value the command accepts	Item stays disabled	Item is enabled
CommandParameter changed to a value the command rejects	Item stays enabled	Item is disabled
CommandParameter changed on an item without a Command	IsEnabled unchanged	IsEnabled unchanged

In the sample from the issue, the Int Parameter and Bool Parameter items are now enabled for all three DataContext locations. The Timespan Parameter item stays disabled, because its command uses CanNeverExecute.

How was the solution implemented (if it's not obvious)?

NativeMenuItem.OnPropertyChanged now calls the existing CanExecuteChanged() method when CommandParameterProperty changes. Button and MenuItem already query CanExecute again in their CommandParameterProperty branches, so this follows the same contract.

The new branch does nothing when Command is null. CanExecuteChanged() writes IsEnabled directly and uses true when there is no command. Without the guard, a parameter change would enable an item that has IsEnabled="False" and no command.

Scope:

• TrayIcon also has Command and CommandParameter, but it queries CanExecute only at click time and stores no result. It is not affected.
• NativeMenuBarPresenter forwards the parameter to a managed MenuItem, which already handles the change.
• The Command branch still overwrites an explicit IsEnabled value. That behaviour is unchanged here.

Validation:

• Added NativeMenuItemTests with a command that accepts only an int parameter. The two tests that set and clear CommandParameter after Command fail without the fix and pass with it. The third test covers the item without a command.
• Loaded the XAML shape from the issue (TrayIcon.Icons on an Application, Command binding, x:Int32 property element) with the runtime XAML loader. With the DataContext set before the load, the item is disabled without the fix and enabled with it. With the DataContext set after the load, the item is enabled in both cases. This check is not part of the PR.
• Ran the NativeMenuItemTests and TrayIconTests classes in Avalonia.Controls.UnitTests. All pass.
• Not verified on a physical tray menu on Windows, macOS, or Linux.

Checklist

• Added unit tests (if possible)?
• Added XML documentation to any related classes?
• Consider submitting a PR to https://github.com/AvaloniaUI/avalonia-docs with user documentation

Breaking changes

None. An item whose command result depends on the parameter can now change IsEnabled when the parameter changes.

Obsoletions / Deprecations

None.

Fixed issues

Fixes #21914

[github-actions]

NuGet packages

The packages for this pull request have been published (workflow run):

• Version: 12.2.999-cibuild0100233-alpha
• Feed URL: https://nuget-feed-all.avaloniaui.net/v3/index.json