我有一个必须在UI线程上运行的长时间运行方法.(Devex - gridView.CopyToClipboard())
我不需要UI在复制时响应,我添加了一个启动画面,这样用户就不会觉得无聊了.
当我运行这个程序时一切都很好.
当我运行一个不同的程序时,麻烦就开始了,而这个程序又启动了一个新进程并在其上运行程序.复制几秒后标题读取(Not Responding)并且鼠标光标显示忙,它当然会在几秒钟内清除但我想摆脱它,因为它给用户误解了程序的感觉是有缺陷的.
有没有办法设置我创建的流程的"超时"?
编辑:
主程序调用以下代码:
fillsProcess = new Process();
fillsProcess.StartInfo.FileName = Application.ExecutablePath;
fillsProcess.Start();
Run Code Online (Sandbox Code Playgroud)
在fillsProcess中,当单击某个按钮时,将调用以下代码:
gridViewToCopy.CopyToClipboard();
Run Code Online (Sandbox Code Playgroud)
这行代码需要一段时间来处理,几秒钟后,fillsProcess的窗口看起来没有响应,因为此方法在UI线程上运行.
编辑第二名:
显然(并且非常可以理解)
gridViewToCopy.CopyToClipboard();
Run Code Online (Sandbox Code Playgroud)
不是导致此问题的唯一方法.许多Devex方法必须在UI线程上运行(例如,数据排序,数据过滤)
所以感谢任何提供特定解决方案的人(无论是否有效),但我原来的问题再次突然出现:
有没有办法改变超时时间或以某种方式控制整个"无响应"的惨败?
在长期操作期间,我们的C++ Win32应用程序显示一个带有进程条的模态状态对话框,每隔几秒左右就会更新一次.从Windows 7开始,我们意识到Windows很快会显示一条消息"似乎挂起......"和/或在我们的窗口标题栏中附加"不响应".
我们发现进程对话框必须处理消息以避免这种情况.更具体地说,似乎Windows 7不断发送WM_UPDATE消息以检查我们的程序是否存活.我们以前在此对话框中禁用了所有不需要的消息处理,因为配置文件运行显示它们是一个主要的减速.
但是虽然我们认为已经修复了这个问题,但是用户再次报告了这些问题:Windows显示"似乎挂起......"和/或在我们的窗口标题栏中附加"不响应",尽管我们每隔几秒就会处理所有事件.
问题:
是否有关于Windows 7(或Windows Vista)中此行为更改的任何文档?我们还没有发现任何.我们还发现了许多其他消息传递行为的变化.
是否有可能从Windows禁用所有这样的"活着"检查?我们的应用程序非常活跃,流程可能需要很长时间.
编辑:更具体一点 - 我们每隔几秒钟才会调用消息泵PeekMessage/ TranslateMessage/ DispatchMessage.
由于这是一个相当古老的遗留程序,因此在不久的将来不可能使用单独的工作线程.我们当然会为新代码做到这一点.请注意,我的主要观点是这种行为肯定会在Windows Vista/Windows 7中发生变化.我还没有找到任何文档.
这条消息意味着什么,是否有一个API来"响应"Microsoft Windows状态查询?
我正在寻找技术答案.谢谢 :)