工作中遇到的这个问题还是很有意思的。其中嵌套了很多奇葩性的问题。 (转载请指明出于breaksoftware的csdn博客)
我们来看下故事的发生过程,QA同学发现我们存在如下的bug
看到如此多的串,可以认为这个是典型的溢出问题。后来我咨询解决该问题的同学,他说这个bug在debug模式下不会出现,只有在release下才会出现(这个意味着,该问题很有可能是内存问题引起的,因为debug和release的一个很大的区别就是内存初始化和布局)。解决方案就是在筛选器后面加个 。
OPENFILENAME m_ofn; ::ZeroMemory(&m_ofn, sizeof(m_ofn)); m_ofn.lStructSize = sizeof(m_ofn); m_ofn.hwndOwner = m_hwnd; m_ofn.lpstrFilter = L"png|*.png ";
问题的确是解决了,但是我觉得微软设计接口也不至于如此弱吧。这样的奇葩的写法不应该是接口设计的规范。于是我研究了下为什么要加 。
我们看下
http://msdn.microsoft.com/en-us/library/ms646839(VS.85).aspx,它记录了OPENFILENAME结构体的说明,其中对lpstrFilter的说明有如下内容
lpstrFilter Type: LPCTSTR A buffer containing pairs of null-terminated filter strings. The last string in the buffer must be terminated by two NULL characters.
其中特别说明了,这个串的最后要以两个NULL( )结束。假如不是很熟悉windows设计的同学,可能此时已经感叹微软真的有这样奇葩的设计了。
但是,真实的问题却是我们没有关注到的:这样的写Filter是正确的么?(需要转换下思维了)通过Filter这个名字,我们可以猜想到,这个是选择器,让我们的文件“打开,保存”框只筛选出符合我们规则的文件。我们看下画板程序的文件打开框的选择
此时我们选择的是jpeg格式,则显示了所有后缀为jpg的文件。如果我们选择png格式,则只显示后缀为png的文件。如下图
而用我们的代码打开的是
这可以见得,我们的筛选器失效了。这也意味着,我们的筛选器写法是有问题。找到这个问题,就离我们找到为什么lpstrFilter要以两个NULL结尾的问题不远了。
其实我们仔细看下MSDN的说明。可以知道lpstrFilter保存的是若干个“字符串对”(A buffer containing pairs of null-terminated filter strings.)。这种设计思想,在windows上很多的,比如可以看http://blog.csdn.net/breaksoftware/article/details/3914358这篇文章中介绍的PendingFileRenameOperations注册表项,其记录的数据也是若干个“字符串对”。lpstrFilter中的每个“字符串对”,第一个字符串保存的是用于在框的“保存类型”中显示的文字,比如png;二个字符串保存的是“筛选规则”(不会显示出来,供窗口筛选用),比如*.png。而我们的窗口中显示的是png|*.png。此时似乎我们懂了点什么……这个就是我们写错了!我猜测这段代码的作者,也是希望做成有筛选功能的,否则也不用指定这个字段。但是他可能认为“|”是分隔符。于是便有了
png | *.png
(显示名) (分隔符) (筛选器)
话说
这样的显示也忒不协调了!
正确的写法是png *.png 。
可以想象下windows对这个串的处理:
- Search第一个 ,找到“显示字符串”
- 从前一个 开始搜索第一个 ,寻找到“匹配规则串”
- 从前一个 开始搜索第一个 ,如果位置和前一个 不相邻,则走到1;否则结束搜索
这个流程就解释了为什么我们需要以两个连续的NULL结尾。
这儿再多说两句,我们看下mspaint的保存框
这种组合的正确写法是
m_ofn.lpstrFilter = L"单色位图(*.bmp;*.dib) *.bmp;*.dib 16色位图(*.bmp;*.dib) *.bmp;*.dib 256色位图(*.bmp;*.dib) *.bmp;*.dib 24位位图(*.bmp;*.dib) *.bmp;*.dib JPEG(*.jpg;*.jpeg;*.jpe;*.jfif) *.jpg;*.jpeg;*.jpe;*.jfif GIF(*.gif) *.gif TIFF(*.tif;*.tiff) *.tif;*.tiff PNG(*.png) *.png ";