用WPF做编辑器UI

最近在抽零碎的时间做特效编辑器的UI部分，和同事讨论了一下，采用WPF开发UI部分，其理由比较简单，该编辑器是为GameBryo服务的，而GB本身大多数编辑器的UI框架都采用C#开发，ToolBench部分采用WPF（WinForm中嵌入WPF），而C#本身比较适合做这类工具开发，.net又具备丰富的控件，WPF又号称microsoft的下一代界面技术，so，决定尝试用WPF做编辑器UI。

 

很久没做界面方面的工作了，我对界面开发的认识还停留在MFC时代，打开MSDN看了下WPF的介绍，突然很感慨：我out了。几年前，我做过一些网站开发方面的工作，用Dreamweaver制作网页，同时也在写一些mfc的程序，当时就觉得如果windows程序的界面如果能像网页那样做的话就好了——用Dreamweaver布局界面，然后加入一些css样式单，事件处理只需要一个onclick事件，触发一个js函数即可，事实上，很多软件也确实在嵌入了一些html作为部分界面，在我的记忆中，好像是用CHtmlView这个类嵌入html页面，然后通过IWebBrower2接口做事件传递。

在我的意识形态中，做界面就是一个杯具，效果事半功倍，为了做一个稍微复杂的界面，到处去寻找各种各样，五颜六色的界面库——MFC，WTL，QT，BCG，wxWidget，SkinMagic，etc…确定了界面库之后，为了控件更加好看或者功能更加丰富，又得到codeproject之类的网站上去找诸如xlistctrl等Owner draw的控件，如果运气实在不好，还得自己花n天的力气写一个效果看起来很囧的OnCustomDraw。。。n天过后，你的控件库丰富了，整齐了，这个时候就应该采用圣人们教导我们的MVC，Observer等模式来分离界面和逻辑，而实际情况经常是界面和数据弄的一团糟。为了适应多种分辨率和窗口任意缩放，费劲九牛十虎之力，精打细算至像素对齐，前后左中右上中下的调整，就为了搞个缩放算法。

不可否认的是，web技术的发展，对界面技术的推动是显著的，HTML，JavaScript,css,ajax,flash,xml等等等等都旨在为广大的人民群众展现一个丰富的表现层。而WPF就是综合web和应用程序界面的一个产物。

WPF能做出多绚丽的界面不是我关心的内容，作为一个实用主义者，更多的是关注它如何高效的完成工作。在我近几天的接触中，至少体会到这么几点：

首先是布局，WPF提供了Canvas，DockPanel，StackPanel，Grid，WrapPanel等多种布局类型，从布局上看，几乎包括了现有流行的布局类型。丰富的布局系统使你根本不用关心界面缩放，多种分辨率等问题。

界面风格：WPF真正意义上实现了类似于css层叠样式单的技术，只需要加入适当的style文件就可以为你的控件展现不同的风格。Btw，貌似这些文件必须加入到工程中，并且路径必须按照站点路径指示，比如

<ResourceDictionarySource="Resources/Shared.xaml" />

数据绑定：真正意义上的分离界面和逻辑，我觉得这个是我所体会到的最有用的技术，你可以指定数据源到目标的单向数据流，也可以配置双向数据流，可以指定数据源为.netobject,xml, DependencyObject，ado.net data。要实现数据的绑定，只需要在对应的xmal中指定一个绑定，如绑定TextBox到一个.net对象的属性上

<TextBox Name="boxname",Text="{BindingPath=PropertyName/>

如果要使用该控件，直接在xaml中定义一个name属性，如上面的boxname，就可以直接在c#文件里当一个成员变量直接使用

其他什么采用DirectX渲染而不是GDI+技术，使用XAML的声明式编程都不是我关注的重点，这里就不提了。

另外，WPF也有一些不足，或许是我不熟悉，或许是它太年轻，WPF的控件貌似没有WinForm丰富，比如没有PropertyGrid，NumericUpDown等控件，现成的类似vs的界面库好像也不好用（虽然据说vs2010是采用wpf开发的，但是我在网上没找到好用的类似的界面库）。WPF和WinForm可以互相集成，在WPF中使用WinFrom控件，需要一个WindowsFormsHost的控件，至于是否好用，我还没做尝试。

总之，瑕不掩瑜，WPF的界面技术或许会成为MS未来界面制作的主流技术，甚至可能演化成游戏UI的主流技术（WPF/E演化成的Silverlight能说明一些问题吧）。

 

PS. 我的vs2008（SP1）经常在编译XAML的时候挂掉，人品？bug？