-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
SelectingItemsControl is handling too many user interactions without options to disable #15433
Comments
I wish I'd seen that PR before it got merged because
However... This is beside the point because after speaking with @billhenn privately, the I first plan to enumerate the differences between Avalonia and WPF in respect to where interactions are handled with regards to items controls to get an idea of where we differ. |
One related thing I've noticed is that setting It's debatable if IsHitTestVisible=false should make a list box item invisible for keyboard selection as well but I believe WPF works this way. |
Took a while to get around to this, sorry. Here's what handles interactions in the most common selecting items controls in Avalonia and WPF: ComboBoxAvalonia
WPF
ListBoxAvalonia
WPF
TabControlAvalonia
WPF
So it looks like |
My question for you now @billhenn is could you go into a bit of detail on why it's easier to customize interactions by overriding methods in the container rather than in the items control itself? One would have thought that it doesn't make much difference where these interactions are handled. (I know you explained it to me privately but would be good for it to be of public record) |
Sure @grokys, someone building a primitive However, for core Avalonia controls like this, there are times where things might be customized further and other container control types introduced. A specific instance of this is a ribbon "backstage" control, which we may or may not be working on. 😉 The A problem with all interactions being in the items control itself, is that in the case of In summary, a |
Is your feature request related to a problem? Please describe.
We are implementing a control that indirectly inherits
SelectingItemsControl
. Some of the items in the control are items that should be selectable, and others (such as separators) are items that should not be selectable. We have found that there are built-in user interactions inSelectingItemsControl
such as focus tracking, clicking, etc. on items that trigger the event source item to be selected.WPF's
Selector
class used a more manual approach for updating selection, which did allow multiple kinds of items to be displayed, while only allowing a subset to be selectable.Describe the solution you'd like
We'd love to see the best of both worlds, where current features in
SelectingItemsControl
that deal with user interactivity can be retained, but add an option or options to turn them off.Either that, or have some callback such as:
And have that determine if a child container control is selectable before automatically trying to select it.
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: