在 WPF 中快速显示大型排序列表?

发布于 2024-08-18 11:57:26 字数 310 浏览 7 评论 0原文

我正在开发一个程序,该程序应该能够显示长(最多 500 项)数据列表,当内容发生变化时需要重新处理这些数据。

本质上,我有一个带有可观察集合的视图模型,其中包含带有绑定到 gui 的可观察数据的类,该数据显示在 ListView 中。

数据必须是排序的,但数据也可能随时发生变化,每次都需要对列表进行重新排序。

在不锁定 GUI 的情况下显示和保持整个事物的最佳机制/隐喻是什么?我有一个使用 NotifyCollectionChangedEventArgs 和一些排序函数的解决方案,但它很慢 - 我假设每次数据元素更改时它都会重新启动并重建整个 GUI。

I am developing a program that should be able to display long (up to 500 items) lists of data that need to be resorted when their contents change.

Essentially, I have a viewmodel with an observable collection that contains classes with observable data bound to the gui, which is displayed in a ListView.

The data must be sorted, but the data may also change at any time, and the list needs to be resorted each time.

What is the best mechanism / metaphor for displaying and keeping the whole thing resorted without locking up the GUI? I have a solution using NotifyCollectionChangedEventArgs and some sorting functions, but its SLOW - I'm assuming it resorts and rebuilds the entire GUI each time a data element is changed.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

温柔戏命师 2024-08-25 11:57:26

查看 CollectionView/CollectionViewSource 类。这些类位于 ObservableCollection 和 WPF 的数据绑定逻辑之间,以便执行排序、过滤等操作。

我怀疑从 NotifyCollectionChanged 编写自己的排序函数是性能问题的根源;这取决于您的精确实现,但是当您对列表进行排序时,可能会引发一系列 CollectionChanged 事件,这会导致 WPF 在排序例程的每次迭代中重新绑定集合...这将非常慢,因为您描述的。

CollectionView 和 CollectionViewSource 不会影响源集合,只会影响 UI 上显示的集合视图,因此您应该会看到比现在正在执行的操作有了显着的加速。当 Microsoft 的 DataGrid 控件发布时,他们它的演示显示和排序数百万行 - 并且它正是使用这些类来执行排序。您确实不应该在 500 行上看到性能问题。

最后,CollectionView 和 CollectionViewSource 之间的区别在于它们的设计用途;当您在 C# 中工作时使用 CollectionView,当您通过 XAML 进行操作时使用 CollectionViewSource。您可能还想查看本文以快速了解这些类。

Have a look at the CollectionView/CollectionViewSource classes. These classes sit 'between' your ObservableCollection and WPF's data binding logic in order to perform operations like sorting, filtering, etc.

I suspect that writing your own sorting functions off of NotifyCollectionChanged is the source of your performance issues; it depends on your precise implementation, but there probably are a flurry of CollectionChanged events being raised as you sort the list, which results in WPF re-binding the collection each iteration of your sort routine... which would be incredibly slow, as you described.

CollectionView and CollectionViewSource don't affect the source collection, just the view of the collection displayed on the UI, so you should see a significant speedup over what you are doing now. When Microsoft's DataGrid control was released, they had demos of it displaying and sorting millions of rows - and it's using precisely these classes to perform its sorts. You really shouldn't be seeing performance problems on 500 rows.

Finally, the difference between CollectionView and CollectionViewSource are where they are designed to be used; CollectionView is used when you are working in C#, CollectionViewSource when you're doing it from XAML. You may also want to have a look at this article for a quick overview of these classes.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文