-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: SplitButton.Click
is not fired when SplitButton
is not in focused
#16940
base: master
Are you sure you want to change the base?
fix: SplitButton.Click
is not fired when SplitButton
is not in focused
#16940
Conversation
You can test this PR using the following package version. |
base.OnKeyDown(e); | ||
} | ||
|
||
/// <inheritdoc/> | ||
protected override void OnKeyUp(KeyEventArgs e) | ||
{ | ||
var key = e.Key; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For both of these changes it's a lot easier to read the changes if you just check and exit on entry:
if (!IsFocused)
{
base.OnKeyUp(e);
return;
}
- That would remove a lot of noise in this PR
- It helps with maintainability and readability to reduce nesting in the logic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I preferred this solution because IL is more compact, see example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think IL really matters here, as JIT might produce very similarly efficient code in the end.
But I don't like doubling base.OnKeyUp(e);
call. Early returns are great, but duplicating base calls is not so much.
var key = e.Key; | ||
|
||
if (key == Key.Space || key == Key.Enter) | ||
if (IsFocused) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about IsEffectivelyEnabled? We should probably check that too, right?
@workgroupengineering Whatever is done here MUST also be done to button. SplitButton copied the logic from Button originally so it would have the same issue. Edit: Looking back at the Button PR for similar issue's you are not implementing the changes the same. I don't think that's a good idea. Button itself probably shouldn't even process Code should not diverge like this (admittedly this is my fault I'm going to have to fix in Avalonia 12. I shouldn't have followed WinUI and should just have inherited Button in SplitButton). |
You can test this PR using the following package version. |
What does the pull request do?
What is the current behavior?
What is the updated/expected behavior with this PR?
How was the solution implemented (if it's not obvious)?
Checklist
Breaking changes
Obsoletions / Deprecations
Fixed issues
Continue of #16184