All Stories

嵌入Lua即可

  今天又看了一下wxLua,其实很简单一回事只要把用CVS下载来的wxLua源代码编译一下,生成一个wx.dll文件(当然是在Windows平台下的),该文件依赖于wxMSW的两个dll,分别是wxmsw28u.dll和wxmsw28u_stc.dll,如果用不同的编译器,或者编译选项,可能会有不同的文件名后缀(注,不是扩展名)。我是用MinGW最新扩展4.3.2 TDM-2来编译的,把编译出来的dll放到搜索路径下,用lua.exe就可以直接运行wxLua自带的几个例子程序了,比如auidemo.wx.lua。  开始时,还在想到底是嵌入一个纯粹的Lua解释器,还是嵌入wxLua。其中的区别就是嵌入wxLua可能会需要多点C/C++代码加到工程中,作为胶水代码连接lua代码和wxWidgets。现在发现,其实不用管这么多了,只要嵌入一个纯粹的Lua解释器就够了,再设定好搜索路径,即package.cpath,就可以自由地装载wxLua了,其他的第三方库也可以用了,比如LuaXML、LuaZip等等。  我仰天长笑,接下来的问题是,如何让外部的Lua脚本识别出各个scintilla控件。MDI界面必定会有多个Scintilla视图,怎么能让脚本方便自主地获取到自己需要操作的那个视图呢?

2号了

  不知不觉,2008已经过去,又是一事无成的一年,凄凉到我有点不堪回首。  12月31日是江江的生日,江江居然邀请我到她家去吃火锅,这让我有点受宠若惊。记得30日时她发邮件,我还没反应过来,一直到31日上午才明白,于是思量着送点什么小玩意儿意思一下。一直到下午快下班的时候才跑到孙同学那里去,抢了她放在机箱上的娃娃。说受宠若惊,不是夸张,而是有原因的。一是我自以为跟江江并不那么熟络,二是我知道江江有BF但她却一直吞吞吐吐,这么邀我去,不就让我什么都知道了吗。不过太多的猜测,或者说心里搞得太明白,反而会让生活变得累人,所以还是不管那么多了。到了江江家,是一套七八十平的两室两厅,有点温馨的感觉。江江的BF似乎有点眼熟,可能是以前哪里见过,但我一点都记不起来,但是他说见过我,汗!火锅味道不错,还有很多肉和丸子,是我很喜欢吃的东西。吃过火锅又打麻将,一直到午夜12点,真是心旷神怡啊!没想到这次新年钟声响起时,我是在打麻将,哈哈。以前的各次印象已经差不多全没了,只记得有一年,大三吧,居然是在自习,欢呼声传出时,我刚刚走出二教大门。  1号,也就是昨天,在家宅了一天,连饭也没正常吃。先是捣鼓了一阵wxLua,它的出现让我犹豫,我是只嵌入Lua,还是嵌入wxLua呢。用嵌入wxLua的好处是,除了用脚本来表达业务逻辑外,界面的一部分也可以方便地用脚本来做了。但从网上看到的一些文章看来,wxLua的评价并不高,而且最大的问题可能是绝大部分开源软件都有的问题,技术支持太少,出了问题不知从何下手寻找解决方案。从CVS下载下来最新代码,直接用MinGW编译还不过,要改下makefile才行,而用vc9编译,则完全不知道如何下手修正了。然后出去吃了个KFC,修剪了一下头发,就看小说去了,看到后半夜!  2号了,好些天前就跟猫猫约好去看电影,起床玩了一会儿电脑,掐着时间出去坐335,到中信广场。来深圳这么久,看电影只去过1次CocoPark的百老江,去过3次东海太平洋。这次不知猫猫从哪里弄来的电影票,刚好去看看新南国的环境怎么样。先去吃了顿泰国菜,然后晃悠上去。片子还是不错的,冯小刚作品,葛优,舒淇主演《非诚勿扰》,有点搞笑,中间有点悲伤和无奈。看完电影,去购书中心晃了一个多小时,跑去喝鸭血汤作为晚饭,然后打道回府!  ……

MSXML删除节点

  昨天遇到一个问题,用MSXML操作XML时,删除一个子节点,可是死活删不掉。后来想到一个变通的办法,把这个子节点的标志性属性值改掉,这样其他处理过程就认不出这个节点了,就相当于删除了,很黄很暴力。  今天再去定位这个问题时,发现原来那子节点真的被删掉了。进一点试验发现,只要在删除该子节点前,先随便改一下这个子节点的一个属性值,下面的删除操作就正常了,但如果没有那个修改操作,就删不掉,真是怪事!  我当时还以为是不是因为子节点下面还有其他孙子节点,还想是不是要修改一下删除子节点的封装方法,递归地删除掉所有子孙节点呢!看来不必了!

e这么烂的程序也卖

  今天在公司看到一个同学在用e,有点好奇,早听闻它有“Windows下的TextMate”之称,以前也下载来装过,只看到界面很简单,功能也很简单,于是就没下文了。今天又有点兴趣,就让同事共享给我再试用一下。  还是老样子,界面上没什么改进,也许比之前我试用时功能上有所增强,但以我目前的眼光看来,它还是太简单了。总的说来,只有一个特色功能,就是bundles。不过可能TextMate赖以成名的就是bundles了,e就是全盘照抄了,从网上看到,说e的作者和TextMate的作者是老乡,两人协商过,让e可以直接使用TextMate的bundles。所有的人都说,e只有TextMate的一小部分功能,这我也是相信。但是最让人受不了的是,e运行极其不稳定,随便点几下就是挂起,或者崩溃。这么烂的程序居然也来卖,而且听同事说可能卖得还不错,我想这全沾了TextMate的光啊!因为说,它的一切思想,无论是从程序开发的角度,还是用户体验的角度讲,都是很好的,但这一切都是TextMate赐予的,e里唯一有点自己特色的是,用类似异步可插入协议的方式来修改配置。我没用过TextMate,不晓得它在这方面是怎么做的。  看了e后,另外一个同事就说,我们现在的Impeller应该也好卖吧,有语法结构树,有自动完成,有调试执行,我笑!

阴雨天睡午觉之安逸

  昨天晚上跑去KTV唱歌,后来唱歌腻了他们就放起的士高来,我是不会蹦迪的,可是看着那些人在那跳得那么起劲,我也有点蠢蠢欲动了,于是去胡乱蹦了几个。结果,今天就显效了,虚脱了,背痛,下午一下就睡着了,好久没在家里睡过午觉了,醒来的时候发现天灰蒙蒙的,还有雨声,还以为睡到天亮了,心里不禁大喊,天呐,我居然从前一天下午睡到第二天早上,还没吃晚饭!后来挣扎着要不要起床,看了一下时间,才18点,心里顿时安定了不少,原来还没到第二天啊,刚刚还郁闷着这周末就不知不觉地让我睡过去了呢!  再说点正儿八经的事。话说我一直想要设计一个基于C++ GUI框架的脚本扩展架构,不过到目前,还没有一个完整的清晰的思路,我只有一个大致的目标。一直想着,这样的架构实现后,只要C++部分实现一些基本的底层支撑,剩下的脚本就可以直接拿出复用,实现所有业务逻辑。为了证明这个架构的通用性,我觉得自己似乎有点儿贪心了。我希望在MFC+XTP的基础上、WTL+TabbingFramework的基础上,以及wxWidgets的基本上都实现一遍。MFC的是因为工作上的需要,WTL则是因为想写一个WIND,而wxWidgets的则是想写一个通用的跨平台IDE。今天只想到一点,所有的逻辑处理都应该交由脚本实现,C++部分只提供最基本的底层(原子)操作。

检测不到Excel文档的修改

  昨天偶然发现,我的程序根本检测不到Excel文档的修改,太让人郁闷,之前完全没料到这个结果啊!后来回想一下也想通了,Excel文档那么复杂的一种文件格式,不使用像txt之类的修改方式,完全是可以理解的。不过理解归理解,问题变得棘手了,怎么才能实现那个需求呢!  今天没写代码,倒是在自己建的wiki上写了几篇文档,有关于设计方案的,也有关于使用说明的。我要开始准备撤退了,出于道义上的,或者说职业道德上的考虑,也是为了让自己以后少被人骚扰,我要输出尽量能解释清楚我目前所做的一切的文档。  写文档也是个很累人的体力活啊,也许是因为几乎从来不写文档,让我觉得很多事情都不知道从何说起。心中很清楚明白其中的每个细节,却不能用文字表达出来,或者说即使能零碎地写些文字出来,却不能有效地串连起来,形成完善的文档。  今天质量部的老大把我叫去,谈了一下之后的计划,我刚好趁此机会明白地告诉他,我对之后的维护性质的工作实在没多少兴趣的,而他居然出乎我意料地说,如果是这样的情况,可以换个人,而且还肯定了我之前所做的,这让我心里比较高兴,哈哈,仰天长笑!

UNICODE与Scintilla合用的问题

  今天做另外一个工具的一点维护工作,需求是通过用户输入的宏名,宏值,类名,函数名以有函数返回值,工具要能自动到指定的文件中找到指定的位置,自动插入生成代码。本来这个需求是上个版本就已经实现了的,今天只是对需求有略微一点修改。可是最大的问题是,今天发现以前实现的这个根本不能用啊,文件是能找到,可是位置却是错的,根本毫无联系。  调试了很久,实现过程是首先利用MSR的greta来找到参考标记,取得标记的位置,然后插入生成的代码。一开始怀疑是取得标记的位置不对,其实冷静地想想,这种可能性几乎不存在。不过我还是傻傻地加入代码,看标记位置取回的字符串内容,毫无疑问,肯定是对的。接着怀疑是Scintilla的插入方法有问题,同样事后想想,这种可能性也微乎其微。不过我也不死心地,加入代码,看该位置的Scintilla文本,果然已经是不正常的内容了。  正在束手无策之时,突然不知怎的,灵光一闪,可能是因为看到其他一个项目中使用多字节编码的greta,觉得可能是这里引起的问题。greta在匹配文本时,在unicode情况下,一个中文字符和一个英文字符都是一占一个长度,而此时Scintilla还是以多字节方式处理,一个中文字符占两个长度,所以greta算出的位置对scintilla来说并不能对应上。想通了这一点,立即将工程编译选项切换到多字节方式编译,果然就正常了。  这次遇到这个问题,也能为以后实现相关需求,或者解决类似问题,提供了极大的参考价值。

培训计划

  老大叫我整理一份项目组内成员的C++相关内容的培训计划。我还是兴冲冲地去弄的,不过基本上是参考我自身的情况制订的,内容方面不是我比较熟悉的,就是我比较欠缺但又在工作中比较需要的。  主要分了8大类,分别是C++对象模型、C++模板、STL、Boost、面向对象程序设计、Windows API、MFC、COM。每一类,都又划出好几个培训课程,我还根据自己所了解的,分别给每一类都备注了参考资料,每一类的的参考资料大多只是两三本经典书籍,比如COM类的,我就写了《COM本质论》和《深入解析ATL》,而Windows API类我就写了《Windows程序设计》和《Windows核心编程》,等等。  等我把这份列表发给老大,老大又转给更大的老大,更大的老大则回复说,内容太多了,要分轻重缓急。我觉得很有道理,这样的培训是很耗费资源的,当然应该拣最有用的来。不过他列出的前3位是Windows API、MFC和COM,对于我来说,就有点兴味索然了。虽然这些方面我也远远说不上精通,甚至连熟悉都不够,但我自以为,应付工作上的要求是够了。比COM举例来说,我虽然排斥COM,但必须用地方还是会用的,我会调用COM服务器,同时我也写过COM组件,我觉得自己够了。  既然不能把这份列表作为组内的培训计划,我看了看,觉得依照这些列出的参考资料,也可作为我自己的增强计划。这8类我都有所了解,在实际工作中也都或多或少地有所运用,但我不禁要考虑,学到什么程度算是够?  我个人倾向于学习和使用一些比较通用的技术,比如STL、Boost之类平台无关的知识我就很有兴趣,而COM则是有点深恶痛绝的感觉,MFC稍微好过一点,不过也不是很喜欢。这不是我研究了这些东西后主动有了喜恶观念,而是不知不觉在一个比较长时间内养成的兴趣倾向,直到后来自己总结的时候才发现这个规律。  其实我根本没多少想法,要尝到什么程度,目前而言,我只好给自己暂订个目标,STL、Boost、C++模板和对象模型,以及面向对象程序开发,是能学多少算多少,而其他的,则是够用就行。

使用wxWidgets一天有感

  幸亏有Code::blocks和CodeLite两个的源代码可以参考,可以省事不少,不过还是发现,要像现在用MFC一样的比较熟练地使用wxWidgets仍需要先阅读一些基本的资料,当然wxWidgets的manual也是必不可少的。  学习一种新的GUI框架的使用方式,关键还是在于了解并掌握它的消息处理机制。通常见到的GUI系统都是消息驱动的,所有所有的编程框架都不可避免地要有一套自己的消息处理机制,而且这套机制的设计好处,直接影响到整个框架的运行效率和使用效率。  总的说来,我感觉目前wxWidgets已经有点庞杂,好处是有些问题可以有多种解决方案,坏处是增加了学习成本以及降低运行效率。总觉得它不但最终生成的可执行文件体积大,而且运行效率太低。不过似乎用gcc编译出来的代码,运行效率也不如用VC编译出来的。假设能用Intel编译器来编译,是不是运行效率能更高呢?  现在用wxWidgets来写程序,还有个比较麻烦的问题是,跟用MFC开发相比,缺少一个好用的开发工具。以目前凡事都追求效率的情况来讲,写程序早已不是随便找个文本编辑器就能写代码的时代了,不光要有基本的文本编辑能力,其他自动完成、重构、提示、引用跳转、向导等等,无不影响着程序员的心情,以及开发效率。从这方面讲,目前已经没有哪个环境能跟VC+MFC比了。用vc也能写wxWidgets程序,但跟开发MFC程序相比,它缺了各种向导,比如Property视图,可以直接为各种系统消息、命令ID生成对应的函数声明,还有常用类派生的虚函数实现。  不过,总算起步了!