很多程序員都喜歡讓自己的代碼運行效果與眾不同。Windows系統(tǒng)的應(yīng)用程序打開某個文件一般使用的都是默認的CFileDialog。但是這個默認的CFileDialog往往滿足不了用戶的要求。我就碰到一個這樣的用戶，他的要求如下：

• 1、在默認的CFileDialog對話框中加一個預(yù)覽窗格，以便在選中ASCII文件時能看到所選文件的內(nèi)容，也就是用*.txt作為文件過濾條件。
• 2、在默認的CFileDialog對話框中加一個"全部"按鈕來選擇某個目錄中所有的.txt文件。
• 3、如果選擇的目錄中沒有.txt文件時，要將"全部"按鈕disable，也就是置灰這個按鈕。

   實現(xiàn)上面這些需求必須要改裝CFileDialog對話框。當(dāng)最后寫完程序時，功能到是全都實現(xiàn)了，但在Windows 2000環(huán)境測試中，用戶發(fā)現(xiàn)了這樣一個問題：如果先選中某個文件，然后再去選某個文件夾，預(yù)覽窗格仍然顯示的那個文件的內(nèi)容。盡管在OnFileNameChange中對CDN_SELCHANGE進行了處理，為了獲取所選的文件/路徑名，也調(diào)用了CFileDialog::GetPathName。但是即使是選中了文件夾，GetPathName仍然返回的是文件的名字。即便嘗試用其它的通知消息和函數(shù)，比如 CDN_FOLDERCHANGE 和 GetFileName，但仍舊存在同樣的問題。必須承認在Windows 2000中，CFileDialog是個不完美的對話框，確實存在上述問題。正是有這些不完美，程序員們才忙得個不亦樂乎......那么到底如何判斷用戶選中的是文件還是文件夾呢？下面就讓我們從用戶需求開始，一個一個解決所碰到的問題。
    首先簡單介紹下本文引入的三個輔助類：CFileDialogHook；CFileDialogOwnerHook和CFileDlgHelper，這三個類很簡單，其功能分別是：子類化文件對話框；子類化文件對話框的父窗口或宿主窗口，這兩個類只在CFileDlgHelper類中使用，一些重要的處理都在CFileDlgHelper中。它的使用方法很簡單，實例化CFileDlgHelper以后調(diào)用Init即可。

class CMyOpenDlg ... {
protected:
CFileDlgHelper m_dlghelper;//實例化
};
BOOL CMyOpenDlg::OnInitDialog()
{
m_dlghelper.Init(this)//初始化
……
}     

    初始化CFileDlgHelper以后，便可以用它來獲取列表控制以及判斷選項是否有文件夾屬性，例如：

CListCtrl* plc = m_dlghelper.GetListCtrl();
POSITION pos = plc->GetFirstSelectedItemPosition();
while (pos) {
int i = plc->GetNextSelectedItem(pos);
if (fdh.IsItemFolder(i)) {
// 顯示"(FOLDER)"……
} else {
// 顯示其它內(nèi)容
}
}

    毫無疑問，要改裝CFileDialog對話框，必須建立一個它的派生類以及一個新的對話框資源。“全部”按鈕的實現(xiàn)代碼是這樣的：

void CMyOpenDlg::OnSelectAll()
{
CListCtrl* plc = m_dlghelper.GetListCtrl();
for (int i=0; i<plc->GetItemCount(); i++) {
CString fn = plc->GetItemText(i,0);
if (IsTextFileName(fn)) {
plc->SetItemState(i,LVIS_SELECTED,
LVIS_SELECTED);
}
}
plc->SetFocus();
}

    當(dāng)所選目錄中沒有.txt文件時，要disable“全部”按鈕的處理稍微麻煩一些，要用到ON_UPDATE_COMMAND_UI消息。回顧一下MFC有關(guān)UI更新的基本方法，通常是在主消息循環(huán)處于空閑狀態(tài)時候——也就是說在消息隊列中沒有待處理的消息。但對話框則有所不同，尤其是運行模式對話框時，MFC啟動另外一個消息循環(huán)。當(dāng)沒有消息等待處理的時候，CWnd::DoModal向?qū)υ捒虬l(fā)送一個WM_KICKIDLE消息。所以要想讓對話框處理UI，常用的方式是這樣的：

LRESULT CMyDialog::OnKickIdle(WPARAM wp, LPARAM lp)
{
UpdateDialogControls(this, TRUE);
return 0;
}      

    CWnd::UpdateDialogControls將神奇的CN_UPDATE_COMMAND_UI消息發(fā)送到對話框，觸發(fā)ON_UPDATE_COMMAND_UI處理例程。可惜這個方法對CFileDialog對話框不靈。原因是CFileDialog重寫了DoModal，它不會以正常方式運行某個消息循環(huán)，而是調(diào)用::GetOpenFileName （或::GetSaveFileName）。這些API函數(shù)都有自己消息循環(huán)，并且你無法鉆進去進行消息空閑處理。無論什么時候，每當(dāng)模式對話框處于等待消息狀態(tài)時，對話框發(fā)送自己的WM_ENTERIDLE消息。從這里進去才可以處理UI更新事宜。但有幾個細節(jié)需要注意。首先，Windows只發(fā)送WM_ENTERIDLE消息到對話框的所有者——此處為主框架——所以必須在那里捕獲這個消息。然后，只要對話框仍然處于空閑狀態(tài)，則Windows繼續(xù)發(fā)送WM_ENTERIDLE，但只需要調(diào)用UpdateDialogControls一次，此間可以進行常規(guī)的標(biāo)志設(shè)置。那到底什么時候設(shè)置標(biāo)志呢？無論何時，UI狀態(tài)的改變，都是在對話框獲得到WM_COMMAND 或 WM_NOTIFY消息之后。所以還必須在CFileDialog派生的對話框中截獲這些消息。 因為這些都是一些繁瑣的細節(jié)，所以最好將它們封裝到在一個新類中，這就是CFileDlgHelper的來由。只要從CFileDialog派生的對話框OnInitDialog函數(shù)中調(diào)用CFileDlgHelper的Init，便不用操心ON_UPDATE_COMMAND_UI的處理細節(jié)。CFileDlgHelper是如何實現(xiàn)的呢？告訴你吧，利用萬能類CSubclassWnd，這個類可以用Windows的方式子類化任何窗口，通過在某個窗口過程之前安裝一個新的窗口過程來實現(xiàn)消息的捕獲。實際上，CFileDlgHelper 用了兩個CSubclassWnds派生類：一個用來截獲發(fā)送到對話框父窗口的WM_ENTERIDLE消息，另一個用來截獲發(fā)送到對話框本身的WM_COMMAND 或 WM_NOTIFY。當(dāng)主窗口得到WM_ENTERIDLE消息時，CFileDialogOwnerHook解釋它并更新對話框控制:

LRESULT CFileDialogOwnerHook::WindowProc(...)
{
if (msg==WM_ENTERIDLE) {
if (m_pHelper->m_bUpdateUI) {
m_pDlg->UpdateDialogControls(m_pDlg, FALSE);
m_pHelper->m_bUpdateUI=FALSE;
}
}
return CSubclassWnd::WindowProc(msg, wp, lp);
}

當(dāng)對話框得到WM_NOTIFY 或者WM_COMMAND消息時，CFileDialogHook重置標(biāo)志。

LRESULT CFileDialogHook::WindowProc(UINT msg, WPARAM wp, LPARAM lp)
{
if (msg==WM_COMMAND || msg==WM_NOTIFY) {
m_pHelper->m_bUpdateUI = TRUE;
}
return CSubclassWnd::WindowProc(msg, wp, lp);
}     

一旦知道了其中的奧秘，一切就這么簡單。注意從CSubclassWnd派生了兩個類——CFileDialogOwnerHook和CFileDialogHook，一個用來對付主框架，另一個用來對付對話框本身，它們都在隱含在CFileDlgHelper類中。有了它，“按鈕”的UI更新就會象你所期望的那樣：

void CMyOpenDlg::OnUpdateSelectAll(CCmdUI* pCmdUI)
{
CFileDlgHelper& fdh = m_dlghelper;
CListCtrl* plc = fdh.GetListCtrl();
for (int i=0; i<plc->GetItemCount(); i++) {
if (IsTextFileName(fdh.GetItemName(i))) {
pCmdUI->Enable(TRUE);
return;
}
}
pCmdUI->Enable(FALSE);
}      

   以上是用戶需求的實現(xiàn)，下面來解決Window 2000環(huán)境測試出現(xiàn)的問題：如何確定在列表框中選擇的是文件還是文件夾。
    要想解決這個問題，就必須關(guān)注對話框中的列表控制（ListCtrl/ListView），許多普通的對話框里的控制都有明確的IDs，如靜態(tài)文本控制有stc1，以及列表框有l(wèi)st1，這些符號都定義在文件中。你可以把列表控制看成是lst1，但用Spy++察看后，如圖一所示：

圖一 Spy++

你會發(fā)現(xiàn)列表控制實際上被包含在另一個窗口類SHELLDLL_DefView中。SHELLDLL_DefView窗口的ID為lst2，其項下的列表控制（SysListView32）的子ID為1。所以，為了要得到這個列表控制，可以這樣編碼：

// 在自己的CFileDialog 派生類中
CListCtrl* plc = (CListCtrl*)GetParent()->GetDlgItem(lst2)->GetDlgItem(1);      

    記住，在定制CFileDialog時，它實際上是一個實際對話框的子對話框，這就是必須用GetParent的原因。更多的細節(jié)請參考MSDN中的相關(guān)文章。強制類型轉(zhuǎn)換 CListCtrl* 與每一個常見的MFC訣竅一樣，因為CListCtrl既沒有數(shù)據(jù)成員也沒有虛擬函數(shù)成員，它是一個純粹的包裝類（因為GetDlgItem返回一個臨時的CWnd指針，而不是CListCtrl，每次碰到這種情況，常常都會讓人感到沮喪，其實這很正常）。 一旦你有了列表控制的指針，便可以做任何想做事情——例如獲取選中的路徑名，調(diào)用CListCtrl::GetItemText并添加結(jié)果到當(dāng)前打開的文件夾(GetFolderPath/CDM_GETFOLDERPATH)。有了路徑名，如何知道它到底時文件還是文件夾呢？方法如下：

#include 
// 檢查路徑名是不是文件夾
static BOOL IsFolder(LPCTSTR pathname)
{
struct stat st;
return stat(pathname, &st)==0 && (st.st_mode & _S_IFDIR);
}

    這里需要注意的是：不管怎樣，如果路徑名不是文件夾，你也不能因此就斷定它就是一個文件！因為它還可能是其它的外殼對象，如"網(wǎng)上鄰居"或者"我的電腦"之類的東西。 詳細做法可以參考本文的例子程序 OpenFileDlg，它還示范了如何建立預(yù)覽對話框。這個程序可以進行多項選擇，如果只選中一個.txt文件，則預(yù)覽窗格顯示文件的開始幾行。程序還帶一個調(diào)試窗口，窗口中列出選中的條目，如果選中的是文件夾，則在它的旁邊會有“FOLDER”說明。如圖二所示。


圖二運行中的OpenFileDlg

    如果選中的是文件夾，則OpenFileDlg會清空預(yù)覽格，這樣就解決了本文所提出的預(yù)覽問題。當(dāng)然，如果運行環(huán)境是Windows XP，而非Windows 2000，那么就不會碰上這個問題！在Windows XP中，OnFileNameChange/CDN_SELCHANGE會返回正確的文件名和文件夾名字。但仍然可以用CFileDlgHelper類獲取列表控制，選項名稱等。并且仍然需要IsFolder來檢查路徑名是不是文件夾。
    其實，在OnSelectAll處理代碼中，IsTextFileName的功能是查找以.txt結(jié)尾文件名字。這個函數(shù)真的能實現(xiàn)這個功能嗎？其實，在程序中有個致命的問題——如果用戶定制了資源管理器來隱藏已知文件類型的擴展名。那么，.txt就不會出現(xiàn)在列表框中。也就是說CFileDlgHelper::GetItemName返回foo，而不是foo.txt。實際上，如果擴展名被隱藏，那么象foo.txt、foo.jpg和foo.doc等等這樣的文件都以名字foo出現(xiàn)（試一下就知道了）。如此一來，怎么知道這個foo文件到底是此foo，還是彼foo呢？問題真是解決不完啊，搞掂這個問題，又出那個問題。唉，好累啊，下次再說吧......