在Visual Studio 2008里打开solution，都不知道从哪里下手了，囧。

　　之前我说过，作为一个文本编辑器，一个IDE，不能通过命令行参数打开一个文件，是很说不过去的。前面试图加入这个功能，结果遇到了些问题，经过昨天和今天的奋战，终于搞定了。
　　其实就是发现用wxWidgets的IPC机制怎么都不能正常运行，于是最后我想到了直接用Boost的InterProcess库，这个库也是跨平台可移植的，基本处于符合我的要求的范围内。
　　昨天还一直没死心，希望能用wxWidgets的IPC类搞定，结果果然无论是用DDE还是用Socket，都有问题。今天下定决心，先看了一下Boost的资料，发现其实很简单，InterProcess只是实现了共享内存的部分，再加上一点同步相关的机制，用于通知，于是只要在最老的进程中启动一个线程无限循环等待其他进程的通知，有了通知就从共享内存中读取文件路径信息，然后就可以打开了。
　　顺便说一下，Boost.InterProcess的共享内存类封装得比较底层，有一个类是纯粹的对系统的C API用C++类包装了一下。另一个稍微高级一点，但也是C++语言层面的高级，感觉缺少对现实世界对象的抽象。我有点奇怪自己现在怎么会考虑到这个层面的东西，大概是因为看了一段时间的Qt的文档和代码，Qt在这方面的工作确实做得很好啊。
　　还有个之前说到的，在wxApp::OnInit方法中，创建完主窗口后，直接打开文件也崩溃的问题，其实是当时测试的时候没有把配置文件放在正确的配置目录中，这个功能其实是没多少问题的。
　　总之，现在就是可以通过命令行参数指定文件打开一个文件了，然后又实现了单一进程实例，后面再要通过命令行参数打开文件，都会通过IPC机制通知最早创建的那个进程来打开文件。基本完美实现预定目标！

　　作为一个文本编辑器，一个IDE，不能通过命令行参数打开一个文件，是很说不过去的，于是我就想加这个功能，不料却意外地困难！
　　首先考虑当前没有已经运行的本程序的进程，通过命令行参数指定一个文件后，最wxApp::OnInit的最后返回前，主窗口已经正常创建显示后，可以将文件路径传递给主窗口，让主窗口打开这个文件。照理说，这应该是一个很平常很普通很正规的流程吧，结果不知道为什么，打开文件这个操作会让程序崩溃。
　　然后考虑当前已经有运行的本程序的进程了，这时如果再通过命令行参数指定一个文件，启动新进程，就需要让新进程通过IPC向老进程发送通知，让老进程来打开这个文件，而完成通知工作后新进程就可以退出了。这也是一个很平常很普通很正规的流程吧，于是我查阅了wxWidgets的关于IPC的文档和sample代码，感觉还是很简单的。在Windows平台上有两种选择，分别是基于DDE的实现和基于Socket的实现，可以用相同的代码，最终通过预定义宏来开关选择，可是最终仍然是问题重重。使用基于Socket的实现，进程在第一次启动时，Windows会弹出消息框询问是否允许该程序在本地打开一个网络端口进行监听，这就已经有点小题大做了。然后当新进程给老进程发送通知时，老进程不是没反应，貌似根本没收到通知，就是崩溃！如果切换成基于DDE的实现，倒是老进程能收到通知，但有个很奇怪的现象是从收到通知开始的那个wxDDEConnection::OnExecute函数开始往下走，wxChar*或wxString不能正确转换为const char*（因为我是使用Unicode编译项目，而字符串要以const char *传递给内嵌的Lua解释器），反正就是无论用wxString::mb_str()，还是直接的wxConvLocal::cWC2MB()都不能正确返回转换后的const char*。试了一下C runtime中的wcstomb函数，倒是能正常转换。但在Lua回调宿主程序导出的函数时，该函数将wxString转换为std::string作为返回值传递给Lua，无论用哪种转换方法，结果也会崩溃！
　　到此为止，所有尝试均告失败，加入命令行参数打开文件功能仍然没有实现，郁闷！

　　我一直在寻找，甚至试图自己编写一个Source Insight的替代品，主要看中它作为一个源代码阅读工具，并具有良好的通用代码编辑功能。如果一定要找出同类产品来，还真是比较难，也许Komodo IDE和SlickEdit在通用代码编辑器的范围上可以往上靠，但在代码阅读器的范围内，实在很少见，可能doxygen和understand for C++可以勉强算是一类，但实现方式差别很大。现在有了DForD SourceCoding，总的说来，它是最接近Source Insight定位的同类产品。
　　DForD SourceCoding具有良好的中文支持，这得益于Scintilla控件的完美实现和ICU的强大兼容性。Source Insight的中文支持一直是其软肋，多年来没有什么实质性的改进，无论是保存项目文件的路径字符，还是文件中的字符，凡是中文，都很有可能出现轻重不一的问题，DForD SourceCoding则完全没有这些问题。
　　DForD SourceCoding使用Tab栏多文档界面，很难想像如今还有一个拥有大量用户的多文档界面的软件，居然没有Tab栏，Source Insight就是那么一个独树一帜的软件，以至于有牛人通过逆向工程等手段，给Source Insight开发了外挂，通过外挂给Source Insight添加Tab浏览等功能，可谓用心良苦。
　　还有一个大问题是DForD SourceCoding的代码编辑器是支持代码折叠的，而Source Insight至今仍无任何迹象显示要在这方面有所改进。代码折叠也算是众多Source Insight用户特别期待的一个功能了，对于现在一个完整的代码编辑器，基本上可算是标准配置，可是比较遗憾的是，这个功能似乎连外挂也是不能指望上了。
　　当然DForD SourceCoding也有不少缺点，比较明显的是，速度比较慢，比起Source Insight不是差了一两个数量级。其次，DForD SourceCoding的代码分析功能相比Source Insight来说，不够精准。DForD SourceCoding直接使用了ctags和cscope来进行代码分析，而Source Insight应该是对cscope进行了一定的改进，而且跟编辑器结合得更紧密。另外，DForD SourceCoding虽然本身是基于一个Lua脚本语言扩展的架构实现，但它并不开放这个扩展构架以便用户进行二次开发，而Source Insight则是向用户开放了脚本扩展的能力。所以说，DForD SourceCoding还需要持续改进，才能彻底战胜Source Insight啊。
　　最后有一点值得说的是，Source Insight比较贵，DForD SourceCoding的定价才是它的一半多一点，当然这要看用户如何选择了，是否少花近100美元买80%功能的呢？

　　昨天算是发布出去了，这次花了3个月时间。修正了一些bug，添加了一些新特性，修改了一些功能。总之，现在回头看来，不那么令人满意。
　　没有UT是最大的问题，根本不能保证某次修改会影响到什么。这不能再忽视了，test case要开始补起来。
　　其次是编译器差异和编译模式差异之大，出乎我的意料。好几次都是VC编译出来的正常，用GCC编译的就不正常。或者debug编译的正常，release的不正常。这是因为我离不开Visual Assist，也有点离不开VC的调试器。这点实在不好解决。
　　再次是Lua开发环境还是不够好用。Auto Completion不准确就不说了，有时Auto Completion出来过后，整个程序就会很卡，不知道为什么。以后要能做到Auto Completion分库，可以让用户随意通过增删文件来增删符号库。
　　最后一点是对架构的不满意。经过如今大半年的迭代发现，插件扩展架构的可扩展性和可裁剪性不够灵活。这点现在还没有具体的思路，或者说一直觉得实现上也许有点麻烦。
　　除了这些外，还有许多特性要增加，比如增加几种常见的SCM工具支持，开放二次开发接口，增加插件扩展的开发环境等等。