Chinaunix首页 | 论坛 | 博客
  • 博客访问: 9546992
  • 博文数量: 1227
  • 博客积分: 10026
  • 博客等级: 上将
  • 技术积分: 20273
  • 用 户 组: 普通用户
  • 注册时间: 2008-01-16 12:40
文章分类

全部博文(1227)

文章存档

2010年(1)

2008年(1226)

我的朋友

分类: C/C++

2008-03-17 17:51:16

下载本文示例代码
问题:
    有个朋友编写了一个程序,功能是查找当前所有运行中的应用程序的工具棒按钮信息。结果发现不同的应用程序其工具棒窗口的类名都不相同。例如,用工具(如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。另一方面,如果你实在是觉得必须依赖超酷的用户界面艺术来取胜,并且程序完全能正常运行,外加玩得起的资源的话——那就尽管去做吧。不要管别人怎么想。
祝你好运。
下载本文示例代码
阅读(1846) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~