近兩天在乙個mfc程式裡實現匯入資料功能，匯入過程免不了重新整理進度條，但隨之發現資料量過大時，程序條無響應，於是上網搜尋各種奇技淫巧，都不得法。最後，回到這個mfc工程，在vs工具中全域性搜尋進度條工具終於找到解決方法，實際上遠沒有網上流傳的方法那麼複雜，僅僅五行**把這個問題搞定：
while
(peekmessage
( &msg,
null,
0, 0,pm_remove
) )
///
// 上述**為什麼可以解決這個問題？ 看了這篇文章（深入**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 最有效率的解決問題方式還是應該遵循「就近原則」，看看手裡的工程是怎麼解決同類問題、問身邊的同事，這樣往往比問網際網路的效率高。
MFC程式中進度條無響應的解決方案
前些天寫的mfc程式，每次程式執行後處理大任務時進度條都會出現無響應的情況，只有在處理結束時才會再次更新，並且是直接更新到進度條滿的狀態，十分不爽。今天再次執行mfc程式，實在不能忍受這種情況，在網上查詢資料，得出解決方案，十分容易。參考 msg msg while peekmessage msg,...
MFC控制項之進度條
這個是手工活，不多說。vs2008和vs2005可能沒有這個函式，需要手動新增，如果你不會新增，看看這裡吧。一般初始化就是設定控制項的範圍之類的。bool progressys oninitdialog void 例如本例是在按鈕新增的響應 void progressys onbnclickedbu...
MFC自繪進度條
1 在對話方塊上新增乙個進度條 新建乙個類cmyprogressctr，其基類為cprogressctrl 2 給進度條控 件新增基於 cmyprogressctr 類的變數 progress cpp view plain copy pragma once class cmyprogressctr ...