All Stories

自定义保存文件对话框

  早就想在保存文件时,能让用户顺便多输入点信息了,于是自定义保存文件对话框的需求就提上来了。在网上搜了一遍,各种方法倒是不少,不过都跟我想像中的有点区别,我想在MFC中做,就希望能尽量的简单方便。于是就搁下了,直到前天,在公司里想起这件事,问了问同事,同事给我一个例子,VC6写的工程,看了觉得很简单,但是回家自己弄还是不行。昨天又跟同事交流了一下,再加上晚上在网上找资料,结合着弄,终于成功了。  首先,添加一个对话框资源,加上需要的各种控件,最重要的是要加一个ID为stc32的控件,可以是Static,至于大小、位置,可以之后慢慢调整,以及对话框的风格要加上WS_CHILD。  然后,给该对话框添加类,基类就选CDialog好了,生成代码后,把基类从CDialog改为CFileDialog,尤其要注意,CFileDialog的构造函数需要更多的参数。  再之后,要给m_ofn成员初始化一下,先是dwFlags要有OFN_ENABLETEMPLATE,再lpTempate要指定到刚才活到的对话框资源。  最后,就是看情况,重载几个虚函数,比如OnFileNameOk,OnFileNameChange等等。  搞定!

搞定phpBB的NT域账号认证登录

  当时看到phpBB后台有选项可以选择认证方式,有三种,分别是DB、Apache和LDAP,我就觉得要糟,老大知道后肯定会要求用NT域账号方式认证登录。  果然昨天下班后,老大就发了邮件,说最晚下周要搞定这个问题。我郁闷啊,其实我早就开始想办法去寻找解决办法了,当时直接切换到LDAP认证时,提示说LDAP扩展没有安装,而用Apache认证方式时,说什么账号名要一致云云。  到网上找了很久,也没有发现有价值的内容,倒是sf.net上有个for phpBB 2.x版本的mod,可以使得支持LDAP认证,不过我装的是3.0.2,而且下载下来那个mod,我都根本不知道即使我装的是2.x版本的,怎么应用上去,所以此路不通。  不过看到Apache认证方式,再结合项目组用VisualSVN Server搭建的SVN服务器,给我一点思路。我是可以通过Apache来实现NT域账号认证的,再让phpBB来使用Apache的认证结果。虽然思路是有了,但实际上,我根本不懂Apache的配置文件要怎么写,看了半天它的手册,也不知所云,只知道它是有mod可以支持ldap认证的。最后实在没办法,抱着试试看的心情在公司网上发了个帖子询问,终于有个人回复了,问他要了点例子参考,果然OK了!  基本搞定phpBB的NT域账号认证登录问题!

项目从VSS迁移到SVN

  今天开会的时候,不知怎么的,提到源代码管理的问题,直接就扯到要把源代码从VSS迁移到SVN。这是我之前几次考虑过的事情,不过当时的想法是,既然是迁移,就要把所有历史记录都迁移过去,费了好大的劲,最终还是没成功。当时的问题是,vss2svn并没有转换成功,后来想想继续用VSS也并没有多大影响,于是还是继续用。今天老大就说,历史记录丢了就丢了吧,反正VSS还在,到时候实在有必要的时候,还是可以看的。这样一想,也就霍然开朗了。会后立马动手,从VSS上Get latest整个目录,然后import到SVN上,基本没费什么力气。而且趁此机会,把方案、设计文档、帮助手册、会议纪要也都传了上去。然后绑定redmine上的版本库记录,不过有点问题,据同事说,不但需要svn的客户端程序,还需要重启系统,光是重启redmine服务是不行的,我大汗!  

新版本实现新需求

  今天继续昨天的工作,要能给流程也添加关联的文档和子流程,当时评审需求的时候,我还以为没多少工作量的,这两天做起来才发现,大大地错了,要做的事还是很多的,不过幸好当时也是怀着一点小心思,多报了点。  首先,数据库处理模块需要增加相应的接口,因此COM组件也同样需要加一下封装。然后,核心业务处理模块需要封装数据库处理模块的接口。最后是界面响应增加入口,而且界面响应有三处需要增加入口的。  有了添加关联,同时也就需要查询和删除功能,都需要做不少事情。而之前的代码写得也略微复杂了点,现在增加代码时,发现有不少需要重构的。自从读了《重构》后,把这种活动看作理所当然的,不知假如我没读过该书,仍然遇到这样的事情,会怎么处理呢?  后来偶然看了一下版本计划,发现这些需求竟然不是要求最近这个版本实现,而是再下一个版本,这下我就怵了,宝贵的时间就这么消耗掉了。于是马上掉头做另一个需求,要能实现关联超链接。这时,又发现一个UCD的问题,关联时,弹出太多对话框了,版本历史上最多的时候有3个对话框需要用户进行交互,现在已经减少为2个,但还是不爽,应该在1个对话框里把所有这些都搞定,于是再次重构!  没完!

很流很水账,银湖后山

  昨天又跑出去玩了,玩得太high了,一直到后半夜1点多才回到家,对于不久前的我来说,这简直是太让人难以置信了,我不是应该是个宅男么,不是很不喜欢跟人出去high的吗!但事实就摆在眼前,我跟着一群不熟悉,甚至不认识,很多还是第一次见面的人一起出去玩,而且玩得那么晚!  早上像平时上班一样的时间起床,收拾了一下便出门了,先坐317,到了市二医院转58路到武警医院,太早了!当时上了317我就想,这次应该会提前很多时间,果然,317坐了15分钟,58路坐了10分钟,总共半小时不到就到了集合地点了。本该9点才是出发的时间,结果8点10分就到了。  爬山,仍是主题。这次爬山路线就比较隐秘了,那些路应该都是之前爬山的人走出来的,并不像莲花山、梧桐山、南山这种有专门修过的登山道,而且更陡!不过相比那次爬梅林后山,速度要慢一些,而且这次我为了防止重蹈上次梅林后山的复辙,背了双肩包,装了3瓶共1800ml的佳得乐,1包摩卡蛋糕,1包萨其玛,6个桔子,尽量最后没有用上多少。  我们在差不多山顶的地方进食中饭的,我其实没吃自己带的这些东西,倒是吃了别人的一些枣,挺甜的。有3个mm还带了盒饭,式样全都一样,太可爱了。无聊时,杀人游戏是个老少咸宜的活动,但是和不熟悉的人玩,而且玩的规则也不是我喜欢和熟悉的那种,让我捉襟见肘,屡屡失误。  众人都有些疲乏,便不再爬山,直接下了山,快到山脚时,进入了一片高级住宅区,别墅区,里面的保安还不让我们借道,我们只好从外边再绕出去,搞得另一边的保安们也很紧张!下来了,就是银湖公园了,那里没什么玩的,于是众人商量了很久,走走停停商量着,最后决定到八卦岭去吃饭,如果有玩的就顺便玩一下。  结果是到了八卦一路的一家叫大骨仔的店,离吃饭的时间还早点,就几个人打麻将,几个人打拖拉机,然后吃饭。吃饭倒没什么值得讲的,跟所有下馆子吃饭都一样,喝点酒,吹下牛。  吃完饭,人就先散伙了一批,有人说要去洗脚,哈,这是我很喜欢的一种放松方式,就留下,点一下人,刚好4男4女,不过形象真的不好,全身汗臭,背个大包,着装也不整洁。进了一家叫一方山水的店,装修倒是还可以,不过技师水平不怎么样,而且收得也贵点,38一个人,不过有茶和奶茶喝,成本也是这么高上去的。  洗完脚,叫淡蓝色的mm硬是要叫人再去KTV玩,特别是威逼利诱群主,哈哈,开始群主还是很强硬的样子要回家,最后还是经不住淡蓝色的软磨硬泡,于是8个人再赶到华强北欢唱100,同样,装修不过,包间里还带卫生间。几个人唱起了歌,我就跟淡蓝色几个人玩起骰子,不过我玩不过她,郁闷,开始单玩的时候还好点,有个更差的人垫底,后来分组玩的时候,就惨了,不停地输,不停地喝,喝得我撑死了。  大概high了3个小时吧,终于决定回去了,毕竟第二天还有些人要上班的,包括我。打车回家时,我身上的现金已经不剩下多少了,还好是与人拼的走的,可以不用付这全程的价钱,回到家,1:14!

再次放弃升级工程到VS2005

  本以为今天闲一点了,可以干点其他事了,于是琢磨着把工程从VS2003升级到VS2005。升级的事,之前一直有想,但一直由于这样那样的原因而放弃了。这次又动了这样的想法,一方面是因为VS2005上才有Refactor!,另一方面是换了高版本的dot后,dot本身就带有8.0版本的crt dll,所以想着如果把7.1版本的crt dll换掉,感觉会舒服一点。  先看了看最基本的ACE和XTP有VS2005编译出来的lib和dll,然后开始升级工程。这次学聪明了点,不停靠VS2005自己的升级功能,而是直接自己编辑.sln和.vcproj文件。基本上只要把版本号改了,就可以了。为了回退方便,我先复制了各个.sln和.vcproj文件,并改名,然后才改版本号。再用VS2005打开,编译链接。这个过程倒没出多少问题,2005和2003最大的几点区别是,2005中对字符串操作的函数作了扩展,其次是manifest的引入。这都没有引起多少麻烦的事,只略作修改就可以了。  最后却因为另外一个没想到过的问题而促使我放弃了升级:编译太慢!真是没想到啊,也不知道是本来VS2005的编译器就比较慢,还是说这个编译器在遇到某些情况就会性能降低,比如使用了大量模板等等。反正最后我忍无可忍了,rebuild一次,就要好久好久,2003下明显要快得多,没多少犹豫,决定还是继续使用VS2003吧,顺便庆幸了一下,Impeller幸亏不是用VS2005编译的,不然会多花多时间啊!

夜登莲花山

  本来没打算去的,直到今天中午的时候还没想要去的,结果下午的时候偶然发现飘飘在QQ上,就聊起来,于是被她鼓动了。  下了班,匆匆去取了点钱,然后先坐车回家换衣服,飞快地再坐小巴到梅林关转车。结果给飘飘打电话,说还没出门,晕,于是我只好自己一个人先去了。爬上370,到北大医院下车,在附近转了转,没发现可以吃饭的地方,于是只好在莲花山公园入口处的书报亭买了包豆干来充饥。还没看到大部队,于是在门口随便吃了起来,几下就解决掉了。  过了没多久,看到阿金,于是走过去,倒是认出几个人来。爬山之前等了很久,因为有很多人一起来。  莲花山本来是很矮的,一小会儿就爬到顶了,所以估计也是出于这个考虑,我看领队的故意绕了好些路走,直到我出汗了,说起来今天还是很凉快的,而且结果我的那瓶脉动被飘飘解决掉了。  还是很快,就到了山顶,人山人海啊,我直到今天才知道,重阳节是要登高的,汗!人太多,只是拍了几张照片,便下来了。到中途吃水果,似乎是有吃西瓜的习惯的,连拍照的时候喊的都是“西瓜甜不甜”,呵呵。  吃完水果,因为时间、天气等原因,安排到公园门口集合,然后要吃饭的一起再去腐败。那一带我不熟,被他们带去一个湘菜馆,吃的当然是最普通的湘菜,当然吃什么不是最重要的,重要的是认识一些人,大家互相介绍一下,我还是第一次这么庆幸当然给自己取了这么一个特别的网名,哈哈!

升级dot

  今天偶然发现有一个图,dot会崩溃,换到2.20.x版本后,就没问题了,看来在适当的时候,升级是很有必要的。但是同时又引出一个新问题,高版本dot生成的svg格式,里面使用的坐标系比以前的复杂了,居然出现了科学计数法和负数,这让原来勉强能工作的格式化后活动框的定位又不行了。经过一番研究,发现在svg的开头有一个transform属性,该属性的值分成三部分,其中一部分是translate,经过试验发现,该translate的值加到下面的坐标系中的值,刚好能对应上以前使用的那种方式的坐标系统表示的值。于是乎,也就是说,又要多一步操作了。  升级到高版本的dot,同时也带来一个新问题,就是如果发布这个dot套装。反正我是不想在我的安装程序里面再执行一遍Graphviz的安装程序了,像Wireshark一样,感觉不是很舒服。之前的低版本(好像是2.05.x还是2.15.x)dot,很简单,一个exe文件,五六个dll就搞定了。而新版本的dot而远远不是,经过在一台没装过Graphviz的机器上实验发现,比较省事的一个办法是,复制dot.exe和所有同目录下的dll,一个config文件,一个msvcr80.dll和对应的manifest文件,以及Graphviz安装目录下的lib和etc目录下所有内容,大了不少啊!  今天又想了想,要是有个服务器端的话,有些事情可以容易得多。比如今天突然给了我一堆域账号,我要一个一个在MS SQL Server里先添加账号,再把账号添加到数据库中,很是麻烦,如果有了服务器端,就不需要这步了,最多自己维护一个自定义的很简单的列表;有了服务器端,可以通过服务器端对所有客户端进行广播,而现在的架构如果来做广播,似乎有些不伦不类;如果有了服务器端,就可以优化网络连接和数据传输,从而对系统响应的速度有所提升。不过很大的一个坎,如果有了服务器端,开发、调试的难度将大大增加,维护工作量也随之增加。

WallpaperHelper W.I.P.

  昨天说干就干,打开尘封很久的工程,添加一个窗口,把那几张现成的图片抠过来,然后计算一下桌面工作区大小,把窗口放在桌面右侧,像是侧边栏的样子。结果一开始,什么都没有显示出来,这是相对比较麻烦的出错情况,因为根据之前使用GDI+创建异形窗体的经验,这时候任何地方都有可能是出错的地点,所以要找出原因就要费点工夫。仔细对照之前写的代码,一点点的修改,终于能让它显示出一个窗口了,但是窗口仍然是窗口,没有按照预想的那样把png图片显示出来,并按图片渲染窗口形状。最后发现是在创建窗口的时候,因为心急,直接把窗口设置为桌面的子窗口了,如果把那几行代码去掉,就都正常了。经过这次实践发现,用GDI+实现异形窗体可以随意缩放窗口大小的,一般说来,要把窗口调整到需要的尺寸,通常是大于或等于图片原始大小,这时再把图片按窗口大小画上去就可以了,这种特性在绘制侧边栏的时候有用,比如可以只有小小一张图片,但侧边栏可能很长,就直接这样拉伸了。  能显示出侧边栏的底座了,就要开始考虑接下去怎么做了。鱼鱼和雅虎是两套不同的方案。鱼鱼只是能计算一下各个widget的大小尺寸,根据当前侧边栏上停靠的widget计算出其他widget停靠的位置。雅虎的稍微复杂点,它的一个widget的可见内容分为两部分,一部分是在桌面上散布的体现真正内容的widget;另一个部分可算是widget图标,停靠在侧边栏上。这样对于widget开发者来说,刷新界面时需要刷新两部分的隐性要求比鱼鱼要大,鱼鱼的只要刷新widget主窗口就可以了。当然雅虎的也不是强制要求一定要同时刷新图标,只不过有这样的表现的机会,为什么不利用上呢!  今天又偶然发现,雅虎的widget也使用了跟chrome类似的sandbox技术,从任务管理器上看多显示一个widget,就会多一个YahooWidgetEngine.exe进程,数完widget数目后,还多一个进程,我猜应该是侧边栏的。自从见到chrome后,我就莫名地对这种sandbox做法很有认同感,据说我们部门在北京的分部做的一个测试用例开发执行工具也是用的这种方式。不过相比Unix-like系统,在Windows下创建进程的开销相比就大了点,随便开了十来个widget看看,有两个进程内存占用10MB多一点,其他的都是1MB多,我估计如果它若是使用单片式结构的话,同样开这么些widget,占用的内存数应该没有这些的总和多吧。再说说由此引出的进程间通信的问题,毫无疑问,进程间通信的开销明显要比进程内通信的大,在Windows上应该更突出,不过对于像widget这种应用,进程间通信的频率和数量应该都不大,影响也倒不会太大;其次是从程序开发的角度讲,进程间通信应该更难使用,尽管Windows确实也提供了不少机制,但终归是难用啊。最后还有另外一个问题,对于稍微有点常识的Windows用户来说,这种方式是否也能得到他们的认同呢,某一天打开任务管理器突然发现有这么多相同名字的进程,会不会觉得反感呢,至少我是看到有人这样非议过chrome的。  再说点WTL相关的问题。昨天发现一个用WTL写的应用,在VS2005下编译,Debug下好好的,到了Release下连编译都通不过,删了一些怀疑的代码,还是编译不过,最后从WTL的源代码看到,原来只要在工程设置里把是否使用ATL的最小CRT关掉,就没问题了,之前也有因为这个设置引起奇怪的编译不过的问题,缺少官方正式支持的东西就是累啊,这WTL光是这些头文件包含,宏定义,就让人头大了。  最后八卦一下Inno setup,发现有时居然会out of memory,这时把里面两个压缩级别选项都从ultra改成max就好了,不知道是不是Bug?