再谈 CFileDialog 对话框的定制

下载本文示例代码
原文出处：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 的打包函数，几经重载。图一是修改后的程序运行时显示选中文件的完整物理路径名。具体实现细节请参考源代码。 下载本文示例代码

输入您的搜索字词 提交搜索表单