啊，人生就是不斷地重寫同一個程序。大家看我的博客估計會發現我總是不斷的徘徊在編譯器和界面庫上。這估計是由于一直以來我總是不能把這兩個東西做到我滿意的地步，然后就不斷地重寫，不斷地重構，重構到不行了再重寫。這篇文章講了我之前做編譯器的道路，而這里、這里（這篇文章有一小部分是同學寫我的）和這里可以看成是我做界面庫的道路。

    我學習編程是從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。