关于工具棒的一点看法

　2010-01-09 20:31:53　来源：WEB开发网　　　

核心提示：问题：有个朋友编写了一个程序，功能是查找当前所有运行中的应用程序的工具棒按钮信息，关于工具棒的一点看法，结果发现不同的应用程序其工具棒窗口的类名都不相同，例如，并且程序完全能正常运行，外加玩得起的资源的话——那就尽管去做吧，用工具（如Spy）可以查到资源管理器的工具棒窗口类名为Toolbar

问题：

有个朋友编写了一个程序，功能是查找当前所有运行中的应用程序的工具棒按钮信息。结果发现不同的应用程序其工具棒窗口的类名都不相同。例如，用工具（如Spy）可以查到资源管理器的工具棒窗口类名为ToolbarWindow32；VC的是Afx:400000:b:1486:10:0；Word为MsoCommandBar。真是名堂多多。还发现非ToolbarWindow32工具棒窗口类名的应用程序中发送类似TB_BUTTONCOUNT的消息会失败。为什么会有这样名目繁多的工具棒呢？有没有比较通用的方法来获得有关它们的信息？

解答：

导致存在多种工具棒类的原因完全是人为所致——

如果一个软件思想是成功的，微软基本上都要将它吸收。就拿工具棒来说，微软引进了一组通用控件（common control），这一组控件包括ToolbarWindow32以及其它的控件。MFC用ToolBarCtrl封装了这些东西，CToolBar也一样——事实上在第一版MFC中，原始的CToolBar很简陋，也没有使用ToolbarWindow32。

随着时间的流逝。老的应用程序代码逐渐被丢弃，新的应用程序开始使用新的东西。换句话说，标准化保证了越来越多的应用程序使用ToolbarWindow32作为其工具棒。但是时间一过，出现了更多的UI特性，新事物总是诱人的。标准控件不满足要求并且也不能充分地定制它们。即便有了列表视和树形控件，仍然有很多问题是关于如何用它们做这做那。有时，如果最初的设计者多为以后考虑一下，标准的东西以某种方式自己扩展——象通用控件的NM_CUSTOMDRAW。但不管最初的设计多么有远见，总有一天它会陈旧过时，并且很容易编写自己更满意的工具棒、按钮、菜单和其它的什么。

正像用Spy++所发现的那样。Visual C++ 和 Microsoft Office都是用他们自己各自的工具棒类。Office产品——Excel, Word, Outlook(r)等使用的是MsoCommandBar。可以想象写Office程序的那帮家伙围着会议桌讨论：“标准的工具棒不能满足我们的需要，所以我们还是自己写一个吧。” 。不仅仅微软如此，从自己机器上做一个快速调查就知道，其它的应用程序也是如此，尤其是“大的”应用。某个程序越流行，公司卖的钱就越多，公司就能雇更多的程序员，可能就有更多的程序员建立和维护他们自己的复制标准类的库。

在你为这种情形沮丧之前，记住：如果你试图编写某种能窥探其它应用程序工具棒的类似spy的程序的话，那么你也只有沮丧的份了。如果你是一个用户，你一点都不会在意你的应用程序工具棒使用的是ToolbarWindow32 或者MsoCommandBar.。你只在意这个程序的运行和容易使用。如果不同的工具棒给了你更多你喜欢的特性反而更好！标准化好，代码的标准化给予了UI的标准化——但太多的标准化有时也让人压抑。就象在动物王国，多样性促使创新。

没有办法，我无法施展魔术让你窥视每种工具棒。反而要问你为什么要这么做？我认为需要这样做的唯一一种应用程序是“易接近”应用（如为盲人做的改进应用），并且即使这么作也是使用专门的API（Accessibility API），它提供了所需的钩子（当然这里的问题是首先应用本身必须使用，应该另当别论）。

如果你仍然不顾一切还是想要搞掂每个工具棒，那你只会一无所获，因为这么多不同的工具棒你是无法一个一个搞掂的，只能接受这个事实。再说使用SPY工具所收集的窗口类及信息也不一定就是实际应用中的工具棒：程序使用类名是随意的，你不能先入为主地说因为 “Afx:400000:b:mumble...”是Visual C++的工具棒，那它也使其它程序的工具棒。也可呢在这个程序中是工具棒，但在其它程序中可能就是别的什么东西。MFC自动为类取名字，组合窗口风格、光标、背景刷和图符处理。你大概得插入一些可笑的代码，如：

IF appname="foo" THEN ToolbarClass = "[在这里插入名字]"

大笑......

大多数程序员决不会编一个类似spy的程序来探视其它应用的窗口类名，除非有别的理由。作为一个开发人员，你常常会面临这样一种选择，“我是使用标准的组件还是建立自己的组件？”总是要在首先具备某种新的 GUI特性和等待操作系统来提供这种特性之间权衡。在大多数情况下，我主张等待。

不管什么应用，应该把精力多集中在应用本身上面，也就是说，多考虑应用要做写什么。如果你正编写一个WAVE文件编辑器，就要所考虑将它做成很棒的编辑器。如果你做一个证券投资程序，那就要多考虑股票和分红。运行速度快、可靠。如果你这样做了，用户会喜欢并热衷使用你的程序，我完全敢说没有人会注意你的程序有没有COOLBAR或者菜单按钮，个人化菜单或其它什么最新的GUI小玩意儿。Napster程序没有这些东西，甚至按钮看起来也很笨重。——但每天多有成千上万的人在使用它！为什么呢？ ——因为它有价值。最近我试用了一下最流行的MP3播放器，华丽的界面让人眼花缭乱，我拿它和普通灰色按钮的老式MP3播放器比较了一下，两者的速度简直不能同日而语，它占用太多的CPU时间。因此，我主张：让微软去为你写GUI。另一方面，如果你实在是觉得必须依赖超酷的用户界面艺术来取胜，并且程序完全能正常运行，外加玩得起的资源的话——那就尽管去做吧。不要管别人怎么想。