Blog von Helmut Obertanner

Windows7 schmeckt gut!

Helmut Obertanner — Mon, 08 Mar 2010 09:07:24 GMT

Kollegen lieben MVPs!

Dokumentation für Outlook PST-Format veröffentlicht

Helmut Obertanner — Mon, 08 Mar 2010 07:51:54 GMT

Unter folgendem Link:

http://msdn.microsoft.com/en-us/library/ff385210.aspx

Steht seit kurzem die Dokumentation für das Microsoft Outlook PST Datei-Format zur Verfügung.
Im Rahmen der Interoperabilitätsoffensive steht jetzt in der MSDN Library die angekündigte Dokumentation für das PST-Dateiformat der Outlook-Datendateien zum Abruf bereit. Somit ist der Zugriff auf E-Mails, Kalender, Kontakte und andere Outlook-generierte Daten auch außerhalb dokumentierter APIs geöffnet. Selbstverständlich stehen auch die Seiten bereits veröffentlichter Dokumentationen der Office- und Windows-Dateiformate und -Protokolle weiterhin kostenfrei zur Lektüre bereit.

10 Lizenzen zu verschenken – 30% Rabatt

Helmut Obertanner — Fri, 29 Jan 2010 19:51:13 GMT

Instyler Software hat ein Outlook-Add-in zur Verwaltung von Fahrtzeiten entwickelt.
Das Add-in ist ideal für Geschäftsreisende und Freiberufler und unterstützt bei der Fahrtzeitenplanung.
http://www.instyler.com/

Dank der guten Zusammenarbeit kann ich meinen treuen Blog-Lesern freundlicherweise 10 Lizenzen (Max. 1 Lizenz pro Benutzer) gratis zur Verfügung stellen.
Die ersten 10 Leser welche eine Email mit Betreff: Travel Add-in über das Feedbackformular an mich senden, erhalten eine Travel Add-in Lizenz gratis.

Wenn Sie nicht zu den Gewinnern zählen und Ihnen die Software trotzdem gefällt, können Sie beim Kauf den
Gutscheincode: TRAVELX4U
angeben, sie erhalten auf jede Lizenz einen Rabatt von 30% auf den aktuellen Kaufpreis.

Das Add-in kann heruntergeladen werden, und vor dem Kauf 30 Tage ohne Einschränkungen getestet werden.

Helmut Obertanner

Kostenloses SharePoint eMagazin

Helmut Obertanner — Mon, 18 Jan 2010 20:04:46 GMT

Die Niederländische Benutzergruppe (DIUWG) hat ein SharePoint eMagazin herausgegeben. Das Magazin richtet sich an Entwickler, IT-Profis und Power-Benutzer. Es ist die erste Ausgabe des Magazins und es ist pro Jahr 4 eMagazine und 4 Magazine im Papierformat herauszugeben.

Das Magazin ist in englischer Sprache.

http://www.sdn.nl/IW/FreeMagazine/tabid/139/Default.aspx

Viel Spaß.

Outlook Formular per Code schliessen

Helmut Obertanner — Fri, 08 Jan 2010 20:06:23 GMT

In diesem Beispiel möchte ich über meine Erfahrungen zum über das Schliessen eines Formulars per Programmcode berichten.

Vor kurzem habe ich ein Beispiel zum Überprüfen und Absichern von Geschäftsregeln in einem Outlook Add-in berichtet:
http://www.outlooksharp.dehttp://www.outlooksharp.de/Home/tabid/36/EntryId/54/Geschaftsregeln-fur-Outlook-Formulare.aspx

Das Problem:

Implementiert man eine Lösung zum Sicherstellen von Geschäftsregeln möchte man den Benutzer darauf hinweisen, dass irgendetwas nicht korrekt ausgefüllt ist. Dazu kann man dem Benutzer einen modalen Dialog(MessageBox) anzeigen. Ist eine der Regeln ungültig, kann der Benutzer weder speichern – noch das Formular schliessen. Man sollte dem Benutzer aber immer die Möglichkeit geben einen Vorgang abzubrechen. Zu diesem Zweck kann man dem Benutzer im der Close-Benachrichtigung einen Dialog mit zwei Schaltflächen anzeigen z.B. Ok und Abbrechen. Klickt der benutzer in diesem Fall auf Abbrechen – soll das Formular einfach geschlossen werden ohne die modifizierten Daten zu speichern.
Prinzipiell sieht die Lösung wie folgt aus:

///

/// Flag is used to close the Form when Cancel is clicked

///

bool _closeAfterCancel = false;

///

/// Validates the BusinessRules and returns true if all rules are valid

///

/// If true, a OK/Cancel MessageBox is displayed to the user

/// true when all rules are valid

public bool Validate(bool showCancelButton) {

if (Item.Saved) return true;

// Default value

_closeAfterCancel = false;

// if every business rule is valid we return true

if (_BusinessRules.TrueForAll(X4UBusinessRule.IsRuleValid)) return true;

// no ?

// show a warning to the user and

StringBuilder message = new StringBuilder(500);

message.AppendLine("You can't save this Item, because the following requirements are not met:");

foreach (X4UBusinessRule rule in _BusinessRules) {

if (!rule.IsValid()) message.AppendLine(rule.Description);

}

// display a message to the user what's wrong.

DialogResult messageBoxResult = MessageBox.Show (new OutlookWin32Window(Inspector),

message.ToString(), // Message

"Warning!", // Caption

showCancelButton ? MessageBoxButtons.OKCancel : MessageBoxButtons.OK, // Which Buttons should we display

MessageBoxIcon.Exclamation, // The Icon

MessageBoxDefaultButton.Button1 // The Default Button

);

// when OK-Button is clicked, we cancel the Operation

if (showCancelButton && messageBoxResult==DialogResult.Cancel ){

_closeAfterCancel = true;

}

return false;

}

Wenn eine der geschäftsregeln nicht eingehalten wird, liefert die Validate-Methode false zurück.
Klickt der Benutzer auf die Abbrechen-Schaltfläche im angezeigten Dialog, soll das Formular ohne die Daten zu speichern geschlossen werden.
Um das zu erreichen wird ein Flag _closeAfterCancel auf true gesetzt. Normalerweise könnte man jetzt einfach die Methode Inspector.Close(Outlook.OlInspectorClose.OlDiscard) im Item_Close event aufrufen.

///

/// This Method is called when the Item is going to be closed

///

void Item_Close(ref bool Cancel) {

if (!_closeAfterCancel) {

Cancel = !Validate(true); // MessageBox with OK + Cancel Button

if (_closeAfterCancel) {

Inspector.Close(Outlook.OlInspectorClose.olDiscard);

}

Leider musste ich feststellen, dass dies so nicht funktioniert. Anstatt das Formular zu schliessen, wird ein "Möchten Sie die Änderungen Speichern"-Dialog angezeigt.
Außerdem wurden im Outlook Objekt Model(OOM) einige Änderungen durchgeführt, welche eine korrekte Funktion verschiedener Methoden im Close-Event verhindern, siehe KB929593.
Als Lösungsansatz kann man einen Timer starten und im Timer_Tick event die Methode Inspector.Close aufrufen.
So sieht der modifizierte Programmcode dazu aus:

///

/// Used to call Close() out of the Item_Close event.

///

Timer _closeTimer;

///

/// This Method is called when the Item is going to be closed

///

void Item_Close(ref bool Cancel) {

if (!_closeAfterCancel) {

Cancel = !Validate(true); // MessageBox with OK + Cancel Button

if (_closeAfterCancel) {

_closeTimer = new Timer();

_closeTimer.Tick += new EventHandler(_closeTimer_Tick);

_closeTimer.Start();

}

void _closeTimer_Tick(object sender, EventArgs e) {

_closeTimer.Stop();

_closeTimer.Dispose();

// Close the current Form without saving

Inspector.Close(Outlook.OlInspectorClose.olDiscard);

}

Jedoch wenn man dies ausführt kommt folgendes Resultat:

Es wird kein "Möchten Sie die Änderungen Speichern"-Dialog angezeigt
Das Formular wird geschlossen
Die Daten werden gespeichert

Es funktioniert einfach nicht wie gewünscht.
Nach meinen Erkenntnissen ist die einzig funktionierene Form anstatt der Inspector.Close(olDiscard)- die Item.Close(olDiscard)-Mehtode aufzurufen.
Der korrekte Code sieht dementsprechend aus:

void _closeTimer_Tick(object sender, EventArgs e) {

_closeTimer.Stop();

_closeTimer.Dispose();

// Close the current Form without saving

Item.Close(Outlook.OlInspectorClose.olDiscard);

}

Nur mit dieser Implementierung wird das Formular geschlossen ohne die Daten zu speichern.

Herzlichen Dank an Ken Slovak, durch Ihn bin ich auf die korrekte Lösung gekommen.

Viele Grüße – Helmut Obertanner
http://www.x4u.de

Geschäftsregeln für Outlook Formulare

Helmut Obertanner — Tue, 29 Dec 2009 19:54:52 GMT

Vor kurzem musste ich einem Kunden helfen Geschäftsregeln für Outlook Objekte(Kontakte) zu implementieren. Glücklicherweise habe ich dafür schon mal ein Programmierbeispiel auf der Webseite Outlookcode.com veröffentlicht. Dieses Beispiel ist aber schon ziemlich alt und als Vorlage diente ein sogenanntes "Shared" COM Add-in. Deshalb habe ich mich dazu entschlossen ein aktualisiertes Beispiel hier auf dem Blog zu veröffentlichen und VSTO-Technologie dazu zu benutzen.

Inspector Wrapper

Aller Anfang bildet wie immer ein Inspector Wrapper als Vorlage. Vor kurzem habe ich darüber geschrieben – hier kann man das Nachlesen: http://www.outlooksharp.dehttp://www.outlooksharp.dehttp://www.outlooksharp.de/Home/tabid/36/EntryId/45/Outlook-InspectorWrapper-erklart.aspx.

Die Grundlage der meisten Outlook-Applikationen ist das korrekte bearbeiten der verschiedenen Outlook Datenobjekte(Item) und deren Fenster(Inspector). Wenn in Outlook ein Item erstellt oder bearbeitet und in einem Formular angezeigt wird, wird dies von dem dazugehörigen Inspector überwacht. Der vorgestellte inspector Wrapper code macht es einfach die verschiedenen Datenobjekte und Formulare sauber in der Anwendung zu verarbeiten. Das aktuelle Datenobjekt, welches sich hinter einem Inspector verbirgt, ist über dessen CurrentItem-Eigenschaft erreichbar. Als Szenario in diesem Beispiel sollen für Kontakte Geschäftsregeln erzwungen werden.
Ein Outlook ContactItem stellt verschiedene Benachrichtigungen zur Verfügung welche dazu benutzt werden können, um ein kleines Framework Sicherstellung von Geschäftsregeln zu programmieren. Es kann sowohl das Speichern eines Objekts als auch das Schliessen eines Formulars überwacht und abgebrochen warden. Dazu muss man die Nachrichten write und close der entsprechenden Objekte überwachen. Die write(schreiben) und close(schliessen) Benachrichtigungen eines ContactItems verfügen über eine Cancel(Abbrechen) Eigenschaft welche als Referenztyp der Methode übergeben wird. Wird die Eigenschaft Cancel auf true(wahr) gesetzt, wird der entsprechende Vorgang abgebrochen – das Speichern der Daten oder das Schliessen des Formulars wird abgebrochen. Zunächst erstellen wir ein neues Outlook Add-in.

Abbildung 1: Erstellen eines Outlook Add-ins

Nach der Fertigstellung des Assistenten erhält man den üblichen VSTO Anwendungscode. Hier wird sogleich der InspectorWrapper implementiert welcher dazu dient alle individuellen Formularfenster zu verarbeiten. Die Basisklasse dazu nennt sich InspectorWrapper.cs und implementiert alle Nachrichten des Inspector Objekts. Möchte man Code für ein Kontakt-Objekt implementieren leitet man dazu eine Klasse von diesem InspectorWrapper ab und implementiert spezifischen Code für Kontakt-Objekte(ContactItem). In dieser Klasse lassen sich dann die Nachrichten für die Objekte monitoren und die Geschäftslogik implementieren.
Hier sehen Sie den Code für die InspectorWrapper Basisklasse:

///

/// Eventhandler used to correctly clean up resources

///

/// The unique id of the Inspector instance

internal delegate void InspectorWrapperClosedEventHandler(Guid id);

///

/// The base class for all InspectorWrappers

///

internal abstract class InspectorWrapper {

///

/// Event notifier for the InspectorWrapper.Closed event.

/// Is raised when an Inspector has been closed.

///

public event InspectorWrapperClosedEventHandler Closed;

///

/// The unique Id the identifies the Inspector Window

///

public Guid Id { get; private set; }

///

/// The Outlook Inspector Instance

///

public Outlook.Inspector Inspector { get; private set; }

///

/// .ctor

///

/// The Outlook Inspector instance that should be handled

public InspectorWrapper(Outlook.Inspector inspector) {

Id = Guid.NewGuid();

Inspector = inspector;

// register for Inspector events here

((Outlook.InspectorEvents_10_Event)Inspector).Close += new Outlook.InspectorEvents_10_CloseEventHandler(Inspector_Close);

((Outlook.InspectorEvents_10_Event)Inspector).Activate += new Outlook.InspectorEvents_10_ActivateEventHandler(Activate);

((Outlook.InspectorEvents_10_Event)Inspector).Deactivate += new Outlook.InspectorEvents_10_DeactivateEventHandler(Deactivate);

((Outlook.InspectorEvents_10_Event)Inspector).BeforeMaximize += new Outlook.InspectorEvents_10_BeforeMaximizeEventHandler(BeforeMaximize);

((Outlook.InspectorEvents_10_Event)Inspector).BeforeMinimize += new Outlook.InspectorEvents_10_BeforeMinimizeEventHandler(BeforeMinimize);

((Outlook.InspectorEvents_10_Event)Inspector).BeforeMove += new Outlook.InspectorEvents_10_BeforeMoveEventHandler(BeforeMove);

((Outlook.InspectorEvents_10_Event)Inspector).BeforeSize += new Outlook.InspectorEvents_10_BeforeSizeEventHandler(BeforeSize);

// Only Outlook 2007((Outlook.InspectorEvents_10_Event)Inspector).PageChange += new Outlook.InspectorEvents_10_PageChangeEventHandler(PageChange);

// Initialize is called to give the derived Wrappers a chance to do initialization

Initialize();

}

///

/// Eventhandler for the Inspector close event

///

private void Inspector_Close() {

// call the Close Method - the derived classes can implement cleanup code

// by overriding the Close method

Close();

// unregister Inspector events

((Outlook.InspectorEvents_10_Event)Inspector).Close -= new Outlook.InspectorEvents_10_CloseEventHandler(Inspector_Close);

((Outlook.InspectorEvents_10_Event)Inspector).Activate -= new Outlook.InspectorEvents_10_ActivateEventHandler(Activate);

((Outlook.InspectorEvents_10_Event)Inspector).Deactivate -= new Outlook.InspectorEvents_10_DeactivateEventHandler(Deactivate);

((Outlook.InspectorEvents_10_Event)Inspector).BeforeMaximize -= new Outlook.InspectorEvents_10_BeforeMaximizeEventHandler(BeforeMaximize);

((Outlook.InspectorEvents_10_Event)Inspector).BeforeMinimize -= new Outlook.InspectorEvents_10_BeforeMinimizeEventHandler(BeforeMinimize);

((Outlook.InspectorEvents_10_Event)Inspector).BeforeMove -= new Outlook.InspectorEvents_10_BeforeMoveEventHandler(BeforeMove);

((Outlook.InspectorEvents_10_Event)Inspector).BeforeSize -= new Outlook.InspectorEvents_10_BeforeSizeEventHandler(BeforeSize);

// Only Outlook 2007((Outlook.InspectorEvents_10_Event)Inspector).PageChange -= new Outlook.InspectorEvents_10_PageChangeEventHandler(PageChange);

// clean up resources and do a GC.Collect();

Inspector = null;

GC.Collect();

GC.WaitForPendingFinalizers();

// raise the Close event.

if (Closed != null) Closed(Id);

}

///

/// Method is called after the internal initialization of the Wrapper

///

protected virtual void Initialize() { }

///

/// Method gets called when another Page of the Inspector has been selected

///

/// The active page name by reference

protected virtual void PageChange(ref string ActivePageName) { }

///

/// Method gets called before the Inspector is resized

///

/// To prevent resizing set Cancel to true

protected virtual void BeforeSize(ref bool Cancel) { }

///

/// Method gets called before the Inspector is moved around

///

/// To prevent moving set Cancel to true

protected virtual void BeforeMove(ref bool Cancel) { }

///

/// Method gets called before the Inspector is minimized

///

/// To prevent minimizing set Cancel to true

protected virtual void BeforeMinimize(ref bool Cancel) { }

///

/// Method gets called before the Inspector is maximized

///

/// To prevent maximizing set Cancel to true

protected virtual void BeforeMaximize(ref bool Cancel) { }

///

/// Method gets called when the Inspector is deactivated

///

protected virtual void Deactivate() { }

///

/// Method gets called when the Inspector is activated

///

protected virtual void Activate() { }

///

/// Derived classes can do a cleanup by overriding this method.

///

protected virtual void Close() { }

///

/// This Fabric method returns a specific InspectorWrapper or null if not handled.

///

/// The Outlook Inspector instance

/// Returns the specific Wrapper or null

public static InspectorWrapper GetWrapperFor(Outlook.Inspector inspector) {

// retrieve the message class using late binding

string messageClass = (string)inspector.CurrentItem.GetType().InvokeMember("MessageClass", BindingFlags.GetProperty, null, inspector.CurrentItem, null);

// depending on a messageclass you can instantiate different Wrappers

// explicitely for a given MessageClass

// using a switch statement

switch (messageClass) {

case "IPM.Contact":

return new ContactItemWrapper(inspector);

case "IPM.Journal":

return new ContactItemWrapper(inspector);

case "IPM.Note":

return new MailItemWrapper(inspector);

case "IPM.Post":

return new PostItemWrapper(inspector);

case "IPM.Task":

return new TaskItemWrapper(inspector);

}

// or check if the messageclass begins with a specific fragment

//if (messageClass.StartsWith ("IPM.Contact.XXXX")){

// return new CustomItemWrapper(inspector);

//}

// or check the interface type of the Item

if (inspector.CurrentItem is Outlook.AppointmentItem) {

return new AppointmentItemWrapper(inspector);

}

// or check the interface type of the Item

if (inspector.CurrentItem is Outlook.ContactItem) {

return new ContactItemWrapper(inspector);

}

// no wrapper found

return null;

}

Als nächstes sieht man die Implementierung der ContactItemWrapper-Klasse. Sie ist von der InspectorWrapper-Klasse abgeleitet und ist ab jetzt für alle Kontakt-Objekte in Outlook zuständig. Bis jetzt nichts neues. Wie lassen sich die Geschäftsregeln implementieren? Studiert man den Code etwas genauer kann man sehen, dass in der Initialize-Methode die Benachrichtigungen des Kontakts abgehöhrt werden - und zwar die open, write and close Nachrichten. In C# benötigt die close-Nachricht leider eine Spezialbehandlung. Das Problem ist, dass das ContactItem bereits eine Close() Methode hat und der Generator für die sog. Primary Interop Assemblies nicht zwischen der Close Nachricht und der Close Methode unterscheiden kann. Deshalb muss man hier als Syntax speziell das ItemEvents_10_Event Interface verwenden. Sobald die Nachrichtenregistrierung abgeschlossen ist, wird eine Methode namens SetupBusinessRules aufgerufen. Dies wird aber nochmals im Detail erklärt. Zunächst hier mal der Beispielcode der Klasse ContactItemWrapper.

internal class ContactItemWrapper : InspectorWrapper {

///

/// .ctor

///

/// The Outlook Inspector instance that should be handled

public ContactItemWrapper(Outlook.Inspector inspector)

: base(inspector) {

}

///

/// The Object instance behind the Inspector (CurrentItem)

///

public Outlook.ContactItem Item { get; private set; }

///

/// Method is called when the Wrapper has been initialized

///

protected override void Initialize() {

// Get the Item of the current Inspector

Item = (Outlook.ContactItem)Inspector.CurrentItem;

// Register for the Item events

Item.Open += new Outlook.ItemEvents_10_OpenEventHandler(Item_Open);

Item.Write += new Outlook.ItemEvents_10_WriteEventHandler(Item_Write);

((Outlook.ItemEvents_10_Event)Item).Close += new Microsoft.Office.Interop.Outlook.ItemEvents_10_CloseEventHandler(Item_Close);

SetupBusinessRules();

}

///

/// This Method is called when the Item is going to be closed

///

void Item_Close(ref bool Cancel) {

if (!Item.Saved) {

Cancel = !Validate();

}

///

/// This Method is called when the Item is saved.

///

/// When set to true, the save operation is cancelled

void Item_Write(ref bool Cancel) {

if (!Item.Saved) {

Cancel = !Validate();

}

///

/// This Method is called when the Item is visible and the UI is initialized.

///

/// When you set this property to true, the Inspector is closed.

void Item_Open(ref bool Cancel) {

//TODO: Implement something

}

///

/// The Close Method is called when the Inspector has been closed.

/// Do your cleanup tasks here.

/// The UI is gone, can't access it here.

///

protected override void Close() {

// unregister events

Item.Write -= new Outlook.ItemEvents_10_WriteEventHandler(Item_Write);

Item.Open -= new Outlook.ItemEvents_10_OpenEventHandler(Item_Open);

((Outlook.ItemEvents_10_Event)Item).Close -= new Microsoft.Office.Interop.Outlook.ItemEvents_10_CloseEventHandler(Item_Close);

_BusinessRules.Clear();

_BusinessRules = null;

// required, just stting to NULL may keep a reference in memory of the Garbage Collector.

Item = null;

GC.Collect();

GC.WaitForPendingFinalizers();

}

#region business rule check methods

List<X4UBusinessRule> _BusinessRules = new List<X4UBusinessRule>();

private void SetupBusinessRules() {

_BusinessRules.Add(new X4UBusinessRule("LastNameUppercase", "The Office Location is required and must be Uppercase.", this.BusinessRuleCheck_OfficeLocationRequiredAndUppercase));

_BusinessRules.Add(new X4UBusinessRule("CompanyName3Letters", "The Company Name must have a minimum length of 3.", this.BusinessRuleCheck_CompanyNameMinimum3Letters));

}

public bool Validate() {

// if every business rule is valid we return true

if (_BusinessRules.TrueForAll(X4UBusinessRule.IsRuleValid)) return true;

// no ?

// show a warning to the user and

StringBuilder message = new StringBuilder(500);

message.AppendLine("You can't save this Item, because the following requirements are not met:");

foreach (X4UBusinessRule rule in _BusinessRules) {

if (!rule.IsValid()) message.AppendLine(rule.Description);

}

// display a message to the user what's wrong.

MessageBox.Show (new OutlookWin32Window(Inspector), message.ToString());

return false;

}

public bool BusinessRuleCheck_OfficeLocationRequiredAndUppercase() {

return (!string.IsNullOrEmpty (Item.OfficeLocation) && Item.OfficeLocation == Item.OfficeLocation.ToUpper());

}

public bool BusinessRuleCheck_CompanyNameMinimum3Letters() {

return (Item.CompanyName != null && Item.CompanyName.Length > 2);

}

#endregion

}

Definieren von Geschäftsregeln

Zunächst wird eine KLasse definiert, welche eine Geschäftsregel beschreiben soll. Sie hat als Eigenschaften einen Namen und eine Beschreibung welche später dem Benutzer angezeigt werden soll, falls die Regel nicht eingehalten wird. Außerdem hat sie einen Zeiger auf eine Methode, welche die eigentliche Überprüfung der Regel durchführt. Die Signatur solch einer Methode wird dazu in einem Delegaten definiert.

///

/// Delegate declares the Method signature that checks the BusinessRule and returns true or false

///

/// True if the rule is ok

public delegate bool BusinessRuleCheckMethod();

Im Konstruktor der Geschäftsregel werden die Eigenschaften und der Funktionszeiger übergeben. Es gibt noch eine weitere Statische Methode(IsRuleValid), welche von einer Liste als Prüfmethode aufgerufen werden kann, dazu später mehr Infos. Hier zunächst die Klasse für die Geschäftsregel.

///

/// This class defines a business rule

///

public class X4UBusinessRule {

///

/// The Name of the business rule

///

public string Name { get; private set; }

///

/// A description displayed to the user if the rule is not met

///

public string Description { get; private set; }

///

/// A function pointer that points to the method that checks if the business rule is valid

///

public BusinessRuleCheckMethod IsValid { get; private set; }

///

/// .ctor

///

/// The name

/// The description

/// Function pointer to the validation method

public X4UBusinessRule(string name, string description, BusinessRuleCheckMethod ruleValidator) {

IsValid = ruleValidator;

Name = name;

Description = description;

}

///

/// This method executes the method that the rule points to and returns the result

///

/// The businesrule to check

/// True if the rule is valid

public static bool IsRuleValid(X4UBusinessRule rule) {

return rule.IsValid();

}

Als nächstes sehen wir uns an wie die Geschäftsregeln in der Klasse ContactItemWrapper initialisiert werden. Nur zur Demonstration habe ich zunächst zwei einfache Regeln definiert und ausprogrammiert. Und so sehen diese aus:

public bool BusinessRuleCheck_OfficeLocationRequiredAndUppercase() {

return (!string.IsNullOrEmpty (Item.OfficeLocation) && Item.OfficeLocation == Item.OfficeLocation.ToUpper());

}

public bool BusinessRuleCheck_CompanyNameMinimum3Letters() {

return (Item.CompanyName != null && Item.CompanyName.Length > 2);

}

Die erste Methode überprüft die OfficeLocation-Eigenschaft des Kontakts. Sie darf nicht leer sein und darf nur aus Großbuchstaben bestehen. Die zweite Funktion überprüft die Eigenschaft CompanyName – diese muss mindestens drei Zeichen enthalten. Man kann verschiedenste Regeln implementieren, mann muss nur darauf achten dass die jeweilige Methode true zurückliefert wenn die Regel erfolgreich überprüft ist.

Validierung

Wie und wann werden diese Regeln überprüft? Dafür wird eine Validate-Methode bereitgestellt welche immer in den write und close Benachrichtigungen aufgerufen wird. Die Regeln werden in einer Liste gespeichert, dadurch können alle Regeln mit einem Methodenaufruf (TrueForAll) überprüft werden. Ist nur eine Regel nicht erfolgreich validiert, wird dem Benutzer eine Nachricht angezeigt mit dem entsprechenden Hinweis auf die Ursache der Meldung. Hier ist die Validate-Methode.

public bool Validate() {

// if every business rule is valid we return true

if (_BusinessRules.TrueForAll(X4UBusinessRule.IsRuleValid)) return true;

// no ?

// show a warning to the user and

StringBuilder message = new StringBuilder(500);

message.AppendLine("You can't save this Item, because the following requirements are not met:");

foreach (X4UBusinessRule rule in _BusinessRules) {

if (!rule.IsValid()) message.AppendLine(rule.Description);

}

// display a message to the user what's wrong.

MessageBox.Show (new OutlookWin32Window(Inspector), message.ToString());

return false;

}

Das ist sehr einfach zu implementieren. Die Validate-Methode wird in der Item.Write und in der Item.Close Benachrichtigung aufgerufen. In diesen Methoden wird der Saved-Status des Kontaktes überprüft. Wenn der Kontakt nicht modifiziert wurde ist eine Regelüberprüfung nicht notwendig. Liefert die Validate-Methode false, wird die write- oder close Operation abgebrochen. Als nächstes kann man die Methoden der Benachrichtigungen sehen:

///

/// This Method is called when the Item is going to be closed

///

void Item_Close(ref bool Cancel) {

if (!Item.Saved) {

Cancel = !Validate();

}

///

/// This Method is called when the Item is saved.

///

/// When set to true, the save operation is cancelled

void Item_Write(ref bool Cancel) {

if (!Item.Saved) {

Cancel = !Validate();

}

Wie werden die Geschäftsregeln mit den Funktionszeigern initialisiert? Dies wird mit einer einzigen Codezeile erreicht.
Einfach eine neue Instanz einer BusinessRule-Klasse erzeugen. Dem Konstruktor wird der Name, die Beschreibung und die Methode zum Überprüfen als Parameter übergeben.

List<X4UBusinessRule> _BusinessRules = new List<X4UBusinessRule>();

private void SetupBusinessRules() {

_BusinessRules.Add(new X4UBusinessRule("OfficeLocationRequiredAndUppercase", "The Office Location is required and must be uppercase.", this.BusinessRuleCheck_OfficeLocationRequiredAndUppercase));

_BusinessRules.Add(new X4UBusinessRule("CompanyName3Letters", "The Company Name must have a minimum length of 3.", this.BusinessRuleCheck_CompanyNameMinimum3Letters));

}

Sobald ein Kontakt erzeugt oder bearbeitet - und dieser gespeichert oder geschlossen wird, werden die Geschäftsregeln überprüft. Wird dabei eine Misachtung festgestellt wird diese, wie im Bild zu sehen, dem Benutzer angezeigt.

Abbildung 2: Ein hinweis zeigt dem Benutzer welche Regeln misachtet wurden

Beispielcode

Der Beispielcode zu diesem Blog kann hier heruntergeladen werden:
Visual Studio 2010

Referenzen

Outlook Inspector Object: http://msdn.microsoft.com/en-us/library/bb176679.aspx
Outlook ContactItem Object: http://msdn.microsoft.com/en-us/library/bb176651.aspx
InspectorWrapper: http://www.outlooksharp.dehttp://www.outlooksharp.dehttp://www.outlooksharp.de/Home/tabid/36/EntryId/45/Outlook-InspectorWrapper-erklart.aspx

Geschäftsapplikationen mit Infragistics und Silverlight

Helmut Obertanner — Sun, 27 Dec 2009 12:49:47 GMT

Dieser Artikel hat zwar nichts mit Outlook und VSTO zu tun, dennoch hat zumindest die Optik eine gewisse Ähnlichkeit mit der neuen Oberfläche der Microsoft Office Anwendungen. In der aktuellen Silverlight CTP von Infragistics ist jetzt ein Ribbon Control (XamlWebRibbon) enthalten. Dadurch ist es sehr einfach Geschäftsanwendungen mit Silverlight zu erstellen. Wie es der Zufall gerade will, arbeite ich mit einem Team an der zukünftigen Lizenzierung von Applikationen. Hierbei geht es nicht alleine um die technische implementierung einer Softwarelizenzierung – nein – auch das ganze drumherum, das Backend, Infrastruktur und die Verwaltung muss natürlich bereitgestellt werden. Ich habe sofort die Chance ergriffen und versuche dieses Backend mit neuesten Technologien mit Hilfe von Silverlight, RIA und Infragistics zu erstellen.

Abbildung 1: Screenshot des Infragistics Ribbon Controls für Silverlight

Normalerweise würde ich die Anwendung mit Visual Studio 2010 Beta und Silverlight 4 erstellen, da die Anwendung aber tatsächlich funktionieren soll, habe ich mich dazu entschieden Visual Studio 2008 zu verwenden. Für Silverlight 4 gibt es noch keine Runtime.
Als Datenbank soll ein Microsoft SQL-Server arbeiten, der Zugriff erfolgt mit RIA-Services mit LINQ oder Entity Framework.

Als erstes starten wir eine neue Silverlight-Applikation.

Benötigte Software und Tools

Um so eine Anwendung nachprogrammieren zu können, benötigen Sie folgende Software:

Microsoft Visual Studio 2008 SP1
Silverlight SDK, Tools und Dokumentation - http://www.silverlight.net/getstarted/
Silverlight ToolKit - http://silverlight.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=36060
Microsoft Expression Blend
RIA Services - http://www.silverlight.net/getstarted/riaservices/
Infragistics Silverlight Controls CTP - http://www.infragistics.com/dotnet/netadvantage/silverlight/line-of-business.aspx

Erstellen der Anwendung

Nun bin ich kein Spezialist für Webanwendungen oder Silverlight, deshalb werde ich dieses Projekt ebenfalls als Lernapplikation verwenden. Bestenfalls habe ich eine gute Vorstellung davon, wie die Lizensierungsapplikation auszusehen hat. Vermutlich gibt es auch schon jede Menge fertige Applikationen oder Portale, welche diesen Zweck gut erfüllen und schon tausendfach erpropt sind. Egal, hier geht es um das Erlernen der Anwendung und den Einsatz moderner und neuer Technologien.

Wir beginnen also zunächst mit der Erstellung der Anwendung mit Visual Studio 2008.

Abbildung 2: Silverlight RIA Anwendung erstellen

Nachdem man alles korrekt installiert hat, findet man in den Visual Studio Projektvorlagen under dem Eintrag Silverlight die entsprechenden Templates. Als Vorlage wähle ich das Template "Silverlight Application". Als nächstes erscheind folgender Screen:

Abbildung 3: Erstellen einer Silverlight Anwendung

Ja, die Silverlight Anwendung wird in einer Webseite gehostet und ja, ich möchte RIA Services verwenden.
Nach dem Beenden das Assistenten hat man zumindest schon mal eine funktionierende Anwendungsvorlage. Ein Start der Anwendung startet den Browser und zeigt ein leeres Browserfenster.

Verwendung von Infragistics Controls

Als nächstes soll das Infragistics Ribbon in die Anwendung integriert werden.
Als erstes muss man die entsprechende DLL im Projekt referenzieren. Die Infragistics DLLs habe ich in einem Unterordner des Projektes bereitgestellt. Ich füge die DLL als Referenz hinzu.

Abbildung 4: Hinzufügen der Infragistics Referenzen zum Projekt

Jetzt wird die "Main.xaml" Datei aus Visual Studio heraus mit Expression Blend 3 geöffnet. Die Infragistics Controls findet man unter "Assets|Locactions|Infragistics...".

Abbildung 5: Expression Blend mit Infragistics Controls

Der Seite wird das XamlWebRibbon als Control hinzugefügt. Ein Ribbon hat üblicherweise verschiedene Tabs, die Tabs enthalten wiederum Gruppen und die Gruppen enthalten Bedienelemente. So stelle ich mir zunächst ein einfaches Menü für den Anwender bereit.
Der Anwender soll sein eigenes Konto sehen und die gekaufte Software oder Musik, als auch Rechnungsdokumente, Bedienungsanleitungen und andere wichtige persönliche Dokumente sofort im Zugriff haben. In Expression Blend bin ich mit den Infragistics Control leider nicht so zurecht gekommen, deshalb habe ich die Tabs und Gruppen manuell im XML hinzugefügt.

Der XAML-Code sieht dementsprechend aus:

Abbildung 6: Blend mit XAML Code und Vorschau

Startet man die Anwendung im Debugger, kann man sogleich das Ergebnis sehen.

Abbildung 7: Die Anwendung mit Ribbon im Browser

Fazit

Mit dem XamlWebRibbon Control von Infragistics lässt sich im Handumdrehen ein tolles Userinterface für eine Webanwendung erstellen. Ich bin wirklich beeindruckt wie schnell man hier eine kleine Applikation erstellen kann. Die Integration in Blend ist aber durchaus noch verbesserungswürdig. Die Anwendung ist auf meinem Webserver unter der Adresse: http://silver.x4u.de erreichbar. Ich werde weiter darüber bloggen, wie sich die Funktionalität der Anwendung mit Webservices erweitern lässt. Bleibt für mich jedenfalls ein spannendes Thema.

Rekursiv über Outlook Ordner iterieren

Helmut Obertanner — Sat, 26 Dec 2009 16:47:58 GMT

In diesem wie-wird's-gemacht Artikel möchte ich verschiedene Überlegungen zum Thema Rekursiver Zugriff auf Outlook Ordner und deren Unterordner.

Im Outlook Objekt Model (OOM) wird ein Outlook Ordner durch den MAPIFolderTyp representiert .
Es gibt verschiedene Möglichkeiten auf eine MAPIFolder-Instanz zuzugreifen:

Verwendung der Session.GetDefaultFolder(OlDefaultFolders) Methode um Zugriff euf einen der vordefinierten Ordner zu erhalten
Mit der Session.GetFolderById(folderId, [optional] storeId) Methode wird ein Ordner anhand seiner EntryId geladen
Über die Parent Eigenschaft eines Item Objekts oder eines anderen Ordners
Über die Explorer.CurrentFolder Eigenschaft
Iterieren über die Folders ansammlung eines Stores oder einer Folder Instanz.
Durch erstellen eines neuen Folders

Das rekursive iterieren über einen Ordnerbaum und der Zugriff auf dessen Outlook Objekte kann ein ziemlich langsames unterfangen werden. Es hängt ab von der Anzahl der Items in einem Ordner und der ebenentiefe der Unterordner. Wenn das Outlook Object Model mit .Net(managed) code verwendet wird, muss man sich über die verwendung des Speichers und der COM Objekte Gedanken machen. Der Zugriff und die Verwendung von Objekten wie Emails, Termine(Appointments) and Aufgaben(Tasks) kann sehr langsam sein. Dies liegt leider am internen Design der MAPI Struktur, und wie die Daten gespeichert sind. Das Outlook Objekt Model basiert auf dieser Technologie. Ausserdem spielt die Konfiguration eine Rolle, wenn ein Exchangeserver verwendet wird ist es ein Unterschied ob man online oder offline arbeitet – und wie schnell eine Netzwerkverbindung ist.

Das zu viele RPC Verbindungen problem

Diese Problem kann auftreten, wenn man mit einem Exchangeserver im Backend arbeitet und auf viele Outlook-Objekte in kurzer Zeit zugreift. Für jedes Item auf welches man per Code zugreift, wird eine Verbindung zum Exchangeserver hergestellt (Remote Procedure Call) und das entsprechende Objekt wird geöffnet oder synchronisiert. Im Standardfall ist die Anzahl der gleichzeitig möglichen RPC-Verbindungen von einem Client(Outlook Session) zum Exchangeserver begrenzt auf 256. Wenn man eine Lösung entwickelt und nur offline Arbeitet oder zum Testen nur wenige Objekte verwendet wird dieses Problem nie auftreten. Wird die Anwendung jedoch beim Kunden in Betrieb genommen und verwendet entstehen plötzlich unerklärliche Phänomene. Also: Wann immer über eine Outlook-Items Ansammlung iterierd wird, sollte man diese Problem im Hinterkopf haben und diese schon im Voraus vermeiden. Im ersten Beispiel wird einfach über alle Items im Posteingang iteriert. Hier werden verschiedene Grundlagen besprochen. Für alle Beispiele wird folgende Methode verwendet, welche den Posteingangs-Ordner zurückliefert.

Outlook.MAPIFolder GetInboxFolder() {

return Globals.ThisAddIn.Application.Session.GetDefaultFolder(Outlook.OlDefaultFolders.olFolderInbox);

}

Im ersten Test iterieren wir einfach über alle Email-Items des Posteingangs und lassen die Betreff8Subject)-Zeile ausgeben.

// Get the Inbox folder

Outlook.MAPIFolder inboxFolder = GetInboxFolder();

// Iterate over all Inbox items and get the Subject

foreach (object item in inboxFolder.Items) {

Trace.WriteLine (item.GetType ().InvokeMember ("Subject", BindingFlags.GetProperty, null, item, null));

}

Was ist an diesem Code falsch? Theoretisch ist eigentlich alles OK, jedoch:
- was passiert, wenn mehr Items als mögliche RPC-Connections im Ordner sind?
- die Anzahl der Objekte in der Items-Collection kann sich jederzeit dynamisch ändern – wie reagiert der Code darauf?
- der gesamte Vorgang kann nicht unterbrochen werden, bis alle Objekte verarbeitet wurden.
- der Programmcode läuft im Haput-Anwendungsthread des Outlook Prozesses ab – dies bedeutet: Die Benutzeroberfläche reagiert nicht mehr, bis die Schleife zu Ende ist.

Wie kann man das lösen?

Zuerst wollen wir uns darum kümmern das RPC-Verbindungsproblem zu lösen. Dazu definiert man eine Variable, welche die Anzahl der verarbeiteten Objekte mitzählt. Innerhalb der Anwendungsschleife erhöht man einfach einen Zählerund erreicht man eine vorbestimmte Anzahl von Objekten, erzwingt man den the .Net Garbage Collector die nicht mehr verwendeten COM-Objekte freizugeben und diese aus dem Speicher zu entfernen. Die Ursache des Problems ist: Der .Net Garbage Collector ist intelligent. Dieser merkt sich die verwendeten Objekte für eine gewisse Zeit in einem cache – falls man diese Objekte spatter wiederverwendet, erhält man einen schnellen Zugriff darauf – dadurch werden .Net Anwendungen schneller. Dieses Verhalten trifft leider auch auf COM(Component Object Model)-Objekte also alle Outlook-Objekte zu. Greift man auf ein solches Objekt zu, verbleibt für eine unbestimmte Zeit eine Referenz darauf im Speicher – auch wenn man das Objekt explizit auf NULL setzt. Der GC(Garbage Collector) entscheidet, wann diese Objekt aus dem Speicher freigegeben wird. Als Alternative kann man aber den Garbage Collector dazu zwingen den Speicher aufzuräumen und nicht mehr verwendete Objekte freizugeben. Achtung: Ein GC cleanup ist sehr teuer den er verbraucht CPU-Zeit und blockiert auch andere .Net Anwendungen – man sollte Ihn also möglichst nicht zu oft aufrufen – man muss eben einen guten Mix finden. Bei der Outlook-programmierung ist es ein absolutes muss, einen GC-Cleanup nach der freigabe eines Inspector oder eines Explorer Objekts durchzuführen.
Hier kommt das nächste Code-Beispiel.

// Get the Inbox folder

Outlook.MAPIFolder inboxFolder = GetInboxFolder();

int watchDog = 0;

// Iterate over all Inbox items and get the Subject

foreach (object item in inboxFolder.Items) {

Trace.WriteLine (item.GetType ().InvokeMember ("Subject", BindingFlags.GetProperty, null, item, null));

// Ensures that not too many RPC connections are made to a Server

watchDog++;

if (watchDog > 100) {

watchDog = 0;

GC.Collect();

GC.WaitForPendingFinalizers();

}

Die watchdog Variable wird benutzt, um ein Cleanup des the Garbage Collectors nach einer bestimmten Anzahl Verwendungen von COM Objekten zu erzwingen – dabei warden die RPC-Verbindungen geschlossen.
Anmerkung: Die Folder.Items Ansammlung ist nicht statisch – die Anzahl der Objekte kann sich jederzeit ändern. Anstatt einer foreach-Schleiche sollte man deshalb besser die Anzahl der Objekte ermitteln und einen Rückwärtszähler programmieren.
So sieht der Code dafür aus:

// Get the Inbox folder

Outlook.MAPIFolder inboxFolder = GetInboxFolder();

int watchDog = 0;

// Iterate over all Inbox items and get the Subject

for (int index = inboxFolder.Items.Count; index > 0; index-- ) {

object item = inboxFolder.Items[index];

Trace.WriteLine(item.GetType().InvokeMember("Subject", BindingFlags.GetProperty, null, item, null));

item = null;

// Ensures that not too many RPC connections are made to a Server

watchDog++;

if (watchDog > 100) {

watchDog = 0;

GC.Collect();

GC.WaitForPendingFinalizers();

}

Die index Variable um die Objekte rückwärts herunter abzuarbeiten. So können während des Vorgangs Objekte in der Schleife gelöscht oder verschoben werden. Der gesamte Vorgang kann aber immer noch nicht unterbrochen warden, nicht mal durch Beenden der Outlook Anwendung. Um den Code in einen unterbrechbaren und interaktiven Vorgang zu ändern, muss dieser in einem eigenen Thread laufen. Im .Net Framework gibt es dafür schon etwas was man hier benutzen kann, es nennt sich BackgroundWorker.
Nachfolgend kann man den Beispielcode dafür sehen:

BackgroundWorker _worker;

private void ThisAddIn_Startup(object sender, System.EventArgs e)

{

// Setup the background thread

_worker = new BackgroundWorker();

_worker.DoWork += new DoWorkEventHandler(_worker_DoWork);

_worker.WorkerSupportsCancellation = true;

_worker.RunWorkerAsync();

}

void _worker_DoWork(object sender, DoWorkEventArgs e) {

BackgroundWorker worker = (BackgroundWorker)sender;

// Get the Inbox folder

Outlook.MAPIFolder inboxFolder = GetInboxFolder();

int watchDog = 0;

// Iterate over all Inbox items and get the Subject

for (int index = inboxFolder.Items.Count; index > 0; index--) {

// if someone interrupts the worker exit here

if (worker.CancellationPending) break;

object item = inboxFolder.Items[index];

Trace.WriteLine(item.GetType().InvokeMember("Subject", BindingFlags.GetProperty, null, item, null));

item = null;

// Ensures that not too many RPC connections are made to a Server

watchDog++;

if (watchDog > 100) {

watchDog = 0;

GC.Collect();

GC.WaitForPendingFinalizers();

}

private void ThisAddIn_Shutdown(object sender, System.EventArgs e)

{

if (_worker.IsBusy) {

_worker.CancelAsync();

}

Mit einem BackgroundWorker last sich ein Zeitraubender Prozess im Hintergrund durchführen. Die Anwendungsoberfläche bleibt benutzbar und die Anwendungen bedienbar. Ausserdem kann die Verarbeitung unterbrochen werden.

Rekursive Operationen

Als nächstes werden wir in der Schleife rekursiv über Ordner iterieren. Dazu werden wir eine Methode implementieren, welche sich selbst rekursiv aufruft.

void IterateFolder(Outlook.MAPIFolder folder) {

int watchDog = 0;

// Iterate over all Inbox items and get the Subject

for (int index = folder.Items.Count; index > 0; index--) {

object item = folder.Items[index];

Trace.WriteLine(item.GetType().InvokeMember("Subject", BindingFlags.GetProperty, null, item, null));

item = null;

// Ensures that not too many RPC connections are made to a Server

watchDog++;

if (watchDog > 100) {

watchDog = 0;

GC.Collect();

GC.WaitForPendingFinalizers();

}

for (int index = folder.Folders.Count; index > 0; index--) {

Outlook.MAPIFolder subFolder = folder.Folders[index];

// Call this function recursively

IterateFolder(subFolder);

subFolder = null;

// Ensures that not too many RPC connections are made to a Server

watchDog++;

if (watchDog > 100) {

watchDog = 0;

GC.Collect();

GC.WaitForPendingFinalizers();

}

Dies funktioniert zwar tatsächlich, es ist aber leider nicht die beste Lösung des Problems. Rekursives aufrufen von Funktionen kann den Stapelspeicher des Prozessors überfordern – man landet im schlimmsten Fall im Nirwana. Wie kann man das lösen?
Als einfach Abhilfe kann man dazu das Queue Objekt verwenden, welches bereits durch das .Net Framework zur Verfügung gestellt wird. Eine Queue(Warteschlange) hat im wesentlichen 2 wichtige Methoden: Enqueue() und Dequeue().
Enqueue fügt ein Objekt am Ende der Schlange hinzu, Dequeue mimmt das erste Objket am Anfang der Queue und entfernt es aus dieser. Im nächsten Beispiel sammeln wir einfach die EntryID(Eindeutige ID des Ordners) der Unterordner eines Ordners und fügen diese am Ender der Schlange hinzu. In der Arbeitsmethode des Hintergrundthreads, wird einfach geprüft ob noch EntryID's in der Warteschlange sind, dann wird diese verarbeitet. Die EntryID eines Ordners wird aus der Queue entnommen und der Ordner wird verarbeitet – die ID's der Unterordner werden wieder ans Ende der Queue angefügt. Auf diesem Wege warden alle Ordner verarbeitet, und es gibt kein Problem mit dem Prozessor-Stack(Stapelspeicher). Der Prozess kann auch jederzeit unterbrochen werden.

BackgroundWorker _worker;

Queue<string> _folderIdsToProcess;

private void ThisAddIn_Startup(object sender, System.EventArgs e) {

_folderIdsToProcess = new Queue<string>();

// Get the Inbox folder

Outlook.MAPIFolder inboxFolder = GetInboxFolder();

// and add it to the queue

_folderIdsToProcess.Enqueue(inboxFolder.EntryID);

// Setup the background thread

_worker = new BackgroundWorker();

_worker.DoWork += new DoWorkEventHandler(_worker_DoWork);

_worker.WorkerSupportsCancellation = true;

_worker.RunWorkerAsync();

}

void _worker_DoWork(object sender, DoWorkEventArgs e) {

BackgroundWorker worker = (BackgroundWorker)sender;

Outlook.MAPIFolder folder;

int watchDog = 0;

while (_folderIdsToProcess.Count > 0 && !worker.CancellationPending) {

// pick one folder

string entryId = _folderIdsToProcess.Dequeue();

folder = Globals.ThisAddIn.Application.Session.GetFolderFromID(entryId, Type.Missing);

// Iterate over all Inbox items and get the Subject

for (int index = folder.Items.Count; index > 0; index--) {

if (worker.CancellationPending) break;

object item = folder.Items [index];

Trace.WriteLine(item.GetType().InvokeMember("Subject", BindingFlags.GetProperty, null, item, null));

item = null;

// Ensures that not too many RPC connections are made to a Server

watchDog++;

if (watchDog > 100) {

watchDog = 0;

GC.Collect();

GC.WaitForPendingFinalizers();

}

for (int index = folder.Folders.Count; index > 0; index--) {

if (worker.CancellationPending) break;

Outlook.MAPIFolder subFolder = folder.Folders[index];

// Call this function recursively

_folderIdsToProcess.Enqueue(subFolder.EntryID);

subFolder = null;

// Ensures that not too many RPC connections are made to a Server

watchDog++;

if (watchDog > 100) {

watchDog = 0;

GC.Collect();

GC.WaitForPendingFinalizers();

}

folder = null;

}

private void ThisAddIn_Shutdown(object sender, System.EventArgs e) {

if (_worker.IsBusy) {

_worker.CancelAsync();

}

Beim Zugriff auf die Queue-Variable gibt es auch keine locking-Probleme, da diese nur durch den Arbeitsthread(worker) modifiziert wird.

Beschleunigen des Zugriffs

Es ist Ihnen eventuell aufgefallen, dass der zugriff auf die Outlook-Objekte eine enorme Zeit beansprucht. Es gibt ein paar wenige Möglichkeiten diese Zeiten zu beschleunigen. Als erste Option würde ich die Verwendung eines Filters vorstellen: Ein Filter schränkt die Anzahl der Treffer in einem Ordner ein. Als Beispiel mächten wir nur Outlook-Items verarbeiten, welche nach einem speziellen Datum modifiziert wurden.

BackgroundWorker _worker;

Queue<string> _folderIdsToProcess;

private void ThisAddIn_Startup(object sender, System.EventArgs e) {

_folderIdsToProcess = new Queue<string>();

// Get the Inbox folder

Outlook.MAPIFolder inboxFolder = GetInboxFolder();

// and add it to the queue

_folderIdsToProcess.Enqueue(inboxFolder.EntryID);

// build a filter

// note that this filter is build a little bit complicated

// This works even if you are using an Outlook even with another language format, not only en-us

DateTime from = DateTime.Now.AddMonths(-1);

DateTime to = DateTime.Now;

string filter = string.Format("[LastModificationTime] > '{0}/{1}/{2}' AND [LastModificationTime] <='{3}/{4}/{5}'"

, from.Year, from.Month, from.Day

, to.Year, to.Month, to.Day);

// Setup the background thread

_worker = new BackgroundWorker();

_worker.DoWork += new DoWorkEventHandler(_worker_DoWork);

_worker.WorkerSupportsCancellation = true;

_worker.RunWorkerAsync(filter);

}

void _worker_DoWork(object sender, DoWorkEventArgs e) {

BackgroundWorker worker = (BackgroundWorker)sender;

string filter = (string)e.Argument;

Outlook.MAPIFolder folder;

int watchDog = 0;

while (_folderIdsToProcess.Count > 0 && !worker.CancellationPending) {

// pick one folder

string entryId = _folderIdsToProcess.Dequeue();

folder = Globals.ThisAddIn.Application.Session.GetFolderFromID(entryId, Type.Missing);

Outlook.Items items = folder.Items.Restrict(filter);

// Iterate over all Inbox items and get the Subject

for (int index = items.Count; index > 0; index--) {

if (worker.CancellationPending) break;

object item = items[index];

Trace.WriteLine(item.GetType().InvokeMember("Subject", BindingFlags.GetProperty, null, item, null));

item = null;

// Ensures that not too many RPC connections are made to a Server

watchDog++;

if (watchDog > 100) {

watchDog = 0;

GC.Collect();

GC.WaitForPendingFinalizers();

}

for (int index = folder.Folders.Count; index > 0; index--) {

if (worker.CancellationPending) break;

Outlook.MAPIFolder subFolder = folder.Folders[index];

// Call this function recursively

_folderIdsToProcess.Enqueue(subFolder.EntryID);

subFolder = null;

// Ensures that not too many RPC connections are made to a Server

watchDog++;

if (watchDog > 100) {

watchDog = 0;

GC.Collect();

GC.WaitForPendingFinalizers();

}

items = null;

folder = null;

}

private void ThisAddIn_Shutdown(object sender, System.EventArgs e) {

if (_worker.IsBusy) {

_worker.CancelAsync();

}

Leider lassen sich zum Filtern nicht alle Eigenschaften eines Objekts verwenden.

Das Table Objekt

Seit Outlook 2007 gibt es ein neues Table Objekt im OOM welches schnellen Zugriff auf die Tabellendaten eines Ordners verspricht. Der Zugriff ist schnell, den man kann entscheiden welche Spalten überhaupt benötigt werden und muss nicht jedes mal ein komplettes Objekt durchladen. Die beste Performanz erhält man natürlich, wenn man nur die Daten in die Tabelle lädt, welche man zum Verarbeiten der Daten benötigt. Leider gilt auch hier, dass nicht sämtliche Daten direkt in der Tabelle bereitgestellt werden können. In unserem code verwenden wir ja nur die Eigenschaft Letztes Änderungsdatum(LastModificationTime) und den Betreff(Subject). Prüfen wir als mal wie schnell wir die Daten lesen können. Um den Vorgang zu messen, wird der Anwendungscode noch etwas modifiziert – es wird die Anzahl der Objekte gezählt, als auch die Verarbeitungszeit. Bei Verwendung von Outlook Objekten erhalten wir im Durschschnitt folgendes Ergebnis:

Processing 773 items took 11262ms

Nach Umbau des Codes mit Verwendung des Table-Objektes, liefert der Test auf meinem System aber folgende Werte:

Processing 773 items took 15162ms

Interessant. In all meinen Tests unter Verwendung von Outlook2010 (Beta2) zeigte der Test, dass die Verwendung des Folder.Table -Objektes langsamer war, als direkt über die Items selbst eine schleife laufen zu lassen. Theoretisch sollte die Verwendung von GetTable() wesentlich schneller sein, als alle Outlook Objekte durchzuladen. Dem ist aber nicht so – vielleicht liegt es aber auch an der Beta-Version von Outlook 2010.

Hier ist das Beispiel für die Verwendung des Table-Objektes:

BackgroundWorker _worker;

Queue<string> _folderIdsToProcess;

private void ThisAddIn_Startup(object sender, System.EventArgs e)

{

_folderIdsToProcess = new Queue<string>();

// Get the Inbox folder

Outlook.MAPIFolder inboxFolder = GetInboxFolder();

// and add it to the queue

_folderIdsToProcess.Enqueue(inboxFolder.EntryID);

// build a filter

DateTime from = DateTime.Now.AddMonths(-6);

DateTime to = DateTime.Now;

string filter = string.Format("[LastModificationTime] > '{0}/{1}/{2}' AND [LastModificationTime] <='{3}/{4}/{5}'"

, from.Year, from.Month, from.Day

, to.Year, to.Month, to.Day);

// Setup the background thread

_worker = new BackgroundWorker();

_worker.DoWork += new DoWorkEventHandler(_worker_DoWork);

_worker.WorkerSupportsCancellation = true;

_worker.RunWorkerAsync(filter);

}

void _worker_DoWork(object sender, DoWorkEventArgs e) {

BackgroundWorker worker = (BackgroundWorker)sender;

string filter = (string)e.Argument;

Outlook.MAPIFolder folder;

int itemsProcessed = 0;

Stopwatch watch = new Stopwatch();

watch.Start();

int watchDog = 0;

while (_folderIdsToProcess.Count > 0 && !worker.CancellationPending) {

// pick one folder

string entryId = _folderIdsToProcess.Dequeue();

folder = Globals.ThisAddIn.Application.Session.GetFolderFromID(entryId, Type.Missing);

Outlook.Table table = folder.GetTable(filter, Outlook.OlTableContents.olUserItems);

// try to get the first row

Outlook.Row row = table.GetNextRow ();

// Iterate over all Inbox items and get the Subject

while (!table.EndOfTable ) {

if (worker.CancellationPending) break;

string subject = (string) row["Subject"];

Trace.WriteLine(subject);

itemsProcessed++;

row = table.GetNextRow();

// Ensures that not too many RPC connections are made to a Server

watchDog++;

if (watchDog > 100) {

watchDog = 0;

GC.Collect();

GC.WaitForPendingFinalizers();

}

for (int index = folder.Folders.Count; index > 0; index--) {

if (worker.CancellationPending) break;

Outlook.MAPIFolder subFolder = folder.Folders[index];

// Call this function recursively

_folderIdsToProcess.Enqueue(subFolder.EntryID);

subFolder = null;

// Ensures that not too many RPC connections are made to a Server

watchDog++;

if (watchDog > 100) {

watchDog = 0;

GC.Collect();

GC.WaitForPendingFinalizers();

}

table = null;

folder = null;

}

Trace.WriteLine(string.Format("Processing {0} items took {1}ms", itemsProcessed, watch.ElapsedMilliseconds));

}

private void ThisAddIn_Shutdown(object sender, System.EventArgs e)

{

if (_worker.IsBusy) {

_worker.CancelAsync();

}

Eine weitere Verbesserung könnte die Verwendung eines weiteren Threads sein. Ein Thread zum Auswerten, ob Items überhaupt verarbeitet werden müssen, ein weiterer Thread zum Verarbeiten der Items. Die Komplexität wird dadurch aber wesentlich erhöht, deshalb möchte ich hier darauf verzichten.

Vermeidung von GC.Collect()

Obwohl es nötig ist GC.Collect() bei der Programmierung von Outlook-Anwendungen ab und zu an verschiedenen Stellen aufzurufen, sollte dies nur sehr selten und nur wenn es unbedingt nötig ist geschehen. Ein Erzwingen von GC.Collect() beeinflusst die Laufzeit aller .Net Anwendungen. Innerhalb einer Schleife verwenden wir GC.Collect() nur deshalb um ein spezifisches Problem in Verbindung mit einem Exchangeserver zu umgehen. Wenn Outlook gar keinen Exchangeserver verwendet – oder offline d.h. nicht Verbunden ist, wird GC.Collect() nicht benötigt. Deshalb könnte man hier noch etwas optimieren.

Unten steht der optimierte Code:

private void IncreaseWatchdogAndCallGCIfOnline(ref int watchDog) {

watchDog++;

if (watchDog > 100) {

Outlook.OlExchangeConnectionMode mode = Globals.ThisAddIn.Application.Session.ExchangeConnectionMode;

if (mode == Outlook.OlExchangeConnectionMode.olCachedConnectedDrizzle

|| mode == Outlook.OlExchangeConnectionMode.olCachedConnectedFull

|| mode == Outlook.OlExchangeConnectionMode.olCachedConnectedHeaders

|| mode == Outlook.OlExchangeConnectionMode.olOnline) {

// Ensures that not too many RPC connections are made to a Server

GC.Collect();

GC.WaitForPendingFinalizers();

}

watchDog = 0;

}

GC.Collect() wird nur aufgerufen, wenn Outlook online mit einem Exchangeserver verbunden ist.

References

Outlook Folder Object: http://msdn.microsoft.com/en-us/library/bb176362.aspx
Outlook Table Object: http://msdn.microsoft.com/en-us/library/bb176406.aspx
.Net Queue Object: http://msdn.microsoft.com/en-us/library/7977ey2c.aspx

Hard- u. Softwarepreise gewinnen bei TecChannel.de

Helmut Obertanner — Thu, 26 Nov 2009 08:48:23 GMT

Hurrah! – Ich habe gewonnen – und zwar einen Toshiba Netbook. Wie kam es dazu? Durch Mitmachen und veröffentlichen eines kleinen Beitrags in der Rubrik "Never change a running System" bei TecChannel.de. Vielen herzlichen Dank an alle Benutzer, die für meinen Beitrag gestimmt haben. Aktuell gibt es hier noch eine Gewinnaktion auf TecChannel.de – hier ist der Link: http://www.tecchannel.de/server/2021595/quiz_mitmachen_und_gewinnen_preise_sieger/

Also – mitmachen und gewinnen – es lohnt sich!

Neue Entwickler-Informationen für Office 2010(Beta)

Helmut Obertanner — Thu, 12 Nov 2009 18:50:56 GMT

Heute hat das Outlook-Team neue Informationen für Entwickler zu Office2010(Beta version) auf MSDN bereitgestellt.

http://msdn.microsoft.com/en-us/library/ee692176(office.14).aspx

Das ist neu für Outlook-Entwickler:

http://msdn.microsoft.com/en-us/library/ee692174(office.14).aspx