沒用的“取消”，少來

        從技術的角度說，這些取消之所以不起作用，原因可能有：

一、程序其實是單線程，并沒有設計成多線程，取消只是靠該線程的某個定時器查詢用戶的狀態。因為主代碼占用系統的資源實在太多，即使定時器有偵測到“取消”的觸發，但是能提供給其運行的時間片已微乎其微，自然發揮不了作用了。

二、程序的超時設定。比如鏈接到MSSQL SERVER，假如已設定TimeOut時間為120秒，那么，不把這兩分鐘的延時用完，用戶點不點擊取消按鈕，結果都一樣。微軟的客戶端，像“查詢分析器”等軟件都有這毛病。

三、有的操作，屬于事務處理，只準全部成功，否則就要完全恢復原狀。但是在操作已經進行了一大部分的情況下，要回轉到剛開始的情形，也是需要相當的時間的，因為也許要關照到的地方極多。

......

        所以從程序員的角度，我能理解“取消”命令“不作為”的難處。但是用戶他們不知道呀，他們就是覺得你的程序就是哄人，連個“取消”都要弄這么久，以致失去繼續用下去的信心。因此，不要小看一個小小的“取消”功能，針對上面的三種情況，在用戶點擊“取消”按鈕后，分別作出三種不同的提示：

一、協調主代碼和定時器代碼的關系。建議設置一個指示“是否取消”的Public變量。該變量由定時器設定，由主代碼讀取。尤其在主代碼的循環，或是某些耗時較久的語句前，要記超時得檢查該變量值。
二、可以把超時設定設置得小一些，分多次。比如，將120秒/次改為30秒/次。這樣做也有弊端，因為快的機器連服務器不到1秒的事情，在慢的機器上就要費時1分鐘。所以具體小到什么程度，還要依機器性能而定。
三、在用戶取消時，已經做了些什么，占全部應該做的百分比多少，程序是知道的。所以回轉的過程，就是把這百分比消除的過程。這是要向用戶提示“已取消 N %”，而非籠統的“正在取消，請稍候”。