Über die Vielfalt der Toolbar-Implementierungen

Veröffentlicht: 07. Sep 2001 | Aktualisiert: 18. Jun 2004

Von Paul DiLascia

Es gibt eine unglaubliche Vielfalt an Implementierungen von Symbolleisten. Angesichts dieser Vielfalt stellt sich die Frage, ob man denn unbedingt eine eigene Implementierung eines Steuerelements benötigt.

Streuung und Auslese

Diesen Artikel können Sie hier lesen dank freundlicher Unterstützung der Zeitschrift:

Frage
Ich möchte ein Programm entwickeln, das mir Informationen über die Schaltflächen auf den Symbolleisten aller laufenden Programme liefert. Mir ist aufgefallen, dass das Symbolleistenfenster in praktisch jeder Anwendung zu einer anderen Fensterklasse gehört. Im Windows Explorer und im Spy heißt die Klasse zum Beispiel ToolbarWindow32. Im Visual C++ lautet der Klassenname "Afx:400000:b:1486:10:0" und in Word MsoCommandBar. Außerdem hat es keinen Sinn, einer Anwendung eine Nachricht wie TB_BUTTONCOUNT zu schicken, wenn die Symbolleistenklasse in der betreffenden Anwendung nicht ToolbarWindow32 heißt. Warum gibt es so viele verschiedene Implementierungen für Symbolleisten? Gibt es einen zuverlässigen Weg, um von dieser bunten Vielfalt die gewünschten Informationen zu erhalten? Hätten Sie eine Idee, die mir weiterhilft?

Antwort
Ich verstehe zwar das Problem, aber ich fürchte, dass ich Ihnen keine allgemeingültige Lösung anbieten kann. Die Vielfalt der Symbolleistenklassen ist einfach ein Zeichen dafür, wie sich die meisten Softwaresysteme entwickeln. Übrigens nicht nur Softwaresysteme, sondern die meisten Systeme, nicht zu vergessen das Leben selbst. Nämlich chaotisch. Meistens läuft es ungefähr so: Jemand hat eine Großartige neue Idee. In diesem Fall also Symbolleisten oder "Toolbars". Die Idee fällt auf fruchtbaren Boden, entwickelt sich weiter und gewinnt eine Art Eigendynamik. Plötzlich will jeder so etwas haben, kann nicht mehr ohne leben. Die Entwickler schreiben an Zeitschriften wie das System Journal und fragen: "Wie kann ich eine Symbolleiste in meine Anwendung einbauen?" Andere krempeln die Ärmel hoch und tun es einfach. Das Ergebnis ist? Vielfalt! Dieselbe Idee, viele Implementierungen.

Wenn eine Software-Idee erfolgreich ist, wird sie auch irgendwann in Redmond aufgegriffen. Im Fall der Symbolleisten führte Microsoft eine Gruppe von "common controls" ein, zu denen unter anderem ToolbarWindow32 gehört. Die MFC kapselt die Symbolleiste mit CToolBarCtrl. Auch CToolBar steht für eine Symbolleiste - mit dem kleinen Unterschied, dass die ursprüngliche CToolBar-Version in der ersten MFC-Version sozusagen selbstgebastelt war und gar nicht auf ToolbarWindow32 zurückgreifen konnte.

Im Laufe der Zeit entwickelt sich eine Art Konvergenz. Ältere Anwendungen lassen ihre Spezialimplementierungen zugunsten von allgemeinerem Code fallen, neue Anwendungen setzen von vorne herein die allgemeineren Codeversionen ein. Anders gesagt, es tritt so etwas wie eine Standardisierung ein. In diesem Fall halten sich mehr und mehr Anwendungen, was Symbolleisten anbetrifft, an ToolbarWindow32. Das Leben ist völlig in Ordnung.

Aber nicht lange. Da mehr und mehr "UI-Features" und sonstige Kinkerlitzchen verlangt werden, ist die Versuchung groß, neue Dinge auszuprobieren. Die Standard-Steuerelemente können da nicht mehr ganz mithalten und lassen sich auch nicht hinreichend anpassen. Seitdem es die Listen- und Baum-Steuerelemente gibt, erhalte ich einen steten Zustrom von Anfragen, in denen es darum geht, wie man diesen Steuerelementen neue Tricks beibringen kann. Manchmal, wenn die Entwickler weitsichtig genug waren, lässt sich das Standardelement relativ einfach erweitern. Zum Beispiel via NM_CUSTOMDRAW, wie die Standard-Steuerelemente.
Aber wie weise der ursprünglichen Entwickler auch sein mag, irgendwann kommt der Tag, an dem sich der Originalcode vom Werkzeug zum Hemmschuh entwickelt hat und es einfacher wird, die Symbolleiste, die Schaltfläche, das Menü oder was auch immer "mal eben" selbst zu schreiben.

Wie Sie mit dem Spy++ selbst herausgefunden haben, benutzen sogar Visual C++ und Microsoft Office ihre eigenen Symbolleistenklassen. Die Office-Produkte - Excel, Word, Outlook und so weiter - verwenden so etwas wie MsoCommandBar. Ich kann mir lebhaft vorstellen, wie die Office-Leute um den runden Tisch herum saßen und über die Arbeitsweise der Symbolleiste diskutierten: "Die Standard-Symbolleiste kann das einfach nicht, was wir wollen. Lasst uns eine eigene Version schreiben." Und das ist wohl nicht nur bei Microsoft so gelaufen. Ein schneller Rundblick auf meiner Maschine ergab, das auch andere Anwendungen so verfahren, insbesondere große Anwendungen. Je beliebter ein Programm ist, je mehr Geld die Hersteller mit dem Verkauf verdienen, desto mehr Programmierer können sie sich leisten. Desto wahrscheinlicher wird es, dass die Programmierer ihre eigenen Bibliotheken entwickeln, weil ihnen die Standardklassen nicht reichen.

Bevor wir nun gemeinsam über diese beklagenswerte Situation jammern, möchte ich auf eine wichtige Kleinigkeit hinweisen: Sie ist nur dann beklagenswert, wenn man so etwas wie ein Spy-Programm entwickeln möchte, mit der man in den Symbolleisten von anderen Anwendungen herumstöbern kann. Einem Anwender ist es ziemlich egal, ob sein Programm mit ToolbarWindow32 oder mit MsoCommandBar arbeitet. Ihn interessiert nur, ob das Programm funktioniert und sich leicht bedienen lässt. Wenn die verschiedenen Symbolleisten alles bieten, was man von ihnen verlangt, dann um so besser. Standardisierung ist gut. Standardisierung im Code führt auch zu einer gewissen Standardisierung in der Schnittstelle zum Anwender. Aber zuviel Standardisierung kann auch erdrücken. Eine gewisse Individualität ergibt sich eben nur durch die Abweichung vom Standard.

Bleibt unter dem Strich festzuhalten, dass ich Ihnen keine magische Lösung präsentieren kann, mit der sich jede Art von Symbolleiste erkunden ließe. Statt dessen möchte ich aber die Frage stellen, warum Sie das eigentlich vorhaben? Die einzigen Programmarten, für die ich da einen gewissen Sinn sehe, sind Hilfsprogramme zur Bedienung von Anwendungen durch Behinderte, zum Beispiel durch Anwender mit eingeschränktem Sehvermögen. Bei diesem Anwendungsbereich ist der Rückgriff auf die Accessibility-API sicher die bessere Lösung (Natürlich ergibt sich dabei das Problem, dass auch die entsprechenden Anwendungen auf diese Art der Bedienung ausgelegt sein müssen. Aber das ist ein anderes Thema.).

Wenn Sie trotzdem noch vorhaben, jede einzelne Symbolleiste zu knacken, kann ich Ihnen auch nicht weiterhelfen. Da bleibt Ihnen wohl nur übrig, so viele Spezialfälle im Programm unterzubringen, wie Sie können - und sich mit dem Gedanken anzufreunden, dass eine ganze Reihe von Symbolleisten übrig bleiben, die Ihr Programm nicht auskundschaften kann. Sie werden mit den gängigen Spy-Programmen untersuchen müssen, um welche Fensterklassen und Nachrichten es sich handelt. Es wird trotzdem ein recht mühsamer Weg durch's dichte Unterholz werden, denn es lässt sich nicht in jedem Fall mit Sicherheit sagen, welche Fenster überhaupt für die Symbolleisten vorgesehen wurden. Die Anwendung kann auch reine Phantasienamen verwenden. Und Sie können auch nicht aus dem Umstand, dass "Afx:400000:b:murmel..." im Visual C++ eine Symbolleiste ist, schließen, dass dies auch in anderen Anwendungen der Fall sein müsse. In der einen Anwendung könnte es sich dabei um eine Symbolleiste handeln, in der anderen um etwas gänzlich anderes. Die MFC generiert die Klassennamen mehr oder weniger automatisch, wobei eine Kombination von Fensterformat und den Handles für Cursor, Hintergrund-Farbrolle und Bildsymbol verrechnet wird. Vermutlich werden Sie einige höchst unbefriedigende Zeilen wie die folgende ins Programm aufnehmen müssen:

IF appname="foo" THEN ToolbarClass = "[trage hier den Namen ein]"

Tja!

Die meisten Programmierer werden sich nie die Mühe machen, ein Spy-Programm zu entwickeln, das sich über die Fenster von anderen Anwendungen informiert. Trotzdem sind die oben angeführte Betrachtungen, die hier exemplarisch von Symbolleisten handeln, aus einem anderen Grund wichtig. Als Entwickler stehen Sie ständig vor der Frage, ob Sie Standardkomponenten einsetzen oder lieber eine eigene Version bauen sollen. Es hat nicht nur seine Vorteile, wenn man der erste ist, der die neusten Zierleisten, Melodie-Hupen, Airbags und Nachbrenner im tiefergelegten Programm anbieten kann, sondern auch, wenn man einfach abwartet, bis die gewünschte Funktionalität zum Standardangebot des Betriebssystems gehört. Das spart nämlich viel Zeit und Arbeit. In den meisten Fällen plädiere ich daher für das Abwarten.

Was auch immer Ihr Programm tun soll - Sie sind fast immer besser beraten, wenn Sie sich auf diese Kernaufgaben des Programms konzentrieren. Wenn Sie einen Musikeditor schreiben, dann schreiben Sie einen guten Editor. Wenn Sie ein Portfolio-Programm entwickeln, dann konzentrieren Sie sich auf Aktien und Rentenpapiere. Sorgen Sie dafür, dass die Anwendung funktioniert, zuverlässig arbeitet und hinreichend schnell ist. Wenn Sie das tun, werden die Anwender Ihr Programm mögen und benutzen. Sie können fast schon Gift darauf nehmen, dass kaum jemand das Fernseh-Programm im Info-Dialog vermisst, die fehlende Börsengeschäftsfähigkeit gewisser Büroklammern beklagt oder welcher Schnick-Schnack auch immer gerade in UI-Mode ist.

Ich habe vor kurzem einen der bekanntesten MP3-Spieler ausprobiert. Eine UI vom Feinsten, sollte man meinen. Man konnte die Oberfläche fast schon nach Wunsch mit den edelsten Stoffen neu beziehen. Aber so langsam und träge, dass er mir einfach zuviel CPU-Zeit weggefressen hat. Ich habe ihn wieder gelöscht und benutze nun einen alten Spieler mit ordinären grauen Knöpfen, der so leichtgewichtig und schnell ist, dass mein Pentium ihn kaum bemerkt. Mein Rat lautet also: lassen Sie einfach die Leute in Redmond die wichtigen Steuerelemente entwickeln. Nutzen Sie Ihre Zeit für wichtigere Arbeiten.

Wenn Sie andererseits unbedingt glauben, dass Ihr Erfolg auf jeden Fall von einer nietenagelneuen Schnittstelle zum Anwender abhängt und der Rest der Anwendung bereits tadellos läuft, Sie also mit der Hauptarbeit fertig sind und noch Zeit und Geld investieren können - nun, dann tun Sie's. Das System Journal wird sich auch weiterhin bemühen, Sie durch die entsprechenden Informationen bei Ihrem Vorhaben zu unterstützen.