Microsoft Office

Die neue JavaScript-API für Office

Stephen Oliver
Eric Schmidt  

Dieser Artikel ist der erste in einer Reihe von ausführlichen Betrachtungen der JavaScript-API für Office, die in Microsoft Office 2013 neu eingeführt wurde. Der Artikel setzt voraus, dass Sie mit Apps für Office vertraut sind. Andernfalls finden Sie auf der MSDN-Dokumentationsseite „Übersicht über Apps für Office“ (bit.ly/12nBWHG) eine Übersicht über die API und eine allgemeine Einführung in die API.

In vorliegenden Artikel und den weiteren Artikeln dieser Reihe wird die API zwar nicht erschöpfend, aber sehr ausführlich erläutert. Wir schneiden wichtige Aspekte an, durch die Sie gründliche und umfassende Kenntnisse der Funktionsweise der Apps für Office-API erhalten.

Im ersten Artikel behandeln wir das Apps für Office-Objektmodell. Schwerpunkt des zweiten Teils ist, wie der Zugriff auf den Inhalt von Office-Dateien funktioniert. Außerdem erläutern wir das Ereignismodell. Der dritte Teil widmet sich dem Konzept der Datenbindung und beleuchtet die Grundlagen der Arbeit mit benutzerdefinierten XML-Elementen. Im vierten Teil wird die Reihe schließlich mit einer genauen Betrachtung von Mail-Apps beendet.

In der gesamten Reihe verweisen wir häufig auf die Apps für Office-API-Dokumentation. Sie finden die offizielle Dokumentation, Codebeispiele und Communityressourcen im MSDN-Entwicklercenter für Apps für Office und SharePoint (dev.office.com).

Übersicht über die JavaScript-API für Office

Die JavaScript-API für Office umfasst ein vollständiges Objektmodell. Die API ist in einem Satz von JavaScript-Dateien enthalten, beginnend mit der Datei „office.js“. Damit eine App die JavaScript-API für Office verwenden kann, muss sie einen Verweis auf die Datei „office.js“ umfassen. Beim Laden lädt die Datei „office.js“ die anderen Skripte, die erforderlich sind, damit sie funktioniert, einschließlich der Skripte für die Hostumgebung und die Gebietsschemazeichenfolgen. Erfreulicherweise können Sie den Verweis auf die Datei „office.js“ mithilfe eines Netzwerks für die Inhaltsübermittlung (Content Delivery Network, CDN) hinzufügen und müssen daher keine Kopie der Datei „office.js“ zusammen mit Ihrer App bereitstellen. Im Folgenden finden Sie ein Beispiel:

    <!-- When deploying an app, you should always
      load the CDN version of the office.js file. -->
    <script src=
      "https://appsforoffice.microsoft.com/lib/1.0/hosted/office.js">
    </script>

Beim Design des Objektmodells wurden mehrere Ziele berücksichtigt:

1. „Einmal schreiben, überall ausführen.“ Das Objektmodell musste erweiterbar sein. Es sollte nicht an eine bestimmte Hostanwendung gebunden sein, sondern für Funktionen erstellt werden, die in mehreren Hostanwendungen verfügbar sind. Die Apps greifen auf hostspezifische Funktionalität auf einheitliche Weise zu.
2. Plattformübergreifend. Die Kompatibilität war ebenfalls eine Toppriorität beim Design. Das Objektmodell ist daher nicht an eine bestimmte Version von Office gebunden. Bei entsprechender Unterstützung funktioniert außerdem derselbe Code für die Web App-Versionen der Office-Clientanwendungen. Eine App für Excel kann beispielsweise für Excel Web App genauso gut funktionieren wie in der Excel-Clientanwendung.
3. Leistung und Sicherheit. Das Objektmodell musste auf eine optimale Leistung ausgerichtet werden, damit die Apps für die Benutzer so unauffällig wie möglich ausgeführt werden können. Die JavaScript-API wurde zudem für die direkte Interaktion mit Dokumenteninhalt entworfen, ohne dass Office-Anwendungen automatisiert werden müssen. Stabilität und Sicherheit der Lösungen wurden somit verbessert.

Ein weiteres wichtiges Ziel für die JavaScript-API war, Webentwickler für die Office-Plattform zu gewinnen. Das Objektmodell wurde daher unter dem Gesichtspunkt der modernen Webprogrammierung erstellt. Wenn Sie Apps in Verbindung mit der JavaScript-API für Office erstellen, können Sie Ihre aktuellen Kenntnisse über andere JavaScript-Bibliotheken wie beispielsweise jQuery und die Fähigkeiten, die Sie hinsichtlich dieser Bibliotheken bereits haben, nutzen.

Das asynchrone Programmierungsmuster

Wie bereits erwähnt war beim Design der Apps für Office-API die Leistung ein wichtiges Ziel. Eine der Methoden, die von den Entwicklern zur Verbesserung der Leistung der API eingesetzt wurde, war die verstärkte Nutzung von asynchronen Funktionen.

Durch die Verwendung asynchroner Funktionen wird vermieden, dass eine App während der Ausführung blockiert wird, wenn eine Funktion nicht umgehend zurückgegeben wird. Die asynchrone Funktion wird aufgerufen, aber die Programmausführung wartet nicht darauf, dass die Funktion zurückgegeben wird. Die Ausführung dauert stattdessen an, während die asynchrone Funktion weiterhin ausgeführt wird. Die Benutzer können daher das Office-Dokument weiter verwenden, während die App möglicherweise noch arbeitet.

Die folgenden wichtigen Punkte geben Ihnen einen Einblick in die Funktionsweise des in diesem Abschnitt beschriebenen asynchronen Designs der Apps für Office-API:

• Die allgemeine Signatur der asynchronen Funktionen in der Apps für Office-API
• Die Verwendung optionaler Parameter in asynchronen Funktionen
• Die Rolle des AsyncResult-Objekts in asynchronen Funktionen

Wir gehen nacheinander auf diese Themen ein.

Allgemeine Signatur der asynchronen Funktionen in der Apps für Office-API Alle asynchronen Funktionen in der Apps für Office-API verfügen über dieselbe Benennungskonvention und dieselbe grundlegende Signatur. Alle Namen von asynchronen Funktionen enden wie das Beispiel „Document.getSelectedDataAsync“ mit „Async“.

Die Signatur aller asynchronen Funktionen folgt dem folgenden Basismuster:

functionNameAsync(
    requiredParameters,
    [, options], [callback]);

Den erforderlichen Parametern folgen zwei weitere Parameter: ein Objekt, dass optionale Parameter enthält, und eine Rückruffunktion. Beide sind immer optional.

Optionale Parameter in asynchronen Funktionen Das optionale JavaScript-Objekt in der Signatur von asynchronen Funktionen ist eine Collection aus Schlüssel-Wert-Paaren, durch einen Doppelpunkt getrennt, wobei der Schlüssel der Name des Parameters ist und der Wert die Daten darstellt, die Sie für diesen Parameter verwenden möchten. Die Reihenfolge der Schlüssel-Wert-Paare ist nicht von Belang, solange der Parametername richtig ist. In der MSDN-Dokumentation für jede asynchrone Funktion wird angegeben, welche Parameter in dem options-Objekt für diese bestimmte Funktion zur Verwendung verfügbar sind.

Die Document.setSelectedDataAsync-Methode besitzt zum Beispiel dieselbe grundlegende Signatur, die alle asynchronen Funktionen in der Apps für Office gemeinsam haben:

Office.context.document.setSelectedDataAsync(
  data [, options], callback);

Wie alle asynchronen Funktionen in der API besitzt die Document.set­SelectedDataAsync-Methode ein options-Objekt, das optionale Parameter enthält. Die Parameter für das options-Objekt unterscheiden sich jedoch von denen für andere asynchrone Funktionen in der API, da der Zweck dieser Funktion darin besteht, Daten festzulegen. Die optionalen Parameter für „Document.setSelectedDataAsync“ beziehen sich daher auf das Festlegen von Daten:

• „coercionType“: Eine CoercionType-Enumeration, die das Format für die Daten bestimmt, die eingefügt werden (Text, HTML, OOXML, Tabelle oder Matrix).
• „asyncContext“: Ein benutzerdefiniertes Objekt, das unverändert in dem AsyncResult-Objekt zurückgegeben wird, welches an die Rückruffunktion als deren einziger Parameter übergeben wird.

Dasselbe Konzept trifft für alle anderen asynchronen Funktionen zu.

Sie können das Objekt, das die optionalen Parameter als ein Objektliteral enthält, entweder inline im asynchronen Funktionsaufruf bereitstellen oder zuerst ein Objekt erstellen und dieses anschließend an den Parameter übergeben. Die folgenden zwei Codebeispiele zeigen die beiden Möglichkeiten zum Bereitstellen des options-Objekts mithilfe der Document.setSelectedDataAsync-Funktion.

Übergeben der Optionsparameter inline:

function setData(data) {
  Office.context.document.setSelectedDataAsync(data, {
  coercionType: Office.CoercionType.Text }  
  );
}

Übergeben der Optionsparameter in einem JavaScript-Objekt:

function setData(data) {
  var options = { coercionType: Office.CoercionType.Text };
  Office.context.document.setSelectedDataAsync(data, options );
}

Die Rolle des AsyncResult-Objekts in asynchronen Funktionen Der dritte Parameter in der gemeinsamen Signatur für asynchrone Funktionen in der JavaScript-API für Office ist der optionale Rückrufparameter. Der Rückrufparameter entspricht genau seinem Namen: eine von Ihnen bereitgestellte Funktion, die aufgerufen wird, wenn der asynchrone Vorgang abgeschlossen wird. Sie können natürlich entweder eine benannte Funktion oder eine anonyme Funktion inline im Aufruf der asynchronen Funktion bereitstellen. Wichtig dabei ist die Rolle des AsyncResult-Objekts hinsichtlich der Rückruffunktion.

Wenn die Laufzeit Ihren Rückruf aufruft, übergibt sie als einziges Argument für den Rückruf ein Async­Result-Objekt. Das AsyncResult-Objekt enthält Informationen über den asynchronen Vorgang, zum Beispiel ob der Vorgang erfolgreich war oder nicht, welche Fehler möglicherweise auftraten und ggf. den Rückgabewert der asynchronen Funktion. Das AsyncResult-Objekt ist tatsächlich in allen asynchronen Funktionen, die irgendeine Form von Daten oder ein Objekt zurückgeben, die einzige Möglichkeit, auf den zurückgegebenen Wert zuzugreifen. Dazu verwenden Sie die AsyncResult.value-Eigenschaft.

Der folgende Codeausschnitt zum Beispiel ruft die Größe des Dokuments ab und zeigt sie im angegebenen HTML-Element in der Benutzeroberfläche der App an. Um die Dateigröße zu erhalten, rufen Sie zuerst das Dateiobjekt ab, das die Document.getFileAsync-Methode über die AsyncResult.value-Eigenschaft zurückgibt. Dazu gehen Sie folgendermaßen vor:

function getFileData(elementId) {
  Office.context.document.getFileAsync(Office.FileType.Text,
  function (asyncResult) {
    if (asyncResult.status === 'succeeded') {
      var myFile = asyncResult.value;
      $(elementId).val(myFile.size);
    }
  });
}

Die getFileData-Funktion ruft die Document.getFileAsync-Methode auf und gibt an, dass sie den Dateiinhalt als Text zurückgeben soll. Sie verwendet anschließend die Werteigenschaft des AsyncResult-Objekts, die an den anonymen Funktionsrückruf übergeben wurde, um einen Verweis auf das File-Objekt zu erhalten. Die Funktion verwendet dann die Größeneigenschaft des File-Objekts, um die Dateigröße im angegebenen Element anzuzeigen. Ähnlich verwenden Sie die AsyncResult.value-Eigenschaft, um in der Apps für Office-API den Rückgabewert einer beliebigen asynchronen Funktion abzurufen. 

Zur Document.getFileAsync-Methode können Sie im nächsten Artikel dieser Reihe mehr lesen.

Objektmodellhierarchie

Die JavaScript-API für Office zielt darauf ab, versionsübergreifende Kompatibilität für Office und Symmetrie über verschiedene Hostanwendungen hinweg bereitzustellen. Um diese Ziele zu unterstützen, hat die JavaScript-API ein schlankes Objektmodell mit einer klaren Hierarchie, die nicht direkt an eine bestimmte Hostanwendung gebunden ist. Stattdessen hostet das Objektmodell eine zielgerichtete Reihe von Funktionen zur Interaktion mit Office-Dokumenten, die auf den Typ der App (Aufgabenbereich-, Inhalts- oder Mail-App) begrenzt sind, von der sie verwendet werden.

Abbildung 1 bietet eine verkürzte Übersicht der obersten Hierarchieebene von Objekten in der JavaScript-API für Office (es wird nicht das gesamte Objektmodell gezeigt). Insbesondere zeigt das Diagramm die Beziehungen zwischen den Objekten „Office“, „Context“, „Document“, „Settings“, „Mailbox“ und „RoamingSettings“.

Abbildung 1: Die Objektmodellhierarchie in der JavaScript-API für Office

Jede Hostanwendung (Word, Excel, Excel Web App, PowerPoint, Project, Outlook und Outlook Web App) kann eine Untermenge der in der API enthaltenen Funktionen verwenden. Zum Beispiel betreffen ungefähr 40 Prozent des Objektmodells ausschließlich Mail-Apps, die nur in Outlook und Outlook Web App genutzt werden können. Ein weiterer Teil des Objektmodells lässt die Interaktion mit benutzerdefinierten XML-Elementen zu, die nur in Word 2013 verfügbar sind.

Abbildung 2 zeigt die Funktionen, die für bestimmte Hostanwendungen verfügbar sind.

Abbildung 2: Verfügbarkeit von Funktionen in der JavaScript-API für Office nach Hostanwendung

Gemeinsame Objekte im Objektmodell Die JavaScript-API für Office hat einen eindeutigen Einstiegspunkt, das Office-Objekt, das für alle Typen von Apps und in jeder der Hostanwendungen verfügbar ist. Das Office-Objekt stellt eine spezifische Instanz einer App dar, die in ein Dokument, eine Arbeitsmappe, eine Präsentation, ein Projekt, eine E-Mail-Nachricht oder einen Termin eingefügt wird. Mithilfe der Methode select kann das Objekt auf die Bindungen zwischen der App und dem Dokument zugreifen. (In einem späteren Artikel gehen wir detaillierter auf Bindungen ein.) Am wichtigsten ist, dass das Office-Objekt das initialize-Ereignis für die App verfügbar macht, wodurch Sie Initialisierungslogik für die App erstellen können (mehr dazu in einem zukünftigen Artikel). Schließlich enthält das Office-Objekt einen Verweis auf das Context-Objekt für die App.

Das Context-Objekt, das ebenfalls für alle Typen von Apps und in jeder der Hostanwendungen verfügbar ist, macht Informationen über die Laufzeitumgebung verfügbar, die die App hostet. Das Context-Objekt speichert nicht nur die Spracheinstellungen für die App, sondern stellt auch den Einstiegspunkt für die Laufzeitfunktionen in der JavaScript-API für Office bereit, die spezifisch für den Host sind, in dem die App aktiviert wurde.

Sie können zum Beispiel durch die Context.document-Eigenschaft auf das Dokument (Document-Objekt) zugreifen, das mit der App verknüpft ist. Diese Eigenschaft gibt jedoch nur einen Wert zurück, wenn sie aus einer Hostanwendung heraus aufgerufen wird, die sie unterstützt, also aus einer Aufgabenbereich- oder Inhalts-App. Wenn wir versuchen, die Context.document-Eigenschaft aus einer Mail-App heraus aufzurufen, kommt es zu dem Fehler „undefiniertes Objekt“. Dasselbe mit der Context.mailbox-Eigenschaft: In einer Mail-App gibt sie das in der Hostanwendung geöffnete Postfach (Mailbox-Objekt) zurück. In einer Aufgabenbereich-App ist sie undefiniert.

Unterstützung für Aufgabenbereich- und Inhalts-Apps im ObjektmodellFür Aufgabenbereich- und Inhalts-Apps stellt das Document-Objekt das Dokument oder Projekt dar, in welches die App eingefügt wurde, bzw. die Arbeitsmappe oder Präsentation, in die sie eingefügt wurde. Das Document-Objekt bietet den höchsten Zugriffsgrad auf den Inhalt der Datei. Im Grunde ist es der Hauptverbindungspunkt zwischen einer App und einem Office-Dokument.

Fast alle Techniken für den Zugriff auf den Inhalt des Office-Dokuments erfordern das Document-Objekt. Aus diesem Grund ist es sinnvoll, wenn Sie bei der Initialisierung der App einen Verweis auf das Document-Objekt erfassen, wie in Abbildung 3 gezeigt.

Abbildung 3: Speichern eines Verweises auf das Document-Objekt beim Initialisieren der App

// Add a handler to the initialize event of the Office object
Office.initialize = function (reason) {
  $(document).ready(function () {
    app.get_Document(Office.context.document);
 
    // Other initialization logic goes here
  })
}
 
// Use a self-executing anonymous function to encapsulate the
// functionality that the app uses
var app = (function () {
 
  var _document;
  function get_Document(officeDocument) {
    _document = officeDocument;
  }
 
  // Other fields and functions associated with the app
 
  return {
    get_Document: get_Document
    // Other exposed members
  };
})()

Beim Aktivieren einer App in einer Project-Datei macht das Document-Objekt zusätzliche, spezifische Funktionen verfügbar, die auf Project-Dateien abzielen. Über das Document-Objekt kann eine App Daten für bestimmte Aufgaben, Ansichten, Felder und Ressourcen im Projekt abrufen. Eine App kann auch Ereignislistener hinzufügen, die Änderungen an der im Projekt ausgewählten Ansicht, Aufgabe oder Ressource durch den Benutzer überwacht. (Im nächsten Artikel finden Sie weitere Informationen zur Verwendung des Document-Objekts in einer App für Project.)

Das Document-Objekt macht auch das Settings-Objekt verfügbar, dass den Eigenschaftsbehälter für eine App darstellt. Eine App kann mithilfe des Settings-Objekts benutzerdefinierte Eigenschaften sitzungsübergreifend im selben Dokument speichern und beibehalten. Die Eigenschaften bleiben bei dem Dokument: Wenn Sie eine Office-Datei für jemand anderen freigeben, die eine App enthält, sind die in der App gespeicherten benutzerdefinierten Eigenschaften verfügbar, wenn die andere Person die Datei liest.

Das Speichern und Abrufen von Einstellungen mithilfe des Eigenschaftenbehälters ist einfach. Die Settings.set-Methode erstellt die Einstellung im Speicher als ein Schlüssel-Wert-Paar. Zum Abrufen der Eigenschaften aus dem Eigenschaftenbehälter nutzen wir die Settings.get-Methode und übergeben den Namen (Schlüssel) der Einstellung, um den Wert zu erhalten. Sowohl die set- als auch die get-Methoden sind synchron. Zum sitzungsübergreifenden Speichern der Einstellungen müssen wir die Settings.saveAsync-Methode aufrufen, die alle benutzerdefinierten Eigenschaften speichert, die beim Speichern des Dokuments in der App enthalten sind.

Der Beispielcode „Apps für Office: Beibehalten benutzerdefinierter Einstellungen“ (bit.ly/UEiZff) bietet weitere Beispiele zur Verwendung des Settings-Objekts und dem Speichern von Daten in einer App.

Unterstützung für Mail-Apps im Objektmodell Für Mail-Apps stellt das Mailbox-Objekt den Einstiegpunkt für den Datenzugriff und somit für Mail-App-spezifische Funktionalität bereit. Das Mailbox-Objekt entspricht dem Postfach des aktuellen Benutzers und wird dahin weitergeleitet, wo Benutzer ihre E-Mails lesen, entweder in der Outlook-Clientanwendung oder in Outlook Web App. Das Mailbox-Objekt bietet nicht nur Zugriff auf einzelne E-Mail-Nachrichten und Termine (über die Mailbox.item-Eigenschaft), sondern ermöglicht der App, neue Termine zu erstellen, auf das Profil des lokalen Benutzers zuzugreifen und sogar die Ortszeit des Benutzers abzurufen.

Wie beim Document-Objekt für Inhalts- und Aufgabenbereich-Apps ist es sinnvoll, wenn Sie bei der Initialisierung der App einen Verweis auf das Mailbox-Objekt erfassen, wie in Abbildung 4 gezeigt.

Abbildung 4: Speichern eines Verweises auf das Mailbox-Objekt in einer globalen Variable beim Initialisieren der App

// Add a handler to the initialize event of the Office object
Office.initialize = function (reason) {
  $(document).ready(function () {
    app.get_Mailbox(Office.context.mailbox);
 
    // Other initialization logic goes here
  })
}
 
// Use a self-executing anonymous function to encapsulate the
// functionality that the app uses
var app = (function () {
 
  var _mailbox;
  function get_Mailbox(mailbox) {
    _mailbox = mailbox;
  }
 
  // Other fields and functions associated with the app
 
  return {
    get_Mailbox: get_Mailbox
    // Other exposed members
  };
})()

Das RoamingSettings-Objekt, das ebenfalls nur in Mail-Apps verfügbar ist, ist dem Settings-Objekt für dokumentenorientierte Apps ähnlich (Aufgabenbereich- und Inhalts-Apps). Durch das Objekt können Apps benutzerdefinierte Eigenschaften wie Namen-Wert-Paare sitzungsübergreifend beibehalten. Im Unterschied zum Settings-Objekt, das die benutzerdefinierten Eigenschaften in der Office-Hostdatei speichert, speichert das RoamingSettings-Objekt allerdings die benutzerdefinierten Einstellungen im Postfach des aktuellen Benutzers. Dadurch werden die benutzerdefinierten Eigenschaften unabhängig davon verfügbar, welche Nachricht der Benutzer liest oder wie der Benutzer auf sein Postfach zugegriffen hat (in Outlook oder in Outlook Web App).

Weitere Informationen über die Objektmodellhierarchie in der JavaScript-API für Office finden Sie auf der MSDN-Dokumentationsseite „Grundlegendes zur JavaScript-API für Office“ (bit.ly/UV2POY).

Testen, ob eine Funktion in einer Hostanwendung verwendet werden kann

Wie bereits erwähnt besteht eine der Stärken der JavaScript-API für Office darin, dass die Apps für Office einmal entwickelt und vielerorts gehostet werden können. Dieselbe Aufgabenbereich-App kann zum Beispiel in Word, Excel, Project und PowerPoint aktiviert werden (vorausgesetzt, ihr Manifest lässt alle diese Funktionen zu).

Da allerdings nicht alle Apps Zugriff auf genau dieselbe Liste von Funktionen haben, könnte eine App in eine Hostanwendung eingefügt werden, welche die für die App erforderlichen Funktionen nicht zulässt. Project lässt beispielsweise derzeit keinen Zugriff auf das Settings-Objekt zu. Eine App, die beim Einfügen in Project versucht, auf das Settings-Objekt zuzugreifen, löst den Fehler „undefiniertes Objekt“ aus.

Die Entwickler müssen daher ihren Apps Logik zum Testen der Verfügbarkeit der erforderlichen Funktionen hinzufügen. In dem Beispiel mit Project funktioniert das Ermitteln von Funktionen in einer Hostanwendung am besten über einen einfachen if-Block:

// Test for Settings object in host application
if (Office.context.document.settings) {
 
  // Provide implementation that uses the Settings object
 
}
else {
 
  // Use some other technique for saving custom properties,
  // like localStorage, sessionStorage or cookies
 
}

Weitere Informationen über die Vorgehensweise zum Ermitteln der Verfügbarkeit eines Elements in der Hostanwendung finden Sie auf der MSDN-Dokumentationsseite „Vorgehensweise: Ermitteln der Hostanwendungsunterstützung für bestimmte API-Elemente“ unter bit.ly/TR5ZlB.

Fassen wir zusammen: In diesem Artikel haben wir die Grundlagen der JavaScript-API für Office erläutert. Wir haben die wesentlichen Aspekte der Objektmodellhierarchie und das asynchrone Muster, wie es im Objektmodell implementiert wird, beschrieben. Außerdem sind wir darauf eingegangen, wie Sie testen können, ob eine Funktion in einer Hostanwendung unterstützt wird.

Im nächsten Artikel dieser Reihe betrachten wir die einfachsten, aber leistungsfähigsten Methoden für die Arbeit mit Daten in einer App für Office genauer. Wir beschreiben ausführlicher, wie ausgewählte Daten abgerufen und festgelegt werden. Ein weiterer Aspekt wird das Abrufen des gesamten Dateiinhalts und dessen Analyse sein. Wir gehen auf Apps in Project und das Lesen von Aufgaben-, Ressourcen- und Ansichtsdaten ein. Zum Schluss widmen wir uns dem Ereignismodell in der JavaScript-API für Office: Für welche Ereignisse können Sie codieren, und wie werden die Ergebnisse verarbeitet?

Stephen Oliver* *arbeitet als Redakteur im Bereich Programmierung in der Office Division und ist Microsoft Certified Professional Developer (SharePoint 2010). Er schreibt die Entwicklerdokumentation für Excel Services, Word Automation Services und PowerPoint Automation Services und hat bei der Betreuung und dem Entwurf der Excel Mashup-Website unter ExcelMashup.com mitgewirkt.

Eric Schmidt* *arbeitet als Redakteur im Bereich Programmierung in der Office Division. Er hat verschiedene Codebeispiele für Apps für Office erstellt, darunter das beliebte Codebeispiel „Beibehalten benutzerdefinierter Einstellungen“. Außerdem hat er Artikel verfasst und Videos erstellt, in denen andere Produkte und Technologien im Bereich der Office-Programmierbarkeit erläutert werden.

Unser Dank gilt den folgenden technischen Experten für die Durchsicht dieses Artikels:Mark Brewster, Shilpa Kothari und Juan Balmori Labra