线程和 WPF 的绑定
情况
我的应用程序出现以下不稳定的行为:大约 20 次执行中有一次,WPFToolkit 的 DataGrid
绑定到 DataTable
不会渲染所有行,缺少预期的全部 4 行中 1 到 3 行之间的任何内容。
内部工作
DataGrid
绑定到DataTable
、D1,它是自定义类的属性,<强>C1。- 当用户激发视图时,我们必须从后端检索数据,这可能需要时间。为此,我们创建一个线程(实际上,我们使用
BackgroundWorker
来执行此操作,但使用其中一个似乎没有区别),它运行一个方法 M1,打开连接并请求数据。该线程用于避免应用程序无响应。 - M1 首先检索数据并将其存储在 DTO 上。之后,他要求C1清理它的桌子。 C1 执行此操作(通过调用
D1.Clear()
)并引发NotifyPropertyChanged()
(从线程)。 - M1 将新后端的
DataTable
传递给 C1,后者将逐行插入到 D1 中。插入行完成后,C1 引发NotifyPropertyChanged()
。线程退出。
所以,换句话说,我清除表,通知 WPF,插入数据,通知 WPF 然后退出。
在我看来,只要从 UI 正确使用最后一个 Notify,它就应该始终 显示所有行。
除了DataTable
之外,还有大量属性(主要是字符串和整数)正在更新并因此得到通知。我们在任何其他情况下都没有观察到这种行为,仅在DataTable
中观察到这种行为。
我知道这深入到了 WPF 的绑定机制,但我希望任何人都可以在这里阐明。欢迎任何有关 WPF 绑定或多线程与 WPF 的信息。
The Situation
I'm getting the following inconstant behavior on my application: One in about 20 executions, a WPFToolkit's DataGrid
which is bound to a DataTable
won't render all the rows, missing anything between 1 to 3 of the whole 4 rows that were expected.
Inner Workings
- The
DataGrid
is bound to aDataTable
, D1, which is a property of a custom class, C1. - When the user stimulates the view, we must retrieve the data from the back-end, which can take time. To do so, we create a thread (actually, we use
BackgroundWorker
for that but there seems to be no difference from using one or the other), which runs a method, M1, that opens the connection and request the data. The thread is used to avoid having an unresponsive application. - M1 retrieves data and stores it on a DTO first. After that, he asks C1 to clear it's table. C1 does so (by calling a
D1.Clear()
) and raisesNotifyPropertyChanged()
(from the thread). - M1 passes the new backend's
DataTable
to C1, which inserts row by row into D1. After finishing inserting the rows, C1 raisesNotifyPropertyChanged()
. The thread exits.
So, in other words, I clear the table, notify WPF, insert the data, notify WPF and exit.
In my view, as long as the last Notify is correctly consumed from the UI, it should always show all the rows.
Besides the DataTable
, there are a large number of properties (mostly strings and int) being update and thus notified. We have not observed this behavior in any other case, only with the DataTable
.
I know this goes deep into WPF mechanisms for binding, but I hope anyone can shed a light here. Any information about WPF binding or multi-threading with WPF is welcome.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
DataTable 早于 WPF,因此未实现 < a href="http://msdn.microsoft.com/en-us/library/ms668604.aspx" rel="nofollow">INotifyCollectionChanged 这是 WPF 监视集合更改的方式。您有两个选择:
INotifyPropertyChanged 会在属性发生更改时发出通知,而不是在内部状态(无论是属性还是集合)发生更改时发出通知。当您触发 Property Changed 事件时,如果属性与上次绑定数据时的对象不同,WPF 只会重新绑定控件。当您仅更改对象图中几层的一个属性时,这可以防止刷新整个屏幕。
DataTable pre dates WPF and thus doesn't implement INotifyCollectionChanged which is how WPF monitors for collection changes. You have two options:
INotifyPropertyChanged notifies when the property has changed, not when the internal state (be it a property or collection) have changed. When you fire the Property Changed event WPF only rebinds the controls if the property is a different object from the last time it bound the data. This keeps it from refreshing the whole screen when you only change one property several layers down in an object graph.
您是否将新数据加载到已绑定到 DataGrid 的相同 DataTable 实例中?
如果是这样,那么 (a) 每次您从后台代码对 DataTable 进行更改时,它都会从错误的线程发出通知,这是一个禁忌; (b) 当您最后触发 PropertyChanged 时,DataGrid 可能足够聪明,注意到引用实际上并未更改,因此它不需要执行任何操作。 (我不知道 DataGrid 是否试图变得那么聪明,但这并不是没有道理的——特别是考虑到 WPF 在集合之上构建视图 - 它可能有助于解释您所看到的症状。)
尝试每次都创建一个新的 DataTable 实例你需要刷新,然后当您从后台线程填充该实例后,将新的(完全填充的)引用分配给您的通知属性并触发 PropertyChanged (当然,请确保执行分配+PropertyChanged来自 UI 线程)。
Are you loading the new data into the same DataTable instance that's already bound to the DataGrid?
If so, then (a) every time you make a change to the DataTable from your background code, it's firing notifications from the wrong thread, which is a no-no; and (b) when you fire PropertyChanged at the end, the DataGrid might be clever enough to notice that the reference didn't actually change, so it doesn't need to do anything. (I don't know whether DataGrid tries to be that clever, but it wouldn't be unreasonable -- especially given the way WPF constructs views on top of collections -- and it might help explain the symptoms you're seeing.)
Try creating a new DataTable instance every time you need to refresh, and then when you're done populating that instance from your background thread, then assign the new (fully-populated) reference into your notifying property and fire PropertyChanged (and, of course, make sure to do the assignment+PropertyChanged from the UI thread).
基于 Asti 的第三点,我经常遇到跨线程 PropertyChanged 场景,并为此拥有一个基本视图模型。视图模型基于 PRISM
NotificationObject
,但是如果您不想使用 PRISM,当然可以直接实现INotifyPropertyChanged
接口。如果您使用过 Silverlight,它也同样适用。Based on Asti's third point, I often come across a cross-thread PropertyChanged scenario and have a base view model for that. The view model is based on the PRISM
NotificationObject
, but of course you can implement theINotifyPropertyChanged
interface directly if you do not wish to use PRISM. Works just as well for Silverlight if you ever use it.ListChanged
,DataRowView 有PropertyChanged
。PropertyChanged
不是线程安全的。您不能导致任何更改在不同线程上触发PropertyChanged
。它必须在调度员上完成,因此找零必须通过调度员。例如,您应该使用 Dispatcher.Invoke(new Action(model => model.Data = newData), Model) 或类似的名称,而不是
Model.Data = newData
。ListChanged
and DataRowView hasPropertyChanged
.PropertyChanged
is not thread safe. You cannot cause any change to triggerPropertyChanged
on a different thread. It must be done on the dispatcher, so have the change go through the dispatcher.E.g., Instead of
Model.Data = newData
, you should useDispatcher.Invoke(new Action(model => model.Data = newData), Model)
or similar.