解决工作中遇到的一个"打开,保存"文件框的bug的过程
我们来看下故事的发生过程,QA同学发现我们存在如下的bug
看到如此多的串,可以认为这个是典型的溢出问题。后来我咨询解决该问题的同学,他说这个bug在debug模式下不会出现,只有在release下才会出现(这个意味着,该问题很有可能是内存问题引起的,因为debug和release的一个很大的区别就是内存初始化和布局)。解决方案就是在筛选器后面加个\0。
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\0";
问题的确是解决了,但是我觉得微软设计接口也不至于如此弱吧。这样的奇葩的写法不应该是接口设计的规范。于是我研究了下为什么要加\0。我们看下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(\0)结束。假如不是很熟悉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\0*.png\0。
可以想象下windows对这个串的处理:
- Search第一个\0,找到“显示字符串”
- 从前一个\0开始搜索第一个\0,寻找到“匹配规则串”
- 从前一个\0开始搜索第一个\0,如果位置和前一个\0不相邻,则走到1;否则结束搜索
这儿再多说两句,我们看下mspaint的保存框
这种组合的正确写法是
m_ofn.lpstrFilter = L"单色位图(*.bmp;*.dib)\0*.bmp;*.dib\0\t16色位图(*.bmp;*.dib)\0*.bmp;*.dib\0\r256色位图(*.bmp;*.dib)\0*.bmp;*.dib\0\r24位位图(*.bmp;*.dib)\0*.bmp;*.dib\0JPEG(*.jpg;*.jpeg;*.jpe;*.jfif)\0*.jpg;*.jpeg;*.jpe;*.jfif\0GIF(*.gif)\0*.gif\0TIFF(*.tif;*.tiff)\0*.tif;*.tiff\0PNG(*.png)\0*.png\0";
上一篇: Java多线程1.8.多线程程序练习
下一篇: 工作中微信小程序我遇到的问题和总结