Repository navigation
CommandParameter invalidates CanExecute - #4217
Merged
Merged
Conversation
Member
|
@miloush: As soon as Sam has bandwidth, he will review this. Thanks. |
miloush
force-pushed
the
CommandParameter
branch
from
April 3, 2022 16:13
ee7069f to
d78af6f
Compare
Member
|
A year has passed.. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes Issue #3452 #4078 (also discussed in #316)
In summary, the issue is that
and
behave differently. In the latter case,
C.CanExecuteis called to determine whether the element should be enabled, but since the parameter has not been parsed yet,CanExecuteis called with anullargument. After the parameter is parsed, the status of the command is not re-evaluated and therefore the element stays disabled when it shouldn't be.A common workaround is to use the former syntax.
Description
Adds property changed callback to
CommandParameterPropertywherever applicable (MenuItem,ButtonBase,Hyperlink,RibbonGallery,RibbonTextBox) to callUpdateCanExecute.This way, changing command parameter makes it re-evaluate command's
CanExecutevalue. Most notably, this will make the order ofCommandandCommandParameterproperties in XAML irrelevant.Note that
ThumbButtonInfoalready implements this behaviour.Customer Impact
Not taking this fix retains the existing XAML attributes order significance (and the inconsistency with
ThumbButtonInfobehaivour).Testing
This has not been tested as the branch does not build at the time of submitting this PR. Happy to test if further instructions provided.
Risk
No public API changes, 5 private static methods and callback instances in DP properties introduced. All changes in the PresentationFramework assembly.
The new behaviour will cause the
CanExecutemethod of commands to be called more often (with every parameter change), and specifically twice during loading of the element (which could be avoided by deferringCanExecutetoEndInitphase).If user changes both parameter and command and changes the command parameter first, with the new behaviour the existing command will potentially be called with a command parameter of an unexpected type. Since the API accepts
objectthough, the implementations ofCanExecuteshould be able to handle bothnulland any object type.