去年微软的 Visual Studio.net 2008 SP1 出来之前，就有个 Visual C++ Feature Pack 先放了出来，其中一个重大更新就是集成了 BCGControlBar 的一部分内容。但是经历了 beta 版本时很多用户的反对意见和质疑之后，最终还是出了正式版，并最终在 VS SP1 中集成了这个 Feature Pack。但是一年多来几乎天天和这套更新版本的 VC 组件打交道之后，不得不说微软这次举措严重错误，是做了一次效果极其微小的，工作量和精力却花费巨大的更新。

BCGControlBar 原本是一套开源的界面组件套装，早在 Office 2000 开始推行的时候，是全球较先（也许是除了微软之外的最先）实现 Office 界面组件克隆的一套组件，后来由于发展顺利，最终成为商业版并拥有大量从开源版带来的用户。其实这套组件用起来确实不错，在当时来说称得上是极品，即使是成为商业组件之后，BCGSoft 仍然提供免费的非商业版本供个人非商业用途使用。它可以提供非常多种只需简单的几十行代码就能实现的时髦界面，免去很多人和软件公司在界面组件程序设计花费的大量精力（当然钱力就少不了了）。而微软这次集成显得非常失败，下面是我的体会：

• 集成得非常不完整。BCGControlBar 的大部分组件的最基础的功能都有集成，但是由于只有最主要的功能被集成，就限制了开发者的发挥。比如 Ribbon 界面，表面上看似很具优势，但是真正使用下来你才发现，这个 Ribbon 界面是非常不完整的。Ribbon 的主 Frame 风格在 Vista Aero 之外的场合，是忽略 Windows 主题和传统风格的 Office 2007 窗口边框风格，而这个边框风格是不可控的，除了主 Frame，所有其他窗口都不具备这个风格。想像一个程序，在 Windows XP 里运行的主界面边框像 Office 2007，而除了主界面的其他所有内容都是 Windows XP 的 Luna 风格，那是多么怪异的一种界面。所以 Ribbon 的使用范围就被软性限制在主界面了。但是有多少软件只有主界面，没有对话框（包括除主窗口之外的所有窗口）？
• BCGControlBar 的架构即复杂又不灵活，在今时今日，技术已经略显落后。既然大部分组件只集成了基础功能，显然如果要让我们在整套软件的开发工作得到统一，很多工作就必须在原本这些基础功能上面进行扩展。但是 BCGControlBar 作为一个即成产品直接套用就没有严重的问题，但是当它不完整，很多工作要在原先的组件上扩展的时候，甚至即使是完整的，我们仍然经常会遇到需要在原基础类上面进行扩展的时候，你将发现你正在挑战一项高难度的工作，而且不久之后你会怀疑你的工作并不比微软的集成工作更轻松。简单一句话，就是组件的架构太封闭。
• 用 ToolBar 做自己工具的容器？没门！
• ToolBar Label？没有！
• ToolBar CheckBox？改用 Ribbon！
• CMFCShellTreeCtrl 唯一给你定制的地方是 IShellFolder::EnumObjects 的其中一个参数，这个参数无论怎么组合，都得不到一个和 BrowseForFolder 一样的只有驱动器和文件夹的列表，总是会把 ZIP 文件认为是文件夹，想要在列表中过滤掉不想要的行（比如你不想要列出回收站），唯一的方法是自己完全重写整个 EnumObjects 的调用过程！不过如果自行派生 CMFCShellTreeCtrl，你的程序就有可能无法通过 Link，因为 CShellManager 有个 bug，动态链接 MFC 库使用 CShellManager 会出错。所以目前的办法是自己重新写一个 ShellTreeCtrl！真的很变态。
• Ribbon 提供了很多工具，而用于 ToolBar 的工具太少，要自己扩展，找来找去除了能找到对样式的扩展方法之外（比如自绘外观），这套组件几乎不考虑用户对功能的扩展！
• 想动态更换工具栏按钮的图标，菜单图标也会自动被更换，菜单和工具栏的图标在一开始可以分别指定不同尺寸，但是动态更换的图标就不能！
• 想运行时隐藏工具栏的一个按钮，它会记录进注册表，下次程序启动除非你的程序显式的显示这个按钮，否则这个按钮就永远消失，你想找一个暂时性的方法？没有！
• 看中了 Ribbon 的颜色方案，又喜欢 VS.net 2005 的外观风格，没有任何方式可以组合这两者，唯一可以做得到的就是根据 Ribbon 和 VS.net 2005 的 VisualManauger 那几千行代码，自己重新写一个！
• 文档极其不完整，内容也错漏不少，大部分内容搜索跟随 VS.NET 2008 SP1 更新的文档，得到的内容就是 This topic is under construction！借助在线文档有些内容已经得到补充，但是说明远远不及原来 MFC 文档详细，看完还不知所云不知道究竟怎么用是经常的事。唯一可以依靠的就是最新的 VC 示例程序，里面有 Feature Pack 的最新示例，当然看之前得有心理准备，面对类似为按钮设置图标的示例，前面几个按钮用一个实现，后面几个按钮用另外一个实现，而看完却不知道究竟为什么前面几个按钮要这么实现，后面几个按钮要那么实现，最后试了一下发现两个都能实现，这样的事情，要抑制住突然想砸键盘的冲动。
• 功能分类很不合理。经常一个类的某个方法要调用到很远很远的另外一个类的另一个方法，最后完全无法联想为什么这两个类必须结合在一起才能用。
• Bug 不少，更新不知道要等到何年何月。如果用商业版 BCGControlBar，还能等待官方更新，用微软买来的这个不完整的问题很多的版本，发现有个非用不可的功能有致命的 Bug，都不知道要等到哪年才能有补丁。SP2？那是最早啦。
• 界面的渲染很糟糕。Ribbon 除了像 Office 2007 的 Ribbon 之外，大部分细节都和 Ribbon 相差很远，比如颜色，尺寸，阴影，鼠标行为，响应时间，几乎都和 Office 2007 不一样。外观不一样没什么，也就没那么精致而已，但是加上上面一大堆的不方便，你还有心情继续用这套组件吗？
• 最后值得安慰的好处就是类似 CSettingStore，CDrawingManager 之类的类，还是比较实用的。只是里面我用过的大部分觉得实用的类，我自己已经有过封装，因为也是三两下的简单事情。
• 再最后，最不值得安慰的是如果这个这么糟糕的东西我不想用，发布程序时仍然要带上那个因为增加了这些组件而从 1.x M 激增到 3.x M 的巨大身材的运行库，而我也为了不浪费这个超大身材就用起了这套糟糕的组件，最后后悔不已。

我用过一套软件，它的界面使用的是 CodeJock 的组件，看起来组件做的很细致。在易用性方面如何我就不知道，但是至少作为一套在功能上极难扩展，又在界面上完全不精致的 BCGControlBar 精简版，我觉得 CodeJock 更有前途。如果不是非要 Native 组件，DevExpress 的 WinForm 组件我觉得很好用（他们的 Asp.net 组件也很强，只是不及 WinForm 的那么强），架构设计的非常开放和灵活，也很合理，很容易扩展，在各个细节方面做得很值得称赞，更重要的是，几乎每次版本更新都能给人激动人心的新特性，而 Bug 的修正非常及时，售前售后的技术支持都很到位。

总之，用了微软这次集成的 BCGControlBar，觉得非常糟糕，用这些东西的时候开发的时间很多都要浪费在界面组件的扩展上，完全没有使用现成组件提高效率的好处。考虑到既然这些内容是从最新的商业版 BCGControlBar 移植过来的，商业版的灵活性和可扩展性也让人却步。