分类： C/C++
2008-08-04 09:29:25
void CMyOpenDlg::OnSelectAll()
{
CListCtrl* plc = m_dlghelper.GetListCtrl();
for (int i=0; iGetItemCount(); i ) {
CString fn = plc->GetItemText(i,0);
if (IsTextFileName(fn)) {
plc->SetItemState(i,LVIS_SELECTED,
LVIS_SELECTED);
}
}
plc->SetFocus();
}
当所选目录中没有.txt文件时，要disable“全部”按钮的处理稍微麻烦一些，要用到ON_UPDATE_COMMAND_UI消息。回顾一下MFC有关UI更新的基本方法，通常是在主消息循环处于空闲状态时候——也就是说在消息队列中没有待处理的消息。但对话框则有所不同，尤其是运行模式对话框时，MFC启动另外一个消息循环。当没有消息等待处理的时候，CWnd::DoModal向对话框发送一个WM_KICKIDLE消息。所以要想让对话框处理UI，常用的方式是这样的：
LRESULT CMyDialog::OnKickIdle(WPARAM wp, LPARAM lp)
{
UpdateDialogControls(this, TRUE);
return 0;
}
CWnd::UpdateDialogControls将神奇的CN_UPDATE_COMMAND_UI消息发送到对话框，触发ON_UPDATE_COMMAND_UI处理例程。可惜这个方法对CFileDialog对话框不灵。原因是CFileDialog重写了DoModal，它不会以正常方式运行某个消息循环，而是调用::GetOpenFileName （或::GetSaveFileName）。这些API函数都有自己消息循环，并且你无法钻进去进行消息空闲处理。无论什么时候，每当模式对话框处于等待消息状态时，对话框发送自己的WM_ENTERIDLE消息。从这里进去才可以处理UI更新事宜。但有几个细节需要注意。首先，Windows只发送WM_ENTERIDLE消息到对话框的所有者——此处为主框架——所以必须在那里捕获这个消息。然后，只要对话框仍然处于空闲状态，则Windows继续发送WM_ENTERIDLE，但只需要调用UpdateDialogControls一次，此间可以进行常规的标志设置。那到底什么时候设置标志呢？无论何时，UI状态的改变，都是在对话框获得到WM_COMMAND 或 WM_NOTIFY消息之后。所以还必须在CFileDialog派生的对话框中截获这些消息。
因为这些都是一些繁琐的细节，所以最好将它们封装到在一个新类中，这就是CFileDlgHelper的来由。只要从CFileDialog派生的对话框OnInitDialog函数中调用CFileDlgHelper的Init，便不用操心ON_UPDATE_COMMAND_UI的处理细节。CFileDlgHelper是如何实现的呢？告诉你吧，利用万能类CSubclassWnd，这个类可以用Windows的方式子类化任何窗口，通过在某个窗口过程之前安装一个新的窗口过程来实现消息的捕获。实际上，CFileDlgHelper 用了两个CSubclassWnds派生类：一个用来截获发送到对话框父窗口的WM_ENTERIDLE消息，另一个用来截获发送到对话框本身的WM_COMMAND 或 WM_NOTIFY。当主窗口得到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);
}
当对话框得到WM_NOTIFY 或者WM_COMMAND消息时，CFileDialogHook重置标志。
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; iGetItemCount(); i ) {
if (IsTextFileName(fdh.GetItemName(i))) {
pCmdUI->Enable(TRUE);
return;
}
}
pCmdUI->Enable(FALSE);
}
以上是用户需求的实现，下面来解决Window 2000环境测试出现的问题：如何确定在列表框中选择的是文件还是文件夹。
图一 Spy
你会发现列表控制实际上被包含在另一个窗口类SHELLDLL_DefView中。SHELLDLL_DefView窗口的ID为lst2，其项下的列表控制（SysListView32）的子ID为1。所以，为了要得到这个列表控制，可以这样编码：
// 在自己的CFileDialog 派生类中 CListCtrl* plc = (CListCtrl*)GetParent()->GetDlgItem(lst2)->GetDlgItem(1);记住，在定制CFileDialog时，它实际上是一个实际对话框的子对话框，这就是必须用GetParent的原因。更多的细节请参考MSDN中的相关文章。强制类型转换 CListCtrl* 与每一个常见的MFC诀窍一样，因为CListCtrl既没有数据成员也没有虚拟函数成员，它是一个纯粹的包装类（因为GetDlgItem返回一个临时的CWnd指针，而不是CListCtrl，每次碰到这种情况，常常都会让人感到沮丧，其实这很正常）。 一旦你有了列表控制的指针，便可以做任何想做事情——例如获取选中的路径名，调用CListCtrl::GetItemText并添加结果到当前打开的文件夹(GetFolderPath/CDM_GETFOLDERPATH)。有了路径名，如何知道它到底时文件还是文件夹呢？方法如下：
#include这里需要注意的是：不管怎样，如果路径名不是文件夹，你也不能因此就断定它就是一个文件！因为它还可能是其它的外壳对象，如"网上邻居"或者"我的电脑"之类的东西。 详细做法可以参考本文的例子程序 OpenFileDlg，它还示范了如何建立预览对话框。这个程序可以进行多项选择，如果只选中一个.txt文件，则预览窗格显示文件的开始几行。程序还带一个调试窗口，窗口中列出选中的条目，如果选中的是文件夹，则在它的旁边会有“FOLDER”说明。如图二所示。// 检查路径名是不是文件夹 static BOOL IsFolder(LPCTSTR pathname) { struct stat st; return stat(pathname, &st)==0 && (st.st_mode & _S_IFDIR); }
如果选中的是文件夹，则OpenFileDlg会清空预览格，这样就解决了本文所提出的预览问题。当然，如果运行环境是Windows XP，而非Windows 2000，那么就不会碰上这个问题！在Windows XP中，OnFileNameChange/CDN_SELCHANGE会返回正确的文件名和文件夹名字。但仍然可以用CFileDlgHelper类获取列表控制，选项名称等。并且仍然需要IsFolder来检查路径名是不是文件夹。
其实，在OnSelectAll处理代码中，IsTextFileName的功能是查找以.txt结尾文件名字。这个函数真的能实现这个功能吗？其实，在程序中有个致命的问题——如果用户定制了资源管理器来隐藏已知文件类型的扩展名。那么，.txt就不会出现在列表框中。也就是说CFileDlgHelper::GetItemName返回foo，而不是foo.txt。实际上，如果扩展名被隐藏，那么象foo.txt、foo.jpg和foo.doc等等这样的文件都以名字foo出现（试一下就知道了）。如此一来，怎么知道这个foo文件到底是此foo，还是彼foo呢？问题真是解决不完啊，搞掂这个问题，又出那个问题。唉，好累啊，下次再说吧......