-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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 wrong item template selection in CmdPal #9487
Fix wrong item template selection in CmdPal #9487
Conversation
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.
Well this is mental. But a good workaround! Thanks!
</DataTemplate> | ||
|
||
<DataTemplate x:Key="NestedItemTemplate" x:DataType="local:FilteredCommand"> | ||
<Grid HorizontalAlignment="Stretch" ColumnSpacing="8" AutomationProperties.Name="{x:Bind Item.Name, Mode=OneWay}" AutomationProperties.AcceleratorKey="{x:Bind Item.KeyChordText, Mode=OneWay}"> |
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.
Are we losing the HelpText (More options) from x:Uid="CommandPalette_MoreOptions"
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.
Yeah -- we gotta keep this. I'll block for the answer. 😄
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'm a bit worried we're losing a couple things by leaving ListViewItem behind. Hmm. Can the ChoosingXyz event not return a ListViewItem?
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.
ChoosingItemContainer chooses an item container 😄 or more precisely - SelectorItem, which is a parent for *ViewItem.
I mean I played with Narrator and it felt OK.. but probably I missed stuff (my mind was erased while debugging WinUI).
What do you believe will be broken? How can I test that? I probably won't be able to make ChoosingItemContainer return something else, but if you tell me what the concern is, I might find an answer 😊
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 mean I lost MoreOptions (I was not aware of it unfortunately). I guess I can try to fix this 😊 But are there additional concerns?
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 will fix this by binding the automation properties in the code behind, and resubmit. Sorry.
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.
We're getting to the things I hate about XAML. It's like... we did all this work to get away from manually setting up specific values in the codebehind or in the xaml document for specific types of items, right? It was good and clean and smart: the DataTemplate provided everything we needed for the data type. And here, we're forced to add detection to ChoosingItemContainer (sp) to set up the container correctly based on the data type. Something the data template should be able to handle. All because of a silly issue. 😄
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 have expressed my distaste in the linked Xaml issue. Thanks for debugging through WinUI so much. 😀 It can be enough to drive a person mad.
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.
Okay, one last e-mail. It does not work if we add x:Uid="CommandPalette_MoreOptions"
to the Grid?
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.
No, it doesn't. There is no AutomationPeer for the grid. I am still wondering why the text is read correctly. Most probably due to the default automation peer on the internal text block.
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.
as mentioned
@DHowett - please re-review 😊 when you can. Currently main is quite broken without it! |
|
||
if (dataTemplate == _itemTemplateSelector.NestedItemTemplate()) | ||
{ | ||
const auto helpText = winrt::box_value(RS_(L"CommandPalette_MoreOptions")); |
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.
Just checking (and I will merge this before you reply! (unless you are quite fast!))
This is fine, and we never need to clear the Automation Property, because it is only ever applied to items that use the NestedItemTemplate template? And the cache stores them separately. Okay. I've talked myself into it.
|
||
</Grid> | ||
</ListViewItem> | ||
AutomationProperties.AcceleratorKey="{x:Bind Item.KeyChordText, Mode=OneWay}"/> |
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'm surprised this binding actually works! It's on the parent ListViewItem, but that ListViewItem is never bound to the actual object in our code. Is this just something that ListView handles for us?
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'm testing this out locally, but I expect to merge it!
As expected, it is perfect. |
Thank you @Don-Vito. For both fixing this and putting up with my concerns ALL THE TIME |
There seems to be a bug in WinUI (see microsoft/microsoft-ui-xaml#2121) that results in heterogeneous `ModernCollectionBasePanel` configured with `DataTemplateSelector` and virtualization enabled to recycle a container even if its `ContentTemplate` is wrong. I considered few options of handling this: * Disabling virtualization (by replacing item container template with some non-virtualizing panel (e.g., `StackPanel`, `VirtualizingStackPanel` with `VirtualizationMode`=`Standard`) * Replacing `DataTemplateSelector` approach with `ChoosingItemContainer` event handling approach, which allows you to manage the item container (`ListViewItem`) allocation process. I have chosen the last one, as it should limit the amount of allocations, and might allow optimizations in the future. The solution introduces: * A container for `ListViewItem`s in the form of a map of sets: * The key of this map is a data template (e.g., `TabItemDataTemplate`) * The value in the set is the container * `ChoosingItemContainer` event handler that looks for available item in the container or creates a new one * `ContainerContentChanging` event handler that returns the recycled item to the container Closes #9288 (cherry picked from commit e02d9a4)
🎉 Handy links: |
🎉 Handy links: |
Surprise surprise! we ran into an old friend: * #9288 * #9487 * microsoft/microsoft-ui-xaml#2121 so uh, this is ded.
PR Checklist
Detailed Description of the Pull Request / Additional comments
There seems to be a bug in WinUI (see microsoft/microsoft-ui-xaml#2121)
that results in heterogeneous
ModernCollectionBasePanel
configuredwith
DataTemplateSelector
and virtualization enabledto recycle a container even if its
ContentTemplate
is wrong.I considered few options of handling this:
some non-virtualizing panel (e.g.,
StackPanel
,VirtualizingStackPanel
with
VirtualizationMode
=Standard
)DataTemplateSelector
approach withChoosingItemContainer
event handling approach, which allows you to manage the
item container (
ListViewItem
) allocation process.I have chosen the last one, as it should limit the amount of allocations,
and might allow optimizations in the future.
The solution introduces:
ListViewItem
s in the form of a map of sets:TabItemDataTemplate
)ChoosingItemContainer
event handler that looks for availableitem in the container or creates a new one
ContainerContentChanging
event handler that returns therecycled item to the container