Posted 24 May 2019, 6:56 am EST
Hi Ruchir, thanks for your test example. It’s very quick for me as well, so the problem is clearly on our end somewhere. I’m not sure where that is at this point The collection is completely filled from the start, there is nothing iterative going on - that’s why the autocomplete functionality works well from the very start, and it’s just opening the drop-down opening that presents a problem.
Originally, the source was a <class,string> dictionary with DisplayMemberPath and KeyValuePath set. Then I switched it to a list (keeping the DisplayMemberPath - but I can probably override the ToString on the class to get rid of it. Maybe that’s the problem here, though it seems like virtualization should make this a non-issue (and again, autocomplete works fine). The delay goes up linearly/incrementally with the size of the list - 1k is slow, and 30k unbearable, so it really feels like it’s rendering all the items in the dropdown. Is there something we could be doing that is defeating virtualization (like what can happen when you stick a virtualized control into another scrollview and let it grow)? For reference, here is how it’s used in xaml, no special options or styles.
<c1:C1ComboBox Grid.Row="3" Grid.Column="3" IsEnabled="True" AutoComplete="True" IsEditable="False"
ItemsSource ="{Binding SecuritiesViewSource.View}"
SelectedValue="{Binding SelectedSecurity, Mode=TwoWay}"
DisplayMemberPath="name">
<!--<c1:C1ComboBox.ItemsPanel>
<ItemsPanelTemplate>
<VirtualizingStackPanel />
</ItemsPanelTemplate>
</c1:C1ComboBox.ItemsPanel>-->
</c1:C1ComboBox>
I used to just bind the source to the collection, but switched to creating the viewsource manually just in case - no change there.
I’m sorry, I don’t think I can snip out this part of the application into a test project, but I’ll experiment a bit more. For now I replaced it with our FlexGrid-based control, but the combobox solution would be a bit neater in this particular context.
