转： windows下C++ UI库 UI神器-SOUI - CSDN博客
转： windows下C++ UI库 UI神器-SOUI
转：/setoutsoft/p/4996870.html
在Windows平台上开发客户端产品是一个非常痛苦的过程，特别是还要用C++的时候。
尽管很多语言很多方法都可以开发Windows桌面程序，目前国内流行的客户端产品都是C++开发的，比如QQ，YY语音，迅雷等。
快速，稳定是我认为的应用软件开发框架最基本的要求，对于UI还有两个要求就是界面美观，配置灵活。
C++语言满足了快速的要求，传统的客户端软件开发框架如MFC，WTL等满足了稳定的要求。然而界面美观，配置灵活是MFC，WTL这样的开发框架所不能满足的。
腾讯是做客户端发家的，他们的UI经验积累非常好，有自己专门的UI框架；迅雷有一个专业的团队开发自己的UI框架；然而大多数公司只希望有一个能够快速完成项目开发的UI库来使用，它们没有专业的团队来维护UI库。国企有钱任性，所以成就了UIPower：一个商业化的DirectUI库（具体怎么样不好说，优点在于有人给你服务），一般的小公司没有谁愿意当这个冤大头。这就是Duilib这样一个简单到简陋的UI库（请原谅我这样说）为什么这样流行的原因（百度一下Duilib就知道它有多少人在用）。
Duilib基本满足了界面美观&，配置灵活的需求，然而由于框架本身的限制，要实现复杂的效果将不可避免的遇到各种坑。好在Duilib代码量很少，随便一个有经验的UI开发工程师都能够相对容易的使用并修改它，所以在一般的应用中使用并不会有太大的问题，这也应该是为什么会有那么多的Duilib变种的原因：每一个使用它的公司或者个人都会有一份独一无二的副本。
其实上面我还漏了说QT，&QT在国外有专业的团队维护，文档也很好，但至少有两个缺点：1、它是跨平台的，跨平台即是优点，也是缺点，为了实现跨平台，很多时候需要做出取舍，就算抽象的100％的完美，它也不可避免的带来体积庞大；2、代码量太大，普通人很难驾驭：就算是看懂都不容易，更别说修改了，这样的结果就是一旦在使用中遇到问题你唯一的选择就是提交BUG给QT开发小组等待补丁（要知道不存在没有BUG的产品）。
SOUI是什么？
SOUI是一套和Duilib类似的开源C++&UI开发框架。它的祖宗是金山卫士开源版本中使用的UI库Bkwin，之后由启程软件（也就是我了）开发维护升级为Duiengine，最后历经多次重构改名为SOUI，寓意“瘦UI”，“UI, just so so!”。使用MIT开源协议，公司、个人兼可免费作用，只需要发布时带上SOUI的license。
SOUI代码的获取
SVN：&&不要在浏览器中打开该网址，只能使用SVN客户端签出。
SOUI界面效果
SOUI的特点
使用层：高速，稳定，美观，可配置
代码层：精心设计，模块低耦合，插件化设计，对象可靠的命令周期管理，类似WTL的编码方式，现代化的事件处理模型及优异的扩展能力。
代码量：核心模块代码量4W+，编译后DLL Release版本在900K左右。得益于精心组织的代码框架，虽然代码量较Duilib这样的UI库有比较大的提高（核心框架更完善，控件更多，注释量更大），但是阅读代码还是很轻松的（大量实际用户的亲身体验）。
高速主要体现在3个方面：&
1、框架设计扁平化，层次简单（和QT相比）：从宿主窗口收到消息到控件响应消息只有一个中间层。
2、简单有效的刷新策略：通过对剪裁区及刷新时机的有较控制，&能有效的提高刷新效率。
3、高效的渲染引擎：通过&将渲染引擎接口化，成功的将skia渲染引擎引入到SOUI中，Skia是Google的Chrome的渲染引擎，Chrome比IE渲染速度快，Skia功不可没。
稳定性方面，SOUI脱胎于Bkwin，再经过本人的不断精心重构，已经在多个大量用户的产品中应用，包括最近开发的瑞雪医生客户端，多玩魔盒2.0, Dota2游戏盒子及多玩多个游戏盒子中使用， 及百度云管家的大部分界面。
百度云管家据说最初使用的是腾讯QQ界面库的早期版本（无从考证），然而QQ界面库大量使用COM技术，扩展非常麻烦，使用很是不便，在后续的UI需求中开始大量使用SOUI的前身DuiEngine。
美观方面，SOUI原生支持Alpha通道，能够实现各种半透明效果，包括主窗体半透明，DUI窗口半透明，DUI窗口模仿LayeredWindow（分层窗口）效果等，轻松实现各种异形效果。
可配置方面，SOUI中所有UI资源都采用XML描述，调整UI效果一般只需要修改XML资源即可完成。
说到代码层的设计很难用语言描述，只有亲自阅读代码方能理解。为大部分需要在外部（APP层）经常引用的UI相关对象提供引用计数设计能够有效减少C++开发中常见的野指针问题，这一点还是很好体会，同时系统中也重点解决了如消息分发的分层设计，窗口对象的消息重入等影响UI使用体验的关键性问题。
宽泛的说SOUI多好大家并没直观的感觉，下面从一些具体的点来介绍SOUI。
也许初学者对于SOUI的布局还不太适应，特别是对于那些习惯了Duilib的布局方式的朋友。事实上SOUI的布局应该是最接近程序思维的布局方式。前段时间开发Android，仅仅是它的5大Layout就能让人崩溃，而且不同的layout对应的布局属性还不一样。
SOUI的布局非常简单，只有两个布局属性：pos + offset，具体参考博客：
通常使用一个pos属性就解决布局问题了，pos在XML中使用&x1,y1,x2,y2&这样的4个坐标定义一个控件在父窗口中的相对位置，而offset则定义通过pos计算出来的位置后在X，Y两个方向需要叠加的偏移，偏移值需要乘上窗口大小。
例如下面这个需求：
只知道窗口需要靠右下角，不知道窗口大小的情况，在SOUI中只需要使用属性pos=“-20,-30” offset=&-1,-1&即可。
&一个UI中的界面元素最后会通过各级子窗口形成一个树状结构。一般的渲染流程自然是从根节点一层一层的直到渲染完成所有叶结点。这个过程很简单，可能很多UI库也就做到这个层次（例如DuiLib）。但是对于一个高性能的UI库仅做到这个层次是不够的，举例来说：一个画笔程序需要在OnMouseMove里面绘制新拾取的线条，本能的做法是获取窗口画布，绘制完成后再提交画布（类似Windows API: GetDC and ReleaseDC），而不是每一次绘制只能请求宿主刷新（请求宿主立即刷新依赖于系统对UpdateWindow这个API的响应速度）。
因此一个成熟的UI引擎有必要实现GetDC及ReleaseDC这样的接口。和基于HWND的窗口获取HDC不同，在一套DirectUI系统中实现GetDC及ReleaseDC要更加复杂：最关键的问题在于获取前绘制窗口的背景，以及提交后绘制窗口的前景，要实现窗口背景前景的分开绘制又需要系统提供绘制在指定Z-Order范围内的窗口的能力，当然前提是系统中有Z-Order这样的概念。
就算实现了窗口的背景与前景的分别绘制，对于一个高性能的UI引擎可能还是不够的。因为有些时候一个窗口中的内容是不需要和背景混合的，窗口刷新的时候绘制背景是没有意义的（如视频播放窗口），就是需要另一种技术：窗口的跨层渲染（不知道这样命名是不是合适）。当一个视频窗口需要刷新的时候，它的刷新流程和基本的刷新流程是不一样的，渲染时它会跳过它的所有父窗口直接到这个窗口层来，从而大大加速渲染过程。
Windows的分层窗口是Windows 2000提供的一项重要更新。苹果系统的UI很漂亮，有了分层窗口，Windows系统上开发的应用也可以同样漂亮。
这里说的分层窗口有两个层次：一个是DirectUI的宿主窗口中使用分层窗口技术；另一层是在DirectUI的DUI窗口系统内部实现分层窗口技术。
使用分层窗口技术听起来比较简单，不就是设计一个WS_EX_LAYEREDWINDOW属性再使用UpdateLayeredWindow(EX)更新窗口吗？！如果SOUI只达到这个层次，那和codeproject上随便找一个demo也没有什么区别。
首先要搞清楚，SOUI是一套DirectUI系统，而不是Demo，因此它不能停留在加载一个32位PNG图片并显示出来这样的层次上。它必须要能够让用户能够调用各种绘制图形，图像，文字的API来组合出一个最终需要呈现的32位位图。这一点要求看起来简单，在Windows系统上实现起来并不简单，因为Windows上最基本的绘制API（GDI）都是不支持alpha通道的。有一个简单的选择：GDIPlus。然而GDIPlus有一个毛病就是速度太慢，这对于一个通用的UI引擎来说，全部依赖GDIPlus基本上就宣判了这个引擎的死刑。在SOUI中采用渲染引擎抽象的方法实现了两种渲染引擎：Skia
+ GDI。前面不是说GDI不支持Alpha通过不能用吗？没错，直接用GDI函数是不行的，我们需要适当的改造（具体方法参见代码）。
解决了绘制方法，要更新到窗口中显示也还是有技巧的。有人可能知道，使用UpdateLayeredWindow这个API更新的窗口将收不到WM_PAINT消息。由于在半透明窗口中不能直接支持有窗口句柄的子窗口的显示（如IE控件），SOUI还必须为那些需要容纳窗口句柄子窗口的情况提供支持，即通过配置同时支持半透明窗口与不透明窗口。但是我不愿意为两种不同的最终位图呈现模型提供两套不同的机制。解决的办法很简单，通过为半透明类型的窗口设计一个辅助窗口，使用它来接收WM_PAINT消息，收到该消息时调用UpdateLayeredWindow更新窗口。注：
这个技术是学习另一套UI库MetalBone实现的。
讲完了使用宿主窗口分层窗口，下面讲讲DUI窗口的分层窗口技术的实现。&
使用分层窗口技术能够使UI效果更漂亮，关键技术就在这个层。层是什么？层是一组窗口的绘制容器，它将该层下所有子窗口的绘制内容绘制到一个独立的缓冲区上，&最后再一起绘制到分层窗口的上一层绘制缓冲区中。如下图：
A、B、B1、B2、C为DUI系统中5个DUI窗口。其中，B、B1、B2是同一个渲染层。也就是说设计需要它们先绘制好后再和A，C做融合。&类似的需求对于一个漂亮的UI来说可能会很常见。如果在UI引擎中没有层的概念是不可能实现的。如果不需要实现前面提到的背景和前景分别渲染的情况，实现会层窗口其实也不难，只需要在渲染到B窗口时创建一个缓冲区，把从B开始的内容渲染到这个缓冲区，完成后再回到正常渲染流程，就像没有B1、B2一样。但是SOUI是支持背景前景分别渲染的，实现这个过程的代码逻辑就可能很复杂了（可以自己想象一下）。
HWND的非客户区用来绘制滚动条及边框及标题栏，菜单栏。客户区是用户绘制的常规区域，在设计上将窗口的显示区域划分为客户区和非客户区，有利于用户在重写客户区的绘制代码时不被非客户区干扰，也有利于代码的复用。
在DuiLib中，一个控件如Richedit需要显示滚动条，它需要给这个控件组合两个滚动条控件。这种方式虽然看上去没有什么大的问题，如果由于窗口中内容的变化需要动态显示隐藏滚动条时可能会很麻烦，至少它会引起窗口布局系统的重排，因为滚动条显示和隐藏时控件的客户区大小是变化的。
而在SOUI系统中，滚动条和HWND一样，用户根本不需要关心，因为内部已经自动处理好了滚动条，也不会引起布局系统的重排。
一般来说SOUI中引用的所有资源都在XML中描述。刚入门的朋友通常反映SOUI中使用资源的方式不如DuiLib直接，很难入门。但是一旦真正理解了SOUI的这种资源组织方式一定会更喜欢SOUI。
SOUI提供3种资源加载方式：文件，PE资源，ZIP包。
首先SOUI的资源包必须提供一个文件索引表，对于使用PE资源的资源包，索引表就是资源的类型及ID，而对于直接使用文件或者ZIP包的资源，索引表则是一个XML文件。在索引表中，定义每一个资源的type及name两个KEY，SOUI界面布局中只能使用type和name两个key来引用资源。
用户只需要准备一套文件资源，如果需要将资源编译到PE文件中，系统提供一个工具直接从文件资源的索引XML转换成rc编译器可以识别的rc文件；而如果用户需要使用ZIP资源包，则只需要使用一个ZIP工具如rar, 7z将资源文件夹打包即可（推荐使用7z打包资源，SOUI内自带的zlib 1.2.5能够识别7z打包的带密码的zip包，但不能识别rar打包的带密码的zip包。
窗口动画改进
一般情况下我们推荐使用窗口定时器来创建动画。使用窗口定时器创建动画的好处是定时器和UI是同一个线程，而SOUI不支持多线程同步更新UI（事实上一般的DirectUI库都不推荐在工作线程中操作UI，如Android）。那么问题来了，如果为每一个DUI窗口创建很多定时器，那么系统的消息队列中将充满定时器消息，严重时可能大大降低UI性能。
解决方案：在主窗口中创建一个10ms间隔的定时器，需要处理动画的窗口向系统注册使用该定时器，动画记录下一次动画需要等待的时间，使用该统一的定时器计数。
我们看一下面DEMO中显示大量动画表情时SOUI的效率：
这一CPU占用率甚至比QQ中同样情况下还低。
什么叫容器分层？在DirectUI中所有的DUI窗口都必须生存在一个容器中。DUI窗口的绘制请求等最终需要由这个容器来实现。在容器不分层的情况下，所有DUI窗口在容器中的物理坐标都是从(0,0)开始。这样有什么问题呢？如果要在列表控件的列表项中使用DUI控件就会变得非常麻烦，因为在窗口滚动时你可能不得不同时更新所有这些控件的坐标。
有了窗口层的概念就不一样了，每珍上列表项是一个新的容器，无论列表项显示在哪，列表项中的控件（容器中的控件）的坐标都不需要调整。因为有了容器分层，在SOUI中实现包含子控件的列表变得非常简单（参考下节：高性能列表控件）。
高性能列表控件
Windows系统中提供的列表控件非常简单，只能满足简单的数据显示需求。注意，是显示。然而现在的UI需求中经常出现那种即时修改列表控件内容的情况，你将不得不花大量的时间对列表控件进行自绘，而效果只能说勉强。
通过研究Android系统中提供的列表控件的代码，借鉴Android中ListView的思想，SOUI实现了一套高性能的列表控件SListView及SMcListView。
SListView及SMcListView都是基于虚表技术，同时只创建当前正在显示的及部分备用的列表项容器，将资源占用缩小到最少。同时ListView在滚动时能够高效刷新，实现了海量数据的高性能显示及更新。
实现这个高性能列表控件的关键有两点：
首先是SOUI中实现的容器层的概念，使得列表位位置变化时，容器内部的控件不需要调整坐标。
其次就是容器数据的充分重用。
注：上面列表中只测试了7W行数据，实际上listview中显示的数据量多少完全不影响UI性能，亲测700W行数据和7W行效果一样。
无窗口Richedit
Edit控件是UI中最常用的控件之一。在允许存在子窗口句柄的情况下，系统Edit控件已经能够很好的满足我们的需求。然而在不允许子窗口句柄的情况下，实现一个Edit控件会非常麻烦。
当然，程序可以选择自己去重新实现一套edit，Edit也许还可行，一般情况下要实现一个Richedit基本不可行。&好在实现Richedit的模块riched20.dll中把UI和逻辑分离开来，即可以用它直接创建有窗口的Richedit，也可以用它来创建提供无窗口Richedit的ITextServices接口。然而即使是这样，程序员需要为ITextServices实现一个ITextHost接口。尽管MSDN上有相关的文档及示例，但是根据它们提供的这些资料实现的效果很不理想。必竟只是Demo，不是完整的代码，它不能演示开发中可能遇到的每一个细节。然而恰好是这些细节是影响UI用户体验的关键。
所以我们需要另辟蹊径来解决这个问题。我解决这些细节，关键在于理解它们的逻辑。SOUI的办法是找到riched20.dll的源代码。好在网络上流传着一份从WinCE源代码中分离出来的Riched20.dll的源代码，虽然用它编译出来的Richedit有很多BUG，但利用它可以让我们更好的理解各种细节。大家可以测试SOUI中的Edit，效果应该是各种类似库中最好的一个之一。
XML+LUA
部分模块在SOUI中采用了接口化设计，如前面提到的渲染引擎，以及后面要说的多语言翻译，以及这里要说的脚本模块。
脚本语言方便灵活，更新简单，LUA脚本还有高效的特点。和WEB的HTML+JS类似，SOUI实现了XML+LUA的UI开发解决方案。XML实现UI布局，LUA实现逻辑控制。
实现方法：
在XML中使用&script&标签声明UI中需要脚本支持。
通过XML创建UI时自动从脚本模块为该UI实例化脚本对象。
采用lua_tinker自动导出C++类到LUA脚本空间，包含控件对象，及控件事件对象。
在LUA脚本中处理事件响应。
多语言翻译
多语言翻译对于需要国际化的应用来说可能非常重要。SOUI通过一个语言翻译接口来执行特定上下文的多语言翻译并且实现了一个类似QT语言翻译功能的基本XML的语言翻译模块。用户只需要按照Demo中的语言翻译文件的组织方式组织翻译XML就可以了。
String及其它基于模板的集合对象的参数传递
由于String通常要同时支持char及wchar_t这两种字符类型，通常String在一个类库都都是以模板形式存在，比如WTL，ATL，（MFC太久不用，记不清了）。使用模板实现的对象有一个特点，那就是代码会编译到使用它的模块中。如此一来，如果在这些模板类中直接调用malloc, new等内存分配函数时会在调用模块的堆上分配内存，相应地，内存的翻译也需要在调用者模块中执行。
这有什么问题呢？最大的问题莫过于这样的对象不宜在不同的模块之间比参数进行传递（当然，const参数是没问题的）。如果一个这样的对象在A模块中分配的内存到B模块中被翻译，结果只有崩溃。（如果所有模块采用MD方式动态链接VS的运行库是没有问题的）
很多小软件是不希望采用MD编译的，因为这样的话为了确保程序的正常运行，还需要带上VS中相对应的运行库，尽管体积不大，但也麻烦。
SOUI中采用了一点技巧，所有上述模板类都在一个独立的模块中实现，同时改写了这些类中的内存分配及释放代码。将它们重位向到该模块中的两个内存分配释放方法。经过这样处理后，不管这些模板类在哪一个模块中实例化，它们要在堆上申请及翻译内存时都是在这个独立模块中。通过这个简单的技术有效的解决了这些模板对象不能在不同模块之间传递参数的问题。
先进的事件处理模型
SOUI同时支持类似WTL消息映射表方式的事件映射表来响应事件，也支持新式事件订阅的方式响应事件。事件映射表处理事件的优点在于能够规范化的把所有事件处理方法在代码水平集中到一起，方便代码的阅读；而事件订阅则提供了事件的动态处理能力，能够在任意时刻灵活的响应不同控件发出的事件。
除上述亮点，我相信还有很多细节的处理都体现了SOUI的工匠精神，相信用心的朋友一定可以在阅读及使用代码的过程中更深的体会到。SOUI是启程软件历时5年心血的结晶，重复一下我以前做《启程输入之星》时说的那句话：因为努力，所以美丽！&
希望能够为您能够喜欢。&
本文已收录于以下专栏：
相关文章推荐
SOUI是什么？SOUI是一个C++ DirectUI库。
虽然DirectUI不是什么新技术，但是要把UI做好，DirectUI确实是目前为止最有效的解决方案。
SOUI不是一个新项目，它是基于...
源于昨天的一个想法，将duilib部分组件化与Delphi的VCL相结合，这样做的原因主要是之前自己也习惯了Delphi的控件拖放设计，因为真的可以省不少时间，现在直接将TDDuiApp(只需放在一个...
例子在这里，包括skia-render,skia-gdi,image-decoder，以及win32 api使用它例子的所有源码。我去掉了skia-render里面的预编绎，这些高级的东西，我不怎么喜...
开源C++界面库
Ringsdk是CSDN上一个前辈自己写的界面库，这个界面库很轻而易举实现QQ2009的界面效果。链接见
http://blog.csdn.n...
记得大一学C语言的时候，觉得黑白窗很无聊，后来在网上找到了EasyX （一个模仿turbo c的图形库） ，用它写一些贪吃蛇、扫雷这类有图形界面的游戏来练手。 当...
刚开始用C++做界面的时候，根本不知道怎么用简陋的MFC控件做出比较美观的界面，后来就开始逐渐接触到BCG
Xtreme ToolkitPro v15.0.1，Skin++,等界面库，以及一些网友自...
SOUI中创建有窗口句柄的xml布局的子窗口
为了运用SOUI完成基本的父子窗口切换问题，同时能够利用xml文件布局窗口界面，就要用到有窗口句柄的真窗口（SOUI这么叫）。每一个使用SOUI...
在soui中，自定义的控件好像不能进行消息订阅，因此采用以下方式实现消息的响应。
1.首先在对话框窗口（从SHostDialog继承的）中自定义windows消息，在BEGIN_MSG_MAP_EX...
上次说到SOUI只是做了一个简单的描述，那么今天我开始进行***和使用。（vs2008+SOUI）
***VS2008
这个就不在说了，网上教程一大堆。
编译源码库
1.1 进入下载的源码库
他的最新文章
讲师：董岩
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)浅谈工作中使用过的几种C 界面库
我的图书馆
浅谈工作中使用过的几种C 界面库
& & &通常一个界面库是否有广大的使用人群，我觉得与以下几个因素有关：支持的操作系统是否多样，支持的操作系统市场占有率是否大，使用是否方便，是否有良好的"所见即所得"（WYSIWYG）的开发工具支持，是否有经济实力的雄厚的大公司支持等等。结合我使用过的的几种C 界面库和大家交流一下。1.MFC(MicroSoft Foundation classes)：相信在windows下进行开发的各位同僚们都用过MFC进行界面开发。我记得自己初次接触MFC是大学毕设一个关于数字图像处理的课题，用的IDE是VS 6.0，那时就干了件“重复造轮子“的事，而且是个大轮子，那时并不知道VS有生成MFC程序的向导，结果坐在电脑前没黑没白的照着一本参考书上的自动生成代码敲了几天几夜，结果很残酷，没运行起来。着实把我吓了一跳，以为开发软件这么难，现在想想MFC的自动生成代码中的有些语言特性直到现在自己也未必完全了解。之后学习了孙鑫的《VC 深入编程》这才算是对MFC渐渐入了门，但是在此后有相当一段时间内都是对MFC只了解其表，会应用，并不了解其本质。直到看了侯捷老师的《深入浅出MFC》才算是对MFC有了本质的认识。（侯捷老师的写作风格很好，这是我第一次真正喜欢上一本计算机书籍）正如侯捷老师所说，要学习MFC首先要对windows程序的事件驱动特性有所了解，消息的产生，获得，分派，判断，处理；还要了解C 的性质（封装，继承，多态）。之后，侯捷老师又仿真了MFC的六大关键技术：MFC的初始化过程，RTTI（执行时类型识别），动态生成，Persistence（永久留存），消息映射，消息绕行，到此为止，MFC已经被剖析的很彻底和细致了，你也可以掌握MFC的本质了吧！我的使用体验：支持MFC的IDE我使用过VS 6.0， 2008， 2010，其中 AppWizard，ClassWizard， Resource Editor让我们能够很快的构建一个MFC程序。我觉得用MFC实现简单的UI功能还是很不错的，但是要实现复杂，美观的UI，编码还是过于复杂（其实有很多基于MFC实现的界面库，有较好的界面效果，但其中有些要收费,我使用过的是Codejock.Xtreme.Toolkit.Pro）。用vs6.0 和 vs 2008 生成的MFC程序还要依赖相应的VC组件运行，生成的可执行程序由于包含了大量的库比较大。vs 2010生成的可执行程序只需附带运行时dll就行。2.WTL(windows 模板库)：一个用来开发 Windows 应用程序的 C 的 UI 组件，它扩展了 ATL (Active Template Library) 提供了一系列的对话框、帧、GDI对象等等。我们使用的的金山卫士就是用wtl开发的....。以下引自《WTL for MFC Programmers 》“WTL 具有两面性，它没有MFC的界面（GUI）类库那样功能强大，但是能够生成很小的可执行文件。如果你象我一样使用MFC进行界面编程，你会觉得MFC提供的界面控件封装使用起来非常舒服，更不用说MFC内置的消息处理机制。当然，如果你也象我一样不希望自己的程序仅仅因为使用了MFC的框架就增加几百K的大小的话，WTL就是你的选择。当然，我们还要克服一些障碍：1) ATL样式的模板类初看起来有点怪异 ；2) 没有类向导的支持，所以要手工处理所有的消息映射。 3) MSDN没有正式的文档支持，你需要到处去收集有关的文档，甚至是查看WTL的源代码。4) 买不到参考书籍 5) 没有微软的官方支持 6) ATL/WTL的窗口与MFC的窗口有很大的不同，你所了解的有关MFC的知识并不全部适用与WTL。&从另一方面讲，WTL也有它自身的优势：1) 不需要学习或掌握复杂的文档/视图框架。 2) 具有MFC的基本的界面特色，比如DDX/DDV和命令状态的自动更新功能（译者加：比如菜单的Check标记和Enable标记）。 3) 增强了一些MFC的特性（比如更加易用的分隔窗口）。 4) 可生成比静态链接的MFC程序更小的可执行文件（译者加：WTL的所有源代码都是静态链接到你的程序中的）。 5) 你可以修正自己使用的WTL中的错误（BUG）而不会影响其他的应用程序(相比之下，如果你修正了有BUG的MFC/CRT动态库就可能会引起其它应用程序的崩溃。&如果你仍然需要使用MFC，MFC的窗口和ATL/WTL的窗口可以“和平共处”。&我的使用体验：谈起使用WTL的过程，很早就听说过它的这些特点，出于对新技术的热情，私下里一直在进行学习，使用的书籍就是《WTL for MFC Programmers》，自我感觉用WTL进行开发非常便利。碰巧工作上接触了一个使用WTL开发的开源软件http://infrarecorder.org/，界面功能效果都很不错，重要的是他几乎用到了WTL的各种常见界面实现，而且封装的相当好，我在这个软件上进行了很多基于WTL和COM的扩充开发，让我学习到了不少WTL和COM的开发经验。另外，金山卫士的部分开源代码我们也可以进行学习。开发环境依然是VS系列，可以下载相应的WTL版本作为插件集成入VS。3.Qt：相比于以上两种界面库，他最大的优点就是跨平台。以下引自开源中国社区“Qt是诺基亚开发的一个跨平台的C 图形用户界面应用程序框架。它提供给应用程序开发者建立艺术级的图形用户界面所需的所用功能。Qt是完全面向对象的，很容易扩展，并且允许真正地组件编程。Qt 具有下列优点:优良的跨平台特性: Qt支持下列操作系统: Microsoft Windows 95/98， Microsoft Windows NT， Linux， Solaris， SunOS， HP-UX， Digital UNIX (OSF/1， Tru64)， Irix， FreeBSD， BSD/OS， SCO， AIX， OS390，QNX 等等；面向对象 Qt 的良好封装机制使得 Qt 的模块化程度非常高，可重用性较好，对于用户开发来说是非常 方便的； Qt 提供了一种称为 signals/slots 的安全类型来替代 callback，这使得各个元件 之间的协同工作变得十分简单；丰富的 API Qt 包括多达 250 个以上的 C 类，还替供基于模板的 collections， serialization， file， I/O device， directory management， date/time 类。甚至还包括正则表达式的处理 功能；支持 2D/3D 图形渲染，支持 OpenGL；大量的开发文档；XML 支持；我的使用体验：仍然是出于对新技术的热情进行的Qt开发，感觉实现复杂的UI功能和效果比以上两种界面库容易的多，我用的IDE是Qt Creator，很炫，但是感觉运行效率上没VS块（当然是windows平台下的体验），特别是逐步调试推进很慢，有时GCC编译器会无响应（也可以选择windows下的编译器），另外发现一点：数据库操作时，Qt对SQLite的封装执行SQL语句很慢，我测试了一下，在sqlite管理工具中执行一条带表关联和分页的SQL语句需要393ms，但是采用Qt封装的SQLite执行需要1410ms，这数量级可差距大了。（究竟是谁的问题？）以上讲了三种自己使用过的C 界面库，业界有很多对三种界面库的对比，优点，缺点，适不适合用云云，我觉得在没有经过实际应用的情况下去否定另一种是不公平的，这在某种程度上也反映了我们对技术的保守心态，有些人还会抵触新的技术，我还是认为最好多学几种相关技术，然后在最合适的场景下去应用，比如如果要进行网络分发客户端的情况下我会抛弃MFC而选择WTL，减少网络数据传输量，要是在跨平台场景下我会首选Qt，你懂的。本文出自 “” 博客，请务必保留此出处
TA的最新馆藏[转]&
喜欢该文的人也喜欢