调用CommandManager.InvalidateRequerySuggested()比我想要的更长时间才能生效(在UI控件被禁用之前1-2秒延迟).
我有一个系统,我将任务提交给基于后台线程的任务处理器.此提交发生在WPF UI线程上.
当这个提交发生时,管理我的后台线程的对象做了两件事:
它引发了一个"忙"事件(仍然在UI线程上),几个视图模型响应; 当他们收到这个事件时,他们IsEnabled会给自己设置一面旗帜false.我的视图中的控件(数据绑定到此属性)会立即显示为灰色,这正是我所期望的.
它通知我的WPF ICommand对象不应该允许它们执行(同样,仍然在UI线程上).因为没有像对象那样INotifyPropertyChanged的ICommand东西,我被迫调用CommandManager.InvalidateRequerySuggested()强制WPF重新考虑我的所有命令对象的CanExecute状态(是的,我实际上需要这样做:否则,这些控件都不会被禁用).但是,与第1项不同,我的按钮/菜单项/等使用ICommand对象在视觉上更改为禁用状态所需的时间要长得多,而对于IsEnabled手动设置其属性的UI控件则需要更长的时间.
问题是,从用户体验的角度来看,这看起来很糟糕 ; 我的一半控件立即显示为灰色(因为它们的IsEnabled属性设置为false),然后整整1-2秒后,我的控件的另一半跟随(因为他们的CanExecute方法最终被重新评估).
所以,我的问题的第一部分:
听起来很愚蠢,有没有办法让CommandManager.InvalidateRequerySuggested()我的工作更快？我怀疑没有.
很公平,我的问题的第2部分:
我如何解决这个问题？我希望我的所有控件都可以同时禁用.它只是看起来不专业而且很尴尬.有任何想法吗？:-)
我的应用程序是使用WPF中的MVVM模式编写的,我的所有Buttons都使用Command绑定来执行模型中的代码.所有命令都在CanExecute中具有代码,以确定绑定Button的Enabled状态.逻辑运行完美,但在所有情况下,除非我点击GUI中的其他位置,否则GUI将保持禁用状态.
例如,我有一个名为Discard Candy的按钮.当我单击此按钮时,它会在线程池线程中启动一个进程,该进程将名为Running的bool属性设置为true.由于Discard Candy命令的CanExecute方法看起来像这样
public bool CanExecute(object parameter)
{
return !Running;
}
一旦过程开始,该按钮将被禁用.问题是当进程完成时,Running会设置为false,但GUI不会更新,即Discard Candy不会重新启用.
但是,如果我点击GUI中的任何位置,例如在窗口或标题栏上,则会立即启用Discard Candy按钮.所以逻辑是有效的,但事情正在发生,我只是不明白.有人可以向我解释一下这种行为吗？
编辑 - 到目前为止,它听起来像CommandManager.InvalidateRequerySuggested没有帮助人.我打算试一试,但此刻我有点担心.我确实按照推荐的链接,这样做决定阅读更多有关MVVM光工具包的信息.这听起来很不错 - 有没有人在这里使用它并且能够确认它没有表现出我到目前为止看到的问题？虽然我计划在下一个主要版本中尝试MVVM轻型工具包.我的应用程序,我不想重做我目前所有的命令,这就是为什么我可能会开始使用CommandManager.InvalidateRequerySuggested,所以我们都可以在这里得到另一个关于它的用处的数据点.
编辑#2 - 非常有趣,MVVM light工具包实际上依赖于CommandManager.InvalidateRequerySuggested以支持UI禁用/重新启用命令的能力.作者说:
"严格地说,在WPF中,如果你的命令绑定到CommandManager监视的控件,你不必自己引发CanExecuteChanged事件.你可以让CommandManager处理这种情况.也就是说,外部事件可能还可以改变UI的状态.假设UI应该从上午9点到下午5点启用,然后在晚上禁用.用户没有触发UI,所以代码应该(礼貌地)请求CommandManager重新查询状态命令.这是通过调用InvalidateRequerySuggested CommandManager上的方法实现的.正如你猜到了,RelayCommand类的方法RaiseCanExecuteChanged做到了这一点. "