All Stories

今天进度不错

今天进度不错

  花了近半天时间,把about对话框弄完了,不过有点小问题,不能设置tab页的title。整天琐事很多,最近把崩溃问题解决方案稍微整理了一下,说实在的,我心里是没底的,这个任务对我来说似乎要求高了些。我也希望程序能7×24小时地运行不中断,可是无论怎么弄,稍有点复杂的功能肯定就埋藏了大量的bug。

要被Excel整死了

要被Excel整死了

  今天发现原来我的机器上一直跑得好好的程序,到其他机器上就不行了。于是另外找了个装了Win2003和MS Office2003的机器上调试,发现首先我用了一个Excel2003中不存在的接口,Excel2007中是有的。于是绕了个圈子也勉强达到原来的目的了。  接着发现把图表copy到系统剪切板中再取出来存成图片的文件不行了,根本枚举不到GIF类型的剪切数据。在网上找了个剪切板观察工具,发现确实没有那个数据,不是程序的问题,原来Excel2003的接口功能就是要比Excel2007弱。于是绕了好远的路,换个接口,把图表当成图片copy到剪切板中,发现剪切板中有Meta file picture类型的数据,再用Win32 API把这数据保存成文件。很扯的是这文件不知道是不是需要什么句柄释放操作,反正直接是不能修改或删除的,不过还好能复制。接着用GDI+把这个wmf文件转换成jpg或gif。结果郁闷地发现,转换后的图表背景变成全黑的了,想了好多办法,转来转去都是黑的,只有wmf和png看起来是白的。其实大概是透明的,整了好久都没办法,下班的时候跟老雷说起这个事情,老雷说先设置一下背景色。我真想拍一下自己的脑袋,怎么就没想到这点呢!  明天再去弄了。

VC操作Excel生成统计图

VC操作Excel生成统计图

  老雷说,画图功能可以让Excel来做,我曾经还抱着试试看的心理在网上找有没有免费的代码可以方便地生成各种柱状图、饼图的,没找到,也实现懒得自己去画了,于是硬着头皮去用Excel了。  VC的程序操作Excel,而且不光是为了存取数据,所以用COM是最正规最有效最理想的方法。如果是用MFC,可以让IDE自动生成其中的某几个接口的封装类,这样的好处是封装得比较高层,使用起来更方便简单一点。如果直接导入类型库,会生成整个类型库内所有的接口和类型的封装,不过是底层一点,最多是用一下COM智能指针封装的接口,可以少处理一些引用计数的问题。  先可以录一个宏,查看VBA代码,就基本知道要用哪些接口的哪些方法了,但实际上如果用VC通过COM来操作,会发现跟VBA的结果经常有些出入。这让我有点纳闷。不过今天整了一天,总算勉强完成任务了。

插件开发环境

插件开发环境

  想起插件的事,如果一个软件具备插件扩展能力,同时又希望其用户自行开发插件,那么这个软件一般说来需要提供一个良好的插件开发环境。纵观Eclipse,MSVS、MS Office等都是这样的,而且VS和Office中的扩展形式除了插件,还有宏,准确地说来,是开发宏的环境是随软件一起提供的,而插件的开发是要用其他工具的,比如VS。而我前面说的插件开发环境,其实对应的是宏开发环境。  这个开发环境简单的做法,应该是一个独立的程序,但与软件主程序之间有很深入的进程间通信,不然调试功能是不可能那么完善的。也有可能是还有一个中间的宏解释执行器,主程序和宏开发环境都是只与宏解释执行器进行通信,同时该解释执行器也有调试功能。这样做的一个明显的理由是,当调试宏时,主程序可能会被挂起,而这时调试界面则要求是活动的,所以放在主程序中是不容易处理的。  Eclipse可能不需要这么做,它也许可以在不同的实例中使用不同的配置,这样可以在一个实例中调试另一个实例。  还有一种比较极端或者不负责任的做法是,不提供开发环境,让插件开发者痛苦去吧。也许用比较高级的脚本语言来做为扩展架构的底层执行器,这个问题的影响会变小,因为脚本语言对调试的需求可能会小于像C++这种编译型语言。但我觉得无论怎么样,提供一点基本的用于调试的设施还是必要的,比如至少可以加入一种打印输出机制之类的。

google test和google mock

google test和google mock

  今天在公司里看到google test和google mock,又好奇心起,看了看,觉得比起CppUnit来真的简洁不少,而且CppUnit没有一个好用的用于插桩的框架,那Mockpp和Mockcpp都有很明显的很影响使用的这样那样的限制和缺点,而google提供的这两个框架则比较好地解决了这些问题。  回到家又上网下载gtest试试,它有msvc的解决方案文件,也有GNU make的makefile。不过msvc倒是能直接编译通过,而MinGW则是不行的,要改些地方。首先要将MINGW的识别宏添加到GTEST_OS_WINDOWS宏定义中,然后在几处使用了SEH的地方,__try/__except都是VC才用的东西的,只要再在编译开关处把MINGW去掉。这样gtest库是可以编译通过了,不过有一个自测试文件gtest_unitest.cc却还是有问题,要加个文件头包含limits.h,这样就可以全部编译通过了。  又顺带看了一下googlemock,它依赖于tr1。在公司里,我什么都没修改,直接用VS2008编译过了,在家里却不行,总是报VC的xtr1common文件中的什么tr1没开启。上网找了下解决方法,加入boost就行了,不过我试了发现从trunk中取到的boost不知为什么不行,最后还是从googlemock的官方网站上下载到一个他们从boost 1.36.0中提取出来的tr1中tuple部分,这样在编译包含路径中添加boost和tr1的路径,就可以编译过了。但它在源代码中明确限制了只能使用VS2005或更高版本来编译,看来要用在MinGW中是有点困难了。

可以用bjam做点事了

可以用bjam做点事了

  今天把一个用了wxWidgets、Xerces-C++、luabind的工程用bjam写了个构建脚本,可以用MinGW来编译,也可以用VC来编译,这就是bjam的好处,很少需要关心不同编译器的命令行参数。  经过这次实践,还发现alternative的选择原来是要跟它的属性完全对应上才行。比如一个目标,写了toolset和variant以及threading,则在命令行中要把这三个全都设置上,不然它就说找不到匹配的目标。这让我有点头痛,假如我只想在命令行上选择toolset,而让其他两个属性固定死,那怎么办。  不过还算可以了,目前基本能满足实际需求了。

继续bjam

继续bjam

  bjam编译Windows下的rc文件不用特别指定,就像其他C/C++代码文件一样,直接放个文件名就行了,它能自动认出来,并调用相应的资源编译器来,只不过生成的二进制文件后缀还是跟代码文件编译出来的一样,不过并不影响最后的链接过程。  对于debug或release下使用不同配置的情况,需要至少每一种情况写一遍目标,同样如果是不同的toolset也这么处理。  今天把一个使用WTL写的工程用bjam系统编译了一把,果然也不是很麻烦,不过需要写不少特定的参数,bjam的默认配置不够用了,所以这样的情况还是不适合用bjam的。简单地说来,适合用bjam的场合,至少是没有一个好用的IDE的情况下。  想起直接在bjam里用wx-config来生成的编译选项,居然会出错,因为wx-config的输出后面多了个回车,用make就没影响,而链接选项在bjam中也没影响。没办法,去网上找到wx-config的源代码,只有一个文件,不过有几千行,稍微找了一下输出的代码,把末尾的回车换行去掉,再试了下,果然可以了。

bjam使用点滴

bjam使用点滴

  要在工程的根目录下放一个Jamroot文件,可以没有扩展名,也可以加.jam为扩展名,这样其他子目录下的可以命名为Jamfile了。  基本上是个大小写敏感的系统。  还没找到怎么让它来自己编译Windows的资源文件。  用path.glob-tree可以指定目录来进行glob-tree,如果光用glob-tree,是只能从当前Jamfile所在目录开始全部搜索的。

bjam有点意思

bjam有点意思

  在编译Luabind成独立的库时,顺便学了一下bjam。bjam在某些场合下挺有用的,如果之前用的是make,再来用bjam,感觉就是用过汇编之后来用高级脚本语言。  折腾了一阵子后,我的感觉就是bjam几乎是完全给boost设计的。其中最突出的特点是,编译器无关。它在这方面做不了少工作,只要指定一个toolset,它就能自动查找编译器所在的路径,而且不用关心编译命令行,因为大部分常用的选项它都提供自己的抽象方式来表达。还有就是它似乎有良好的可扩展性,在boost的源代码目录下有几bjam的工作目录,下面有几个子目录,里面分别存放着一些jam文件,在写jamfile时,可以import模块进来用。  我捣鼓了一阵,把自己一个工程,里面有几十个C++源文件,从GNU make转成了bjam工程。感觉有点新鲜,但总的说来,它应该是适用于这样的场合:工程是可移植的,即要跨操作系统,跨编译器。