Awake - An OS X Wake-on-Lan Dashboard Widget

Looking for an easy-to-use OS X Wake-on-Lan Dashboard Widget? Then you are right here. But first things first.

What is Wake-on-Lan

Wake-on-Lan is a feature many network enabled devices implement to switch on the device via the network. If Wake-on-Lan is enabled on the device you just have to send a so called "magic packet" to the device and it turns on. All you need to know about the device is its MAC address, a globally unique id, every network device has. This is especially helpful if you don't have physical access to the device like a server in a datacenter. As there is no real magic in the creation of the magic packet there are lots of applications out there supporting Wake-on-Lan.

Why using a dashboard widget

Even though it seems that the dashboard will die in OS X in the not so far future, there are still some cases where I love to have it. One of these cases is Wake-on-Lan to start up my NAS server whenever I need it. I wanted a tool that doesn't waste any menubar space and just does its job fast and easy.

Do it yourself

As I couldn't find an existing Wake-on-Lan dashboard widget I decided to make one myself. Long story short, here is "Awake":

Awake - An OS X Wake-on-Lan Dashboard Widget
Version: 0.1
Release Date: 29.09.2015

Open up

To make the project available for everybody I released it under the MIT-Zero License. So feel free to use is it in any way you like and check out the github project repository.

MacOS Mail: "Google-Konto: Anmeldeversuch blockiert"

Wer die Meldung "Google-Konto: Anmeldeversuch blockiert" schon einmal bekommen hat, wird sich fragen woran das liegt. In meinem Fall wurde der E-Mail-Abruf auf meinem MacBook Pro in Mail verhindert und ich habe folgende Meldung erhalten.

Anmeldeversuch gesperrt – Google-Konto in MacOS Mail gesperrt

Ursache

Wenn man sich durch den Prozess klickt, erfährt man auch aus welchem Grund Google den Account gesperrt hat.

Ursache der Account-Sperrung

In meinem Fall handelt es sich hier aber nicht um ein ungewöhnliches Ereignis. Die Ursache war ein regulärer E-Mail-Abruf. Das besonders ärgerliche an dieser Meldung ist, dass das Fenster nicht geschlossen werden kann. Es ist modal und auch nach Abschluss der Sicherheitsüberprüfung ist die "Fertig"-Schaltfläche nicht aktiviert. Man muss das Mail-Programm also entweder über die Aktivitätsanzeige oder schneller durch Drücken der Alt-Taste und Rechtsklick auf das Mail-Symbol "Sofort Beenden". Wenn man die Sicherheitsüberprüfung des Google-Kontos erfolgreich durchgeführt hat, kann nach einem Neustart von Mail das Google-Konto wieder online geschaltet werden und der E-Mail-Abruf funktioniert wieder.

Die Quelle allen Übels

Doch was war jetzt eigentlich die Ursache für diese in meinem Fall sporadische Meldung? "Power Nap!" Seit MacOS 10.8 gibt es diese Funktion, die es dem Rechner ermöglicht auch im Schlafmodus verschiedene Dienste auszuführen und hierzu gehört auch das Abrufen von E-Mails. "Power Nap" lässt sich in den Systemeinstellungen unter "Energie sparen" aktivieren. Welche Betriebssysteme und Geräte "Power Nap" unterstützen und weitere Informationen findet man unter folgendem Link bei Apple: Informationen zu Power Nap.

Systemeinstellungen > Energie sparen

Ich konnte bei mir nachvollziehen, dass der Google-Account immer gesperrt wurde, wenn die Mails im Ruhezustand meines MacBook Pros abgerufen wurden. Doch auch hier stellt sich die Frage, warum das passiert. Meine Erklärung hierfür ist, dass der während des Ruhezustands genutzte Systemdienst sich beim Abrufen von Mails anders verhält als das Programm Mail selbst und so die Kontosperrung verursacht.

Lösung

Was kann man also machen um das Sperren des Google-Kontos zu verhindern? Hierfür gibt es entweder die naheliegende Möglichkeit die Funktion "Power Nap" über die Systemeinstellungen zu deaktivieren, was ich getan habe, oder man aktiviert im Google-Konto den Zugriff durch weniger sichere Apps (Link zur dieser Einstellung).

Google-Account: Sicherheitseinstellungen bezüglich weniger sicherer Apps

Das ist allerdings nur möglich, wenn man für seinen Google-Account nicht die Zwei-Faktor-Authentifizierung aktiviert hat.

E-Mail-Bilder mit OCR auslesen - Harvester lernen lesen

Die Impressumspflicht zwingt quasi jeden Betreiber einer Webseite ein Impressum einzubinden. Hier müssen einige persönliche Informationen angegeben werden, was im Internet auch schnell mal missbraucht wird. So ist schon lange bekannt, dass sogenannte Harvester durch einfaches parsen von Webseiten unter anderem E-Mail-Adressen sammeln, die dann für den Spamversand genutzt werden. Aus diesem Grund wurden schon viele Methoden entwickelt, um das einfache Auslesen der E-Mail-Adresse zu verhindern. Einige basieren auf der Manipulation der Anzeige über CSS oder Javascript, da die Harvester, zumindest bis heute, nur den html-Quelltext der Webseiten durchsuchen ohne Javascript und CSS zu interpretieren. Einen interessantes Projekt in diesem Zusammenhang findet man hier: http://www.drweb.de/magazin/wirklich-wirksamer-schutz-fr-e-mail-adressen/

Doch in diesem Artikel möchte ich mich mit einem anderen Schutzmechanismus beschäftigen. Mit der Verwendung von Bildern, auf denen die E-Mail-Adresse geschrieben steht, sollen Harvester ausgetrickst werden, da sie den Text nicht lesen können. Oder etwa doch?

Da ich in mehreren Projekten bereits mit OCR (Abkürzung für: Optical Charater Recognition) in Berührung gekommen bin, also dem computergestützten Erkennen von Schrift in Bilddateien, stellte ich mir die Frage wie sicher diese E-Mail-Bilder wirklich sind. Einem entsprechend programmierten Harvester sollte es doch möglich sein den Text auf den Bilddateien zu erkennen und somit die E-Mail-Adresse zu ermitteln.

Aus der Neugier heraus, ob das wirklich funktioniert, habe ich hierfür ein Testprogramm als Proof-Of-Concept geschrieben. Die Basis für die Erkennung sind 30 selbst erstellte E-Mail-Bilder, die ich mittels verschiedener Onlinedienste erzeugt habe. Um ein möglichst realistätsnahes Ergebnis zu erhalten, habe ich außerdem mehrere übliche Variationen beim Erzeugen angewendet.

service_1_0

service_1_1

service_1_2

service_2_0_0

service_2_0_1

service_2_0_2

service_2_1_0

service_2_1_1

service_2_1_2

service_2_2_0

service_2_2_1

service_2_2_2

service_3_0

service_3_1

service_3_2

service_4_0

service_4_1

service_4_2

service_5_0

service_5_1

service_5_2

service_6_0_0

service_6_0_1

service_6_0_2

service_6_1_0

service_6_1_1

service_6_1_2

service_7_0

service_7_1

service_7_2

Der Programmablauf ist dabei wie folgt:

1. Optimieren der Bilder für die OCR - Da eine OCR meist für die Erkennung von Text auf gescannten Dokumenten optimiert ist, hat diese bestimmte Anforderungen an das Quellmaterial. Die hier verwendeten E-Mail-Bilder wurden deshalb vor der Texterkennung optimiert, um bessere Ergebnisse zu erhalten. Nach vielen Versuchen bin ich bei folgendem Algorithmus angekommen: Bild in Graustufen umzuwandeln, skalieren und dann den Kontrast erhöhen. Ein interessanter Effekt hierbei ist, dass sich dadurch nicht nur die Erkennungsqoute gegenüber dem unbearbeiteten Bild verbessert hat, sondern auch die Verarbeitungsgeschwindigkeit der OCR deutlich erhöht wurde.
2. Auslesen der E-Mail-Adresse aus den Bildern - Da ich es auch schon in anderen Projekten gemacht hatte, lag es nahe die freie OCR-Engine "tesseract" zu verwenden¹. Sie liefert ausreichend gute Ergebnisse, auch wenn die proprietäre Konkurrenz bekanntermaßen bessere Erkennungsraten bietet.

Zum Schluß habe ich das Ergebnis noch manuell kontrolliert, um zu prüfen ob die OCR richtig lag.

Lets go

Programmdurchlauf des EMailImageReader

Nun sollen endlich ein paar Zahlen zu den Ergebnissen folgen, wobei ich mir natürlich bewusst bin, dass die verwendeten Inputbilder keine repräsentative Stichprobe, aber für diesen Test absolut ausreichend sind. Die Verarbeitungszeit der 30 Bilder betrug über mehrere Läufe gemittelt etwa 4,5 Sekunden. Die Erkennungsquote der OCR lag dabei im Durchschnitt bei 33 %. Wenn genügend Inputbilder zur Verfügung stehen ergeben sich daraus 133 korrekt ermittelte E-Mail-Adressen pro Minute, was hochgerechnet fast 8000 E-Mail-Adressen pro Stunde ergibt. Auch wenn klassische Harvester vermutlich eine deutlich größere Leistung durch einfaches Parsen von Webseiten erreichen, ist dies ein beachtlicher Wert.

Wie erwartet war die Erkennung bei Bildern mit sehr speziellen Fonts oder Bildrauschen sehr schlecht. Man muss aber auch anmerken, dass das hier verwendete Programm nur als Proof-Of-Concept bezeichnet werden kann. Es gibt noch einige Möglichkeiten die Erkennungsquote und Performance deutlich zu erhöhen und damit die Anzahl korrekt erkannter E-Mail-Adressen pro Minute.

• Der oben beschriebene Algorithmus zur Bildoptimierung lässt sich zum Beispiel um das Entfernen von Bildrauschen oder eine dynamische Kontrastverbesserung erweitern.
• Die einzelnen Anwendungsschritte lassen sich gut parallelisieren. Durch den Einsatz von Multithreading kann das Suchen und Laden der Bilddateien, die Optimierung der Bilddateien und die OCR gleichzeitig für verschiedene E-Mail-Bilder erfolgen. Die Geschwindigkeit dürfte sich dadurch leicht um den Faktor 5 - 10 erhöhen lassen und ist dann hauptsächlich durch die Systemleistung (CPU für OCR und Internetanbindung wegen Webseiten- und Bilder-Download) beschränkt.
• Durch Optimierung der OCR lässt sich die Erkennungsrate noch deutlich erhöhen. Zum Beispiel ließe sich die OCR trainieren, so dass E-Mail-Adressen besser erkannt werden. Alternativ kann auch eine sogenannte Whitelist angegeben werden, die nur Zeichen enthält, die auch in E-Mail-Adressen zulässig sind. Über ein Wörterbuch, dass die häufigsten E-Mail-Provider-Domains enthält, kann die OCR-Erkennung nochmals deutlich verbessert werden. Man könnte das Wörterbuch sogar beim Crawlen dynamisch um die Domainnamen erweitern, von welchen entsprechende Bildern geladen wurden.

Wie wahrscheinlich ist der Einsatz von OCR bei Harvestern?

Auch wenn es keine technischen Hürden gibt mittels dem hier beschriebenen Verfahren E-Mail-Adressen zu sammeln, gibt es keinen Grund zur Panik. Es ist doch sehr unwahrscheinlich, dass diese Technik von Harvestern verwendet wird, auch in absehbarer Zukunft. Folgende Punkte müssen nämlich bedacht werden:

• Da die OCR-Technologie relativ viel CPU-Leistung benötigt, ist das hier beschriebenene Verfahren deutlich rechen- und somit kostenintesiver als das herkömmliche Parsen von Webseiten.
• Damit ein Crawler möglichst effizient arbeitet, müsste er für die vielen verschiedenen Anbieter und Varianten von E-Mail-Bildern speziell angepasst werden, was einen hohen Aufwand verursacht.
• Manche Anbieter von E-Mail-Bildern bieten die Möglichkeit die Providerdomain als separate Grafik abzubilden (z.B.: @gmail.com) und Textfarben und -größen zu ändern um OCR zur erschwehren. Diese Techniken bieten zwar keinen echten Schutz, empfehle ich aber trotzdem jedem, der auf E-Mail-Bilder nicht verzichten kann oder möchte. Der Aufwand dem Crawler das Erkennen der Grafiken "beizubringen" dürfte auch kaum im Verhältnis zum daraus resultierenden Nutzen stehen.
• Tendenziell werden Personen, die Ihre E-Mail-Adresse mit so viel Aufwand versuchen zu schützen, kaum auf den versendeten Spam "klicken". Die Opferquote dürfte hier viel geringer sein, als unter Personen, deren E-Mail-Adressen unbedarft ins Internet gelangen. Eine teuere Optimierung durchzuführen um danach nicht die primäre Zielgruppe zu erreichen

E-Mail-Bilder sicher nutzen

Auch wenn man vor Lesenden-Harvestern aus oben genannten Gründen keine Angst haben muss, lässt sich der Einsatz von E-Mail-Bildern mit ein paar einfachen Richtlinien weiter absichern:

• Binden Sie das Bild nicht über einen Link zum Hersteller ein, da dieser über das Parsen der Seite Rückschlüsse zulässt. Legen Sie das Bild einfach auf dem eigenen Webspace ab.
• Wenn das Bild über JavaScript / CSS eingebunden wird, kann der Link zum Bild in der Regel nicht durch einfaches Parsen der Webseite ermittelt werden.
• Verwenden Sie keinen Dateinamen, der darauf hinweist, dass auf dem Bild eine E-Mail-Adresse vorhanden ist.

¹ Es ist zwar möglich eine in .NET verwendbare Version von tesseract aus dem Quelltext zu erzeugen allerdings gibt es hierfür auch schon fertige Projekte im Netz, die das Einbinden der OCR deutlich vereinfachen. Ich habe in diesem Fall das Projekt von Charles Weld verwendet: .NET Wrapper für tesseract (GitHub-Link)

PDFs verkleinern mit dem Mac

Auf einem Mac lassen sich PDF-Dateien ohne zusätzliche, meist kostenpflichtige, Anwendungen verkleinern. Hierfür reicht es das Dokument mit der integrierten Vorschau zu öffnen und über den Menüpunkt "Ablage > Exportieren" erneut abzuspeichern. Dabei muss nur der vordefinierte Filter "Reduce File Size" gewählt und gesichert werden.

Mit Filter exportieren

Die Einstellungen des Filters können dabei aber nicht auf eigene Anforderungen angepasst werden. Da Bilder und Fotos mit der Standardeinstellung sehr drastisch komprimiert werden, habe ich einen anderen Weg gesucht und gefunden, um die Grafiken nicht unnötig zu verpixeln. Hierfür muss man lediglich einen eigenen Quartz-Filter erstellen, der die gewünschte Konfiguration enthält. In der Systemanwendung "ColorSync-Dienstprogramm" dupliziert man den Eintrag "Reduce File Size", gibt ihm einem sprechenden Namen und passt die Einstellungen wie gewünscht an.

Duplizieren des System-Filters

Beispiel für höhere Qualitätseinstellungen

Der auf diese Weise erstellte Filter steht leider nicht in der oben beschriebenen Auswahl zur Verfügung, da hier nur die vordefinierten Systemfilter verwendet werden können. Es gibt aber noch einen anderen Weg, der es ermöglicht den eigenen Filter anzuwenden. Man wählt einfach im Kontextmenü der zu verkleinernden Datei im Finder den Punkt "Öffnen mit > ColorSync-Dienstprogramm", wählt unten links den selbst erstellten Filter und wendet diesen an.

Öffnen mit Color-Sync

Eigenen Filter wählen

Wenn das PDF-Dokument vorher große Grafiken enthielt, sollte es nun, abhängig von den verwendeten Einstellungen, verkleinert worden sein. In einem konkreten Fall hatte die Ausgabedatei nur noch 10% der Größe der Ursprünglichen. Aber Achtung: bei zu hohen Qualitätseinstellungen und bereits gut komprimierten PDF-Dokumenten kann es auch vorkommen, dass die Datei durch den Vorgang sogar vergrößert wird.

In abgewandelter Form habe ich diese Vorgehensweise auch an anderer Stelle im Netz gefunden, aber die Kombination mit der Erstellung eines eigenen Filters ist hier entscheidend, um den Grad der Kompression optimieren zu können.

Zu scharf - Wieviel HD brauchen wir wirklich?

Mit Einführung und Verbreitung von HD-Technologie und -Inhalten, besonders im TV-Bereich, hat es angefangen. Doch HD ist uns heute schon nicht mehr gut genug, es muss schon mindestens FullHD sein. Dass sich der Trend weiter fortsetzt, zeigt die sich bereits in den Startlöchern befindliche 4K-Technologie mit der alles noch schärfer und besser werden soll. Aber unser Alltag wird immermehr von Bildschirmen aller Art dominiert, ob Werbetafel, Smartphone, Smartwatch, Tablet PC, Notebook oder der gute alte Monitor. Dabei kommen viele verschiedene Größen, Auflösungen und Technologien zum Einsatz, doch für eine gute Darstellungsqualität sind zwei Faktoren ganz entscheidend: Die Pixeldichte und der Betrachtungsabstand. Idealerweise können wir mit bloßem Auge die Pixelstruktur der Displays nicht mehr wahrnehmen, was die biologisch maximale Bildschärfe beim Menschen darstellt. Technisch lässt sich die Pixeldichte zwar noch erhöhen, wir werden aber keinen Unterschied mehr "sehen" können. Das kann sogar negative Effekte haben, bei einer zu hohen Pixeldichte im Verhältnis zum Abstand lassen sich nicht mehr alle Details wahrnehmen.

Mobile Innovation / Revolution

Der Trend zu hochauflösenden Bildschirmen bei mobilen Geräten wurde am 07. Juni 2010 von Apple mit Vorstellung des iPhone 4 eingeläutet. Eine große Neuerung war der Einsatz eines sogenannten Retina-Displays mit der 2-fachen Auflösung im Gegensatz zum Vorgänger. Einen so hochauflösenden Bildschirm gab es bis dahin in keinem mobilen Gerät, dass auch noch in solch immensen Stückzahlen produziert und verkauft wird. Mobiles HD ist hier somit erstmals bei der breiten Masse angekommen. Auch wenn die Konkurrenz recht lange gebraucht hat gleichzuziehen, bietet sich heute eine Vielfalt hochauflösender Displays in den Geräten unseres Alltags. Es folgt der Vergleich von einigen Geräten bezüglich der Pixeldichte ihrer Displays.

Auch wenn die technischen Eckdaten von manch neuem Gerät in der Hochglanzbroschüre oder im direkten Gerätevergleich beeindrucken mögen, gilt hier auch: Weniger ist manchmal mehr. Wird nämlich die Auflösungsgrenze des menschlichen Auges überschritten, kann man keine Auflösungsunterschiede mehr wahrnehmen. Konkret heißt das, dass Sie im normalen Gebrauch keinen Unterschied sehen werden ob das Display Ihres Mobiltelefons nun mit 300 ppi oder mit 450 ppi auflöst.

Zu Scharf

Wo diese Auflösungsgrenze nun genau liegt ist strittig und nicht nur davon abhängig, ob wir gut oder schlecht sehen, sondern auch vom individuellen Betrachtungsabstand und von der verwendeten Displaytechnologie. Durch die meist unterschiedliche Pixelstruktur von TFT- und OLED-Displays, genügen bei Ersteren schon etwa 220 ppi, wobei letztere bis zu 300 ppi benötigen um die Grenze der menschlichen Sehschärfe, im folgenden Graph gemittelt bei 275 ppi eingezeichnet, zu erreichen.

Alle Geräte, deren Pixeldichte über der horizontalen roten Linie liegt, weißen damit eine für das menschliche Auge nicht mehr erkennbare Pixelstruktur auf. Wie viel der Wert über der Linie liegt ist dabei egal. Wenn man das Diagramm betrachtet muss man spätestens ab dem Sony Experia Z2 von einer unnötig hohen Auflösung sprechen. Ein konkretes Beispiel hierfür ist Folgendes:

"Der Bildschirm hat 1920 × 1080 Bildpunkte statt 1280 × 768 wie beim Nexus 4. Mit bloßem Auge lässt sich der Unterschied allerdings kaum erkennen, denn beide Anzeigen wirkten gestochen scharf." (Google Nexus 5 Gerätetest bei Heise.de)

Dabei sollte man nun noch anmerken, dass diese Übertreibung für den Nutzer keinen echten Vorteil, dafür aber Nachteile mit sich bringt. Die wichtigsten negativen Effekte einer zu hohen Pixeldichte dürften Folgende sein:

• Die Kosten für Displays mit höherer Pixeldichte (bei gleicher Panelgröße) sind höher, somit die entsprechenden Geräte teuerer.
• Bei gleicher Paneltechnologie z.B. TFT führt eine Erhöhung der Pixeldichte in der Regel zu einem höheren Energiebedarf und somit zu geringerer Laufzeit.
• Zur Darstellung von Inhalten in höherer Auflösung wird zusätzlich der Prozessor und die Grafikeinheit stärker belastet, was wiederum zu einer geringeren Leistung und Laufzeit führt.

Für den Endnutzer bedeutet das konkret: Teurere Geräte mit kürzeren Akkulaufzeiten. Besonders bei Smartphones spielt der letzte Faktor aber eine ganz entscheidende Rolle.

Fazit

Auch wenn der Griff zu einem bestimmten Smartphone-Modell häufig nicht auf Grund detaillierter Analyse technischer Details erfolgt, lohnt es sich die Sinnhaftigkeit mancher "Features" zu hinterfragen. Es scheint allerdings, als würden vielen Herstellern Mut und Ideen für weitere Innovationen im Smartphone-Sektor fehlen, so dass man von Modell zu Modell die Devise verfolgt: "Größer, Schneller und Hochauflösender", egal ob das für den Nutzer überhaupt vorteilhaft ist, oder nicht.

Ribbon XML in Microsoft Office Addins

Der folgende Artikel befasst sich mit der Erstellung von Oberflächenelementen in Microsoft Office Addins, welche Probleme autreten können und wie man Sie lösen kann. Die Code-Snippets und das am Ende des Posts bereitgestellte Beispielprojekt beziehen sich auf ein Outlook-Addin, die verwendeten Techniken lassen sich aber auch direkt auf Word- oder Excel-Addins anwenden.

Designer vs. XML

Wenn man mit Visual Studio eine GUI für ein Microsoft Office Addin erstellen möchte hat man die Wahl, ob man mit dem grafischen Designer oder direkt im XML-Editor arbeiten möchte. Sicherlich ist die erste Variante einfacher, beschränkt sich aber auf das Erstellen von Ribbons. Manche Anpassungen der GUI, wie zum Beispiel das Kontextmenü, können somit nur per XML-Datei manipuliert werden. Leider lassen sich die unterschiedlichen Methoden nicht mischen¹, man muss in komplexeren Szenarien durchgängig die Oberfläche in XML beschreiben.

Neben dem geringeren Komfort für den Entwickler gibt es aber noch weitere Schattenseiten. Besonders dynamische Oberflächen, die Lokalisierung verwenden oder Elemente bedingt ausblenden, sind hiermit recht umständlich abzubilden. Der größte Nachteil kommt aber zum tragen, wenn man verschiedene Oberflächenelemente, wie Ribbon und Kontextmenu, unabhängig voneinander bei unterschiedlichen RiddonIDs verwenden möchte. Hierzu muss man nämlich für jede Kombination der Elemente eine eigene XML-Datei erstellen. Damit sinkt wiederum die Wartbarkeit und Wiederverwendbarkeit des Quellcodes. Doch dieses Problem lässt sich beheben. Warum beschreibt man nicht einfach jedes Oberflächenelement in einer XML-Datei und fügt sie dann im Programmcode zur konkreten Oberfläche zusammen?

Funktionsweise von Ribbon XML

Zum besseren Verständnis der ganzen Lösung beschreibe ich nochmal kurz die Funktionsweise von Ribbon XML. Wenn man dem AddIn-Projekt ein Ribbon XML Element hinzufügt wird nicht nur eine XML-Datei, sondern auch eine zugehörige Klasse erzeugt. Der Hook für die Ausführung von Ribbon XML ist die Funktion "CreateRibbonExtensibilityObject()" in der ThisAddin-Klasse.

Hiermit wird beim Laden der grafischen Oberfläche die Funktion "GetCustomUI" in der Klasse "CustomUIManager" aufgerufen und bietet damit die Möglichkeit eigene Oberflächenelemente zu erstellen. Wenn man mehrere getrennte Oberflächenelemente erzeugen können möchte und damit mehrere XML-Dateien verwendet, muss eine der automatisch erzeugten Klassen als Controller verwenden, die dann die Oberflächenerstellung übernimmt. Genau dort steckt auch der Kern der ganzen Lösung. Abhängig von der an die Funktion "GetCustomUI" übergebenen RibbonID, wird das entsprechende RibbonXML-String erzeugt und zurückgegeben. Die RibbonID ist ein String der angibt welcher Teil der Anwendungsoberfläche gerade geladen wird. Eine vollständige Liste der RibbonIDs in Microsoft Outlook kann im MSDN nachgelesen werden. Die restlichen Office-Anwendungen besitzen keine so komplexe Unterteilung der Oberfläche und verwenden jeweils nur eine RibbonID (im Einzelnen Microsoft.Word.Document, Microsoft.Excel.Workbook und Microsoft.PowerPoint.Presentation).

Auf den ersten Blick mag es vielleicht etwas unübersichtlich aussehen, ist aber ganz einfach. Jedes mal wenn die Oberfläche geladen wird, z.B. beim Anwendungsstart oder durch Interaktion des Nutzers, wird die Funktion "GetCustomUI" aufgerufen. In dieser wird dann die XML-Repräsenation der eigenen Oberflächenelemente erzeugt und zurückgegeben. Die einzelnen Schritte sind:

1. Prüfen ob für die übergebene RibbonID eine eigene Oberfläche erzeugt werden soll.
   • ja: weiter mit den folgenden Schritten 2 bis 4
   • nein: sofort zurückkehren um die Ausführung nicht zu blockieren
2. Lokalisieren der erzeugten Oberfläche mit der Funktion "LocalizeRibbonXML". Hierfür werden lediglich alle Einträge einer Ressourcendatei geladen um die Texte der Oberfläche zu setzen.
3. Bedingtes Ausblenden von Elementen mit der Funktion "HideRibbonXMLElement". Hiermit könnnen einzelne Oberflächenelemente, falls sie aus bestimmten Gründen nicht angezeigt werden sollen, ausgeblendet werden.
4. Zurückgeben des erzeugten XML-Strings.

Außerdem habe ich noch die Funktion "OnRibbonElement_Click" für das Eventhandling hinzugefügt um Nutzereingaben entsprechend behandeln zu können.

Das Vorgehen setzt natürlich vorraus, dass die verwendeten XML-Dateien keine XML-Header und CustomUI-Tags enthalten, der Inhalt der Datei "OUI_ContextMenu.xml" sieht bei mir zum Beispiel so aus:

Zum Ausprobieren, Weiterentwicklen und Wiederverwenden habe ich mein vollständiges Visual Studio 2010-DemoProjekt für ein Outlook 2010-AddIn zum Download angehängt. Das Konzept wurde ebenfalls mit Visual Studio 2012 und Office 2013 getestet, kann also auch in neueren Projekten angewendet werden.

1 Es ist nicht ganz richtig, dass sich Designer- und XML-Methode nicht in einem Projekt gemeinsam verwenden lassen. Wenn man die Funktion "CreateRibbonExtensibilityObject()" in der ThisAddin-Klasse, die für die Verwendung der XML-Methode benötigt wird.