再谈 CFileDialog 对话框的定制
编译/NothTibet
原文出处:MSDN Magazine C++ Q&A
下载源代码
在《在线杂志》第十四期里,有一篇文章题为:“一个定制CFileDialog对话框的实例”,此文示范了如何定制“打开”文件对话框,通过调用 GetItemText 函数直接从列表中获得选中的文件名, 有心的读者肯定会留意,在这篇文章的最后作者留下一个不大不小的尾巴:
“....其实,在程序中有个致命的问题——如果用户定制了资源管理器来隐藏已知文件类型的扩展名。那么,.txt就不会出现在列表框中。也就是说CFileDlgHelper::GetItemName 返回 foo,而不是foo.txt。实际上,如果扩展名被隐藏,那么象 foo.txt、foo.jpg 和 foo.doc 等等这样的文件都以名字foo出现(试一下就知道了)。如此一来,怎么知道这个 foo 文件到底是此 foo,还是彼 foo 呢?问题真是解决不完啊,搞掂这个问题,又出那个问题。唉,好累啊,下次再说吧......”很多人都在翘首企盼这个“下次再说吧......”究竟会如何?本文且让我将这个尾巴割掉,从而彻底解决遗留的问题。同时也解除大家心头的牵挂。
其实,解决方法很简单,之所以当时没有揭穿,主要是因为它涉及到一个未公开的秘密,而这个秘密我未曾通过微软公司的大老们确认。在前述文章中,我创建了一个类,这个类名叫 CFileDlgHelper,它提供了诸多方便的函数来处理文件 打开对话框。其中有一个函数是 CFileDlgHelper::GetListCtrl,用它可以获得含有特定文件名的列表控制,用 GetItemName 来从列表控制中获取条目名称。正如大家所见到的,GetItemName (它调用 CListCtrl::GetItemText)是有瑕疵的,也就是说,如果你在资源管理器的选项设置中隐藏已知类型的扩展名,那么该函数返回的串不包括扩展名。这样就没办法区分 bugs.txt 和 bugs.bmp,因为 GetItemName 的返回值都是 bugs。
那么,这个微软在“打开”文件对话框中未公开的秘密到底是什么呢?它就是CListCtrl::GetItemData 返回的列表项的数据,一个 DWORD 类型的值,它实际上是该列表项的 PIDL。这个 PIDL 是 Windows 外壳中的东西,它唯一标识一个外壳对象,象文件、文件夹、链接、磁盘驱动器或者是象“我的文档”这样的伪对象。对于一般普通文件,PIDL 是用宽字符表示的文件相对路径名。
一旦你了解了项目数据就是其PIDL,那么要获得它的路径名就很轻松。只不过要懂一点讨厌的外壳编程。首先,向对话框发送一个 CDM_GETFOLDERIDLIST 消息以便获得当前文件夹的 PIDL。它包括两个步骤:1、用空(NULL)缓冲发送一次 CDM_GETFOLDERIDLIST 获取路径长度,分配实际缓冲后再发送一次 CDM_GETFOLDERIDLIST;2、必须组合文件夹的 PIDL (路径名)和数据项的 PIDL(即相对路径名)来获取完整的 PIDL (全路径名)。为此,你必须获得文件夹的 IShellFolder 接口并用神奇的 SHGDN_FORPARSING 标志调用 IShellFolder::GetDisplayNameOf,以次获取全路径名,包括扩展名。
为了减轻大家的劳动,我添加了一个新函数 CFileDlgHelper::GetItemPathName,用它可以轻松获取想要的物理路径名。这个函数的使用方法如下:
CString path = m_dlgHelper.GetItemPathName(i);
图一 修改后的程序运行画面
就这么简单,CFileDlgHelper::GetItemPathName 是调用 CFileDlgHelper::GetDisplayNameOf 的打包函数,几经重载。图一是修改后的程序运行时显示选中文件的完整物理路径名。具体实现细节请参考源代码。