【问题标题】:Force binding update when doing something on a non-focusable control在不可聚焦的控件上执行某些操作时强制绑定更新
【发布时间】:2015-01-29 15:36:12
【问题描述】:

我有一个问题,我以一种不优雅的方式解决了,想知道是否有更好的解决方案。

我有一个视图,它可能包含仅在失去焦点时更新其绑定的文本框(它们的绑定属性使用UpdateSourceTrigger=LostFocus)。这是“几乎”正确的......我可以将绑定的UpdateSourceTrigger 设置为PropertyChanged,我不会有问题,一切都会按预期工作......但是,有一些潜在的计算昂贵的东西发生在更新这些绑定属性(涉及对已编辑对象的深度检查,这可能会很长时间)所以我实际上只想在完成编辑后更新绑定。

这是工具栏的问题,因为它们的按钮不可聚焦,因此单击它们(并发出命令)实际上不会使文本框失去焦点,因此在执行命令时,绑定尚未更新(考虑一个带有工具栏“保存”按钮的实体编辑视图,单击该按钮时会调用一个实际保存实体的保存命令。在这种情况下,实体将在失去焦点之前与文本框的值一起保存)

我可以在发出命令之前检查绑定并更新源(这就是我现在正在做的),但这意味着:

  • 有权访问执行命令的绑定(或控件)。由于解决方案完全不优雅,因此将其丢弃。命令操作是在其他一些应该与 WPF 无关的库上定义的。
  • 在代码隐藏事件处理程序上执行命令并执行绑定更新(或只是将焦点设置到其他内容并让 WPF 更新源),然后再引发命令。这是我现在正在做的,也是我不喜欢的(如果有其他解决方案,我更愿意将命令直接分配给工具栏按钮)。
  • 让 View 界面有一个“ForceEndEdit()”,当我执行一些可能会导致此问题的操作时,View 会执行并调用它。我觉得这很奇怪,我不想这样做。

有没有办法告诉 WPF 更新绑定“每当用户在控件之外调用命令 - 或单击按钮 - 不一定失去焦点”?如果没有,你们中的任何人有没有找到比上面提出的更优雅的解决方案,而我可能没有想到?

正如我所说,在这种特殊情况下,触发绑定更新 OnPropertyChanged(这是我所看到的类似 - 虽然不相同 - 问题的建议)并不是一个足够好的解决方案。

PS:这不仅适用于文本框,还适用于任何类型的编辑控件(日期选择器、范围选择器等),这些控件可能是第三方的,我不一定有访问他们的源代码。

PS2:我使用的是 .NET 4.5

【问题讨论】:

  • 您使用的是什么版本的 .NET?
  • 4.5,对不起,将添加到问题中

标签: c# wpf data-binding


【解决方案1】:

如果您在OnPropertyChanged()UpdateSourceTrigger=PropertyChanged 期间执行计算开销很大的操作,则应考虑在Binding 中使用Delay,以便Binding 仅在用户停止在控件中输入值时更新。

这可以解决您的问题,因为它是基于交互时间的,而不是在启动更新之前依赖某些其他事件/发生。这个属性是 .NET 4.5 中的新属性,这就是为什么我问你使用的是什么版本的 .NET。

【讨论】:

  • 在我开始对此解决方案进行测试之前,我还有一个问题:在执行除属性更改之外的其他操作后是否会立即出现延迟?我的意思是……说我延迟了 500 毫秒,“保存”按钮有一个 ctrl+s 快捷键。如果我正在编辑文本并在 500 毫秒之前按 ctrl+s,绑定会在发出命令之前更新吗?如果不是,那么我处于相同的情况(想法是:所有绑定都应该在引发命令之前更新,无论是什么导致命令引发)
  • 你也需要现实一点,我想。 500 毫秒是 0.5 秒。您认为用户在完成输入后合理尝试点击保存按钮或 Ctrl+S 快捷键的速度有多快?我认为即使有 500 毫秒的延迟,您也不太可能有脏绑定更新。如果延迟是 3000 毫秒,那么是的,绝对是,但不是 500 毫秒。仅供参考,在我处理的实时应用程序中,我们的更新延迟为 300 毫秒以供参考。 ;-)
  • 我通常以与输入代码相同的速度在 Visual Studio 上按 ctrl+s :-)。作为一个慢速打字机,我可以合理地说,如果我在打字时不需要思考(而且我在按下 ctrl-s 时绝对不会思考),我每秒可以轻松地完成大约 3-4 个字符。无论如何,我会在 300 毫秒内相信你的话,并对普通用户进行一些测量,然后为了安全起见减少一点延迟。查看代码库后,更改所有这些“不正确”绑定的影响实际上并不多,因此这可能是一种解决方案。
  • 我只是对实际应用程序进行了一些快速测试(不是样板视图),即使鼠标必须单击功能区栏,我也能够(不费吹灰之力)单击保存按钮低于 200 毫秒。如果不进行额外检查,恐怕这个解决方案对我不起作用。在这个特定的应用程序中,我无法承受因此而丢失数据的“快速用户”。特别是我在窗口上有一个“保存并关闭”按钮,它不允许用户看到实际数据尚未保存,直到为时已晚(这不会是“保存”的问题,因为它会警告在稍后关闭之前):-/
  • 正如我所说,计算时间足够长以致打字不流畅,但不足以“真正中断”......我可能会在编辑时让按钮闪烁,这不是我想要的。有意义的过程是:“单击保存按钮时完成更新绑定,然后保存”,这就是我现在正在做的事情......我希望有一个绑定触发器来执行它,而不是“主动失去焦点”或“必须等待一些时间”......比如:“点击任何其他不可聚焦的控件”,但由于没有,我现在使用的事件处理程序,或者更好的“bindable-proxy-command”将做。
猜你喜欢
  • 1970-01-01
  • 2015-10-24
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多