啊，人生就是不断地重写同一个程序。大家看我的博客估计会发现我总是不断的徘徊在编译器和界面库上。这估计是由于一直以来我总是不能把这两个东西做到我满意的地步，然后就不断地重写，不断地重构，重构到不行了再重写。这篇文章讲了我之前做编译器的道路，而这里、这里（这篇文章有一小部分是同学写我的）和这里可以看成是我做界面库的道路。

    我学习编程是从VB拖控件开始的，后来又经历了Delphi，现在工作又用C#，所以平时自己写什么想坚持C++就变成了一件很纠结的事情。我觉得语言是一种信仰，C++用的爽当然希望他无所不能（其实本来也是。嗯……这句话应该也是信仰）。结果MFC又封装的太难用，其他的界面库基本上都没编辑器，现在C#还有WPF、Silverlight，Adobe还有Flash或者Flex，那C++有啥？啥都没有。但是我还是想用C++写漂亮的demo啊，怎么办呢，没有只好自己操刀。

    话说回来，我从来就不指望我写的界面库能够充当WPF和Flex这种分量的，只是我自己需要了，就写一个，反正闲着也是闲着，做了编译器总要有一些看得见摸得着的demo的。

    第一次做界面库倒并不是因为C++的缘故，本来是给Delphi做游戏的。大一的时候想移植到C++上面，结果就用OpenGL做了一次。后来为了更方便我封装了一下WinAPI（其实封装比自己写难TM多了）。只是Windows的界面标准过于高级，API又过于灵活。我一直以为在菜单上加个图标是很容易的，到最后才明白VB也好Delphi也好.NET也好都偷偷替你OwnerDraw了。我一直以为按钮可以放在一个GroupBox上的，结果竟然XP这个bug没修，.NET偷偷在Button下面放了一个容器来绕过这个问题。我一直以为API提供了WS_TABSTOP的话就帮我们解决了Tab跳转焦点的问题，结果WS_TABSTOP竟然是为了我们方便自己实现跳转焦点而存在的。我一直以为模态窗口是一件很自然的事情，结果不仅没支持（MessageBox那玩意儿倒支持了），实现起来还不容易。

    而且加上我自己也很喜欢RIA，于是就想着干脆总结之前的经验，自己做已做好了。搞定了之后还能给编译器写个demo还是写个破IDE什么的，凑合着估计还有点用。

    目前还没有一个非常详细的计划，只是在项目开了一个子文件夹做做实验。由于观察到界面库的Logic Tree和Visual Tree一般来说有明显结构上的区别，绘图API可以置换，Hit Test跟Control Style应该捆绑等现象，打算基于这种想法来实践实践：

    1：使用Windows API创建窗口和GDI对象，再给出一个跟平台无关的接口来屏蔽这个实现。其实我不想跨平台的，只是这样工程管理起来比较有效罢了。

    2：将控件切割为状态、显示位置、风格和排版四个部分。其中控件自己有自己的结构，排版则将控件结构（Logic Tree）映射到一个显示结构（Visual Tree）并自动维护，显示位置是用于提供显示结构功能的一个框架，风格则负责绘制以及做Hit Test从而将用户输入的系统消息转换成逻辑消息（譬如说点击某个位置 => 点击滚动条的向上按钮）。

    3：提供一套Control Combinator。Windows那套严格来说不是Combinator，凭什么ListView的条目不能是我自己写的控件呢？显然这是他不是Combinator的一个明显的证据。Combinator就好比我们写代码，各种不同的语句组合在一起还是语句，不同的表达式组合在一起还是表达式，而且还有把表达式和语句互相转换的唯一方法，这就是Combinator了。换个角度来说，这跟WPF的那么多种ItemTemplate还是什么破Template应该是一回事。

    4：为每一种Control提供一个默认的风格。其实这个是必须做的，不然连用都没法用。

    5：让控件渲染用的技术、控件风格和控件排版功能可以独立变化。这是所有RIA的共同特征。

    其实也就这么多了。如果试验成功的话这个库将会被合并进Vczh Library++3.0。