程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> C語言 >> VC >> 關於VC++ >> 關於工具棒的一點看法

關於工具棒的一點看法

編輯:關於VC++

問題:

有個朋友編寫了一個程序,功能是查找當前所有運行中的應用程序的工具棒按鈕信息 。結果發現不同的應用程序其工具棒窗口的類名都不相同。例如,用工具(如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。另一方面,如果你實在是覺得必須依賴超酷的用戶界面藝術來取 勝,並且程序完全能正常運行,外加玩得起的資源的話——那就盡管去做吧。不要管別人怎 麼想。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved