All Stories

图形程序设计与实现

  这周开始投入环境组网绘图功能的Demo实现。说简单点,这就是一个图形编辑器,就像Visio之类的。以前也有过自己使用GDI画图形的经历,但那时更简单的一点,没有要求图形可以移动,所以实现时做的事更少些。虽然这次说是做Demo,但我为了以后能以这Demo为基础,继续实际项目的完全实现,在初期就做了不少事情,费了好些心思。  首先是程序架构上,基本上是按照实际项目的设计来做的,以后也不用做大的修改和调整。界面上会有的元素,都留出位置了。花了近2天的时候,才把主界面的框架搭好。昨天又花了1天,把输入的数据源那部分功能也差不多完成了。今天才开始实现真正的绘图功能。  这次Demo主要就是为了预研或显示绘图功能,所以这里需要投入的精力更多。项目使用MFC开发,不使用任何其他第三方的库,传统而显而易见的作法是在CView上进行绘制。本着尽量OO的原则,最先可以想到的是,每种图形元素,可以用一个独立的类来表示,而所有这些类,有一个公共的基类,在基类中声明接口。以前的设计中,我只是让每种图形类保存了各自的位置和类型信息,并实现一个绘图接口。这次我突然发现,如果把相应的响应用户操作也放到各个图形类中实现,才更合理。比如点住鼠标进行移动,这得让图形类自己决定自己该进行什么动作,像一般的矩形,就可以直接将整个矩形进行移动,像折线,则可能只是在中间的折点进行移动。于是一般说来,这些图形类应该能处理鼠标的按键按下,弹起,光标移动等事件。现在觉得这样的设计是理所当然的,可在以前,我是绝对想不到这点的,也确实曾经把这些操作都放到外面统一分类处理。而且自从知道了Loki::Factory这个模板类后,对于这种大批类的操作,我有种近乎执着的热情想让它们不被任何除了这工厂之外的其他模块知道,直至不知道它们的存在。有了这一批图形类后,就需要一个管理器来维护这些图形类实例化出来的对象。这个管理器完全将这些图形类实例的创建、销毁、任务分派等与界面(CView)隔离开来。对于界面来说,图形对象管理器可以完成所有功能。  再说代码实现方面。这次专门看了一遍GDI+的SDK,准备试用一番,嗯,不算试用,是实际用上了。MFC中使用GDI+没有任何限制,在CView的OnDraw方法中把所有图形绘制一遍即可。当然也有双缓冲以免闪烁。网上的用GDI+实现双缓冲的文章和代码都很多,但一般说来只分两种:1、标准的GDI+做法,临时创建一个Gdiplus::Bitmap,将所有内容都画到这个Bitmap上,再将这个Bitmap画到设备上去;2、GDI风格的做法,先创建一个内存DC,GDI+都向这个内存DC画内容,最后将这内存DC都BitBlt到设备上。经过我的实验,发现第1种方法的资源消耗比较大,速度感觉上似乎也慢一点,但没具体测过,没实际数据来证明。于是我换用第2种做法,网上有一个很流行的CMemDC类,使用非常方便。但等我这样实现完后,发现移动某个图形时,需要刷新整个绘图区,还是会闪烁。上网随便搜索一下,发现一个很简单的解决办法:处理WM_ERASEBKGND消息,直接返回TRUE就可以了。

初步了解google-breakpad

  第一次知道google-breakpad这个东西,是一篇讲chrome使用的开源库的文章,当时也只是一带而过,心想这功能也能做成多平台的?  最近还是因为项目的需要,原本已经有一个这种实现的,是从FileZilla的2.x版本中抠出来的,不过有些时候会生成不了dump,让人觉得诧异,还有一些是生成了dump,但最后发现栈回调的信息太缺乏可参考的价值了。我估摸着,这可能跟如何使用dbghelp.dll里的函数的方式有关系,而这google-breakpad在我看来可能是当前功能实现得最好的一个了,就打算好好了解一下。  从svn里取得到的代码,解决方案是用于VC2005的,大概google内部VC都是用的2005吧,看到好些它的开源项目都是。直接用VC2008打开,自动转换版本后,也可以直接编译。主要看src\client\windows\目录下的代码就可以了,一般而言可以用到的有3个lib文件,分别是crash_generation.lib、exception_handler.lib、crash_report_sender.lib。如果用户程序只是为了能生成minidump,直接链接exception_handler.lib就可以了,crash_generation.lib已经被它包含了,而crash_report_sender.lib顾名思义是可以将文件发送到某个地方的,从代码上看,是通过http的上传功能来实现的,不过还没研究。另外还有一个GUI的演示程序,crash_generation_app.exe,可以测试除0异常,CRT函数参数无效异常以及纯虚函数调用异常。  通过阅读crash_generation_app.exe的代码可以大体上了解google-breakpad的使用方法。google-breakpad将这么一个小功能分成几部分来实现,首先,它分为服务器和客户端两部分,这两部分都可以生成minidump,但应用场景不同。用户程序出现未处理异常时,被ExceptionHandler捕获到,该模块会根据当前进程是否已连接到一个服务器,来决定由谁来生成minidump。在crash_generation_app.exe中默认是会去连接一个服务器的,所以如果服务器没有问题,则是由服务器来生成minidump的。而且服务器生成minidump不限于当前进程,它通过Event得到客户端的dump请求,通过管道进行其他数据的传递。使用C/S结构的好处是,可以尽量减少对被dump进程的影响,代价则是大大增加了代码实现的复杂性。如果没有可连接的服务器,客户端也可自己生成minidump,这部分的实现上网上的所有有关这个主题的代码,基本上都是相同的。唯一有点区别的是,网上其他的代码一般只接管了未处理异常,而google-breakpad则还可以接管CRT函数无效参数异常和纯虚函数调用异常。  在crash_generation_app.exe的实现中,使用服务器dump的方式,最后返回的结果总是说没成功,而实际是dump文件是生成了的,这应该算是个bug吧。还有个问题是,如果一开始尝试连接到服务器后,后来服务器又被关掉了,那之后的dump会全都失败,这可能是因为演示的缘故,没有仔细编写这种异常流程的处理代码吧。另外,算是小瑕疵吧,用google-breakpad默认好像是不能自定义dump文件的名字,只能指定个保存路径,最后的文件名是随机生成的uuid。  总的说来,对于有这方面需求的应用,使用google-breakpad是个不错的选择,它做了不少工作。

MinGW中使用GDI+

  昨晚坚持到1点多,做了两件事:1、验证GDI+在MinGW中的使用;2、编译wxWidgets中access这个sample。  GDI+在MinGW中的使用,在网上有不少方法,但绝大多数是不行的,至少都有点小小的问题需要自己修改一下。我本来是没想过有这方面的需求的,也是因为最近想用用GDI+,就顺便想试试MinGW是否也可以。很快就搞定了,先到这里下载一个包含GDI+的头文件和库文件的包,然后把所有头文件解压出来放到MinGw的include目录下面,再把库文件放到MinGW的lib目录下面,其实我没用这个包里的libgdiplus.a文件,而是用reimp.exe重新生成了一个。网上有篇文章说,reimp.exe后面的参数是GDIPlus.dll,其实是错的,看一下reimp.exe自带的命令行参数说明就知道,人家明明是接受一个IMPLIB嘛,所以要跟GDIPlus.lib,之后会生成libgdiplus.a和gdiplus.def文件。这些文件准备好后,可以试着写个小程序编译一下,我就没自己写,直接试着用MinGW编译wxWidgets,带GDIPlus编译,中间会报两个错,错误提示很明显,只要打开那两个文件,把它报错的地方,定义类成员函数的签名的地方,不用加类名作用域就可以了。  编译access则花了我不少时间,因为其中不少时间是在等待wxWidgets库的编译。如果使用默认的编译选项,最后可能也可以得到一个可执行程序,但在运行时会弹出消息框说要定义一个什么wxUSE_ACCESSIBLITY之类的宏。这时可以修改一下access的makefile,在编译命令行中加入这个宏定义。再编译时,可能到最后一步是说某些符号链接找不到。我当时的第一反应是,编译wxWidgets时没有定义这个宏,于是修改src/msw/setup.h中的定义,将这个宏的值设为1,再编译,到最后也是说找不到一些符号链接,这才意识到是没有链接相应的库,还是修改makefile,加上-loleacc,给wxWidgets和access的makefile都要加,就可以正常编译过了,运行access也可以正常工作了。

昨晚遭遇小偷入室

  早上醒来,习惯性地找床头的iPhone看时间,居然没找到,很奇怪地起床,找挎包,心想昨天记得把手机拿出来了的啊,结果连挎包也不见了,越发奇怪,等到发现卧室门打开着,才开始有点焦虑,走到客厅一看,挎包被丢在靠近门口鞋架的旁边,里面的东西已经被翻过了,钱包里面大约有1千的现金已经不翼而飞了。这时我才确认,昨天晚上有贼入室了,这才稍微有点后怕,晚上有人进来我居然什么都不知道,万幸的是,只是丢了点钱和一个iPhone,至少连T43都没丢,T200也在,PSP,NDSL都在,连一起放在挎包里的Nano都还在,除了这些,人身也是没损失。  情绪理所当然地比较差,但也不知道到底是什么心情,没有恐惧,没有愤怒,没有后悔,没有惋惜,只想躺床上睡一觉。大约的损失总共是5000RMB,却没有一点心疼的感觉,对金钱的态度自己都觉得有点不可理喻。想要钱,却不在乎钱。  这该死的国家,该死的社会,我诅咒这个世界,却对那个小偷什么想法都没有,连骂几句,憎恨一下的念头一丁点儿都没有。  还是得靠自己,拥有了强大的力量,才能保护好自己和对自己来说重要的人或东西。

可以自动提交dump分析记录了

  今天花了近一天的时间,重新写了一遍自动分析mini dump然后将分析结果提交到wiki上的程序。通过这次实践,也确认了我原先的想法是可行的,内嵌一个IE,然后通过它暴露的COM接口,进行一些基本的操作,主要有遍历已有元素,填充TextArea,提交。只是发现这些操作,全都不是阻塞的,所以具体应用的时候还是得留心一下。  晚上加班,看了一下一个公司的人写的ppt,介绍Erlang的,看得让我觉得有点不舒服。按我的理解来看这ppt,似乎他的意思是公司目前使用C/C++来开发电信类软件,而且有那么多的问题,而Erlang从语言的机制上就提供了不少的保障机制,可以写出更快更稳的程序来。让我感觉他在鼓吹这就是银弹。就我以为,写这个ppt的目的就不明确,或者说就算明确了,也是动机不纯,我们应该立足于眼前,如何提高公司开发人员的设计和编码水平,而不是考虑着换一种语言就妄图可以解决一堆问题。  不过总的说来,我看了《Erlang程序设计》中的前面一两章后,就觉得这是我真的需要的一种东西,也许它在保证并发上,或者FP编码风格的处理上并不完美和彻底,但就目前看来,它应该是比较适合我的需求的一个选择。

原来一直都理解错了

  嗯,一直以来都以为UTF-8和Unicode是一类的,今天才明白过来,UTF-8确实明明是多字节一类的才对啊,我的理解能力实在是太差了,唉!  不过今天倒是也知道了,如果只是要在ANSI、Unicode、UTF-8之间进行转换,使用两个Win32 API就可以全部搞定了,不需要用什么iconv和ICU了。总是觉得微软做的东西易用性真的很好,通用软件产品很适合普通用户使用,而那些开发工具、库、API对于开发者来说,也很好用啊!  唉,我也就只用玩一下这些容易的东西了。

桌面时钟换肤

  看到搜狗输入法网站上有那么多皮肤,想到哪里可以利用一下。最后想到,桌面时钟啊,以前为了弄些皮肤来,还找了不少其他的桌面日历桌面时钟之类的小程 序,把它们的皮肤里的图片都抠出来,然后转换成自己的程序可以用的格式,还真花了不少时间。输入法的皮肤与桌面时钟的布局有些微差别,于是只好只用来显示 一下数字了,不能显示那种模拟钟面的了又花了近8个小时吧,其中还有不少代码是直接复制的。好在搜狗皮肤文件是用ZIP打包的,这比较方便,原先写的那块 解压缩的功能是调用7z实现的,那接口太繁复了,不好用,还自己特地写了个小小的dll来简化,但还是怎么看怎么觉得不爽。这次就索性全部改成zip的, 从codeproject上找了个解压zip的代码。  刚弄得可以显示出来的时候,发现显示的字体有点问题。首先是字体很小,其次是字体显示部 分是透明的,颜色不明显。字体小我倒不是很关心,但颜色不明显就比较严重了,属于不可控问题了。后来乱试了一下,偶然发现用GDI+来写字时,字体不要从 HDC那里获取,而要直接从字体名称和大小创建一个,这样就可以了,两个问题都一起解决了。  演示如下:

兴致缺缺

  又要开始做环境设计编辑器了,几乎是全部重新做过。这次的计划是自己画,可是现在的我却兴致缺缺,想当年,嗯,也就是一两年前吧,我是多么的希望可以自己动手专心地实现一个这种图形编辑器啊。  我现在的想做的是把自动分析崩溃报告的事情做好。不过这种事情收益有一些,不过却不是主要业务,因为对用户来说,没有多少良好的体验可以从中体现出来。唯一的好处是,开发人员可以减少工作量,嗯,这点上我倒是真有点典型的程序员风格——懒惰!

x和dt偶尔还是有些用处的

  事实证明,x和dt偶尔还是有些用处的,有几个core dump记录,经过分析后,嗯,是x或dt后,发现就是在倒数第二次或倒数第三次调用某个对象的方法时崩溃的,而崩溃的原因就是因为那个指向对象的指针其实是个0,只要调用的方法引用了什么成员变量,那么对不起,保证完成“死给你看”的任务。想来,在知道用x和dt前,那些问题我估计是分析不出什么结果来的。  今天,抱着试试看,用VC9重新全部编译了一下Scintilla,发现真可以用了。在这之前的几天里,偶然发现只要向Scintilla发送什么消息,应用程序就会崩溃,还以为是CVS里的代码有问题。  这软件的问题啊,真是个很缠人的事啊!