[经验总结]解决MFC 进度条无响应的问题

 

近两天在一个MFC程序里实现导入数据功能，导入过程免不了刷新进度条，但随之发现数据量过大时，进程条无响应，于是上网搜索各种奇技淫巧，都不得法。最后，回到这个MFC工程，在VS工具中全局搜索进度条工具终于找到解决方法，实际上远没有网上流传的方法那么复杂，仅仅五行代码把这个问题搞定：

while(PeekMessage(&msg,NULL,0,0,PM_REMOVE))

{

TranslateMessage(&msg);

DispatchMessage(&msg);

}

/////////////////////////////////////////////////////////////////////////////////////////////

上述代码为什么可以解决这个问题？ 看了这篇文章（深入探讨MFC消息循环和消息泵））就知道了。

 

  今天 (10/08/01) 又在经典书籍＜Windows程序设计＞第三章结尾处看到这样一段话，这段话很好的解释了进度条无响应的问题：

Windows 98和Windows NT都是优先权式的多任务环境。这意味着当一个程序在进行一项长时间工作时,Windows可以允许使用者将控制切换到另一个程序中。这是一件好事,也是现在的Windows优越于以前16位Windows的地方。然而,由于Windows设计的方式,这种优先权式多任务并不总是以您希望的样子工作。例如,假设您的程序花费一分钟左右来处理某一个消息。是的,使用者可以将控制切换到另一个程序,但是却无法对您的程序进行任何动作。使用者无法移动您的程序窗口、缩放它、最小化、关闭它、什么都不能做。这是因为您的窗口消息处理程序正忙于进行一项长时间的作业。表面上并不是窗口消息处理程序在执行它自己的移动和缩放操作,但实际上确实是它在做。这就是DefWindowProc部分的工作,它必须被考虑为您的窗口消息处理程序的一部分。

10/08/07 补记:  今天终于拿到一套二手的＜Windows程序设计＞ ，里头第二十章，20.4.1 BIGJOB1程序 讲述一种解决大作业任务的通用方法。

解决这个问题固然很好，但更重要的是发掘解决问题的方式，这个问题的解决方式给我以下两个启示：

1 互联网的内容或者观点可能大部分是不正确的，网络以讹传讹的速度甚于纸媒和口耳相传。

2 最有效率的解决问题方式还是应该遵循“就近原则”，看看手里的工程是怎么解决同类问题、问身边的同事，这样往往比问互联网的效率高。