Fr das bereits im vorherigen Post angesprochene kleine Bestellwesen muáte ich noch einen Eventhandler programmieren. Dieser sollte beim Hinzufgen einer neuen Bestellung aktiviert werden und den zu der eingegebenen Kostenstelle geh”renden Teamleiter aus einer anderen Liste auslesen und zur aktuellen Bestellung hinzufgen. Und dabei hatte ich wieder das Vergngen, mich mit den Sharepoint-Eventhandlern zu besch„ftigen 
Der eben beschriebene Eventhandler sollte also an das Listen-Event ItemAdding gekoppelt werden und ben”tigt einen Wert aus der Spalte Kostenstelle – also aus den Daten, die der momentane Benutzer gerade eben vor Ausl”sen des Events eingegeben hat. Um herauszufinden, wie man an diese eben eingegebenen Daten kommt, habe ich mir den šbergabeparameter eines Sharepoint-Eventhandlers einmal genauer angesehen. Ein Eventhandler bekommt bei seinem Aufruf genau einen Parameter vom Typ SPItemEventProperties mit. Als ich mir diesen Parameter n„her angesehen habe, bemerkte ich, dass hier auch ein Element vom Typ SPListItem enthalten ist. Leider stellte sich aber beim Debuggen heraus, dass dieses Element zumindest beim Event ItemAdding null ist. OK, bei n„herem Nachdenken macht das auch Sinn, denn schlieálich wurde die Verarbeitung der eingegebenen Daten noch nicht abgeschlossen und der eigentliche Speichern-Vorgang steht noch aus.
Aber wie komme ich dann an die eben eingegebenen Daten? Ein weiterer Blick auf die SPEventProperties … ok, versuchen wir es doch mal mit den BeforeProperties. Im SDK werden die BeforeProperties folgendermaáen beschrieben:"Gets a hash table of properties consisting of string/value pairs that correspond to fields in the Sharepoint.SPItem object before the event occurred." Das ist doch genau das, was ich gesucht habe: die Spaltennamen mit ihren Werten zum Zeitpunkt, bevor der Event gefeuert wurde. Um es kurz zu machen: beim ItemAdding-Event sind die BeforeProperties ebenfalls null. 
Bleiben mir nur noch die AfterProperties. Die SDK-Beschreibung sagt dazu: "Gets a hash table of properties consisting of string/value pairs that correspond to fields in the Sharepoint.SPItem object after the event occurred." Dies klingt etwas seltsam, denn das ItemAdding-Event wird genau dann gefeuert, wenn ein neuer Datensatz gerade eben hinzugefgt werden soll. Der Event l„uft also eigentlich noch und eigentlich sollte es deswegen keine AfterProperties geben k”nnen. Aber weit gefehlt: hier stehen genau die Daten die ich gesucht habe. 
Mein Eventhandler sucht also jetzt den Teamleiter, der zu der angegebenen Kostenstelle geh”rt. Um den Namen des Teamleiters zu den Daten, die der momentane Benutzer gerade eben eingegeben hat, hinzuzufgen, benutze ich auch wieder die AfterProperties. In der Bestelllisten gibt es eine versteckte Spalte 'Teamleiter', die ausschlieálich vom Eventhandler ausgefllt werden soll. Mein Eventhandler hat anhand der Kostenstelle den Namen des Teamleiters gefunden und schreibt diese wie folgt in die Listendaten zurck:
SPEventProperties myProperties = properties;
myProperties.AfterProperties["Teamleiter"] = "Max Mustermann";
Weil mir die Sache mit den Eventproperties etwas seltsam vorkam, habe ich noch etwas Zeit fr einen kleinen "Drill down" investiert. Beim Entwicklen von Eventhandlern ist es sehr wichtig, nicht die fr den Anwender sichtbaren Spalten-Namen zu verwenden (also die Display Names), sondern die sprachunabh„ngigen internen Spaltennamen (Internal Name). Wenn man den display name einer Spalte kennt, bekommt man den internal name z.B. so:
string strInternalname = myList.Fields[strDisplayname].InternalName;
Zurck zu den Eventhandlern und den šbergabeparametern vom Typ SPItemEventProperties! Ich habe mir diese Properties auch beim Event ItemUpdating angesehen. Hier ist das Element ListItem nicht null und enth„lt die Daten vor der Žnderung durch den Benutzer (also die ursprnglichen, unver„nderten Daten). Die BeforeProperties sind wieder null – (h„tte ich in diesem Fall nicht erwartet) – und die AfterProperties enthalten die neuen, ver„nderten Daten. Bis auf die leeren BeforeProperties ist also alles, wie erwartet. Warum aber werden die BeforeProperties nicht gesetzt? Um diese Frage zu kl„ren, habe ich meinen "Drill down" fortgesetzt und nun keine Liste mehr verwendet, sondern eine Dokumentenbiliothek. Und siehe da: bei einer Dokumentenbiliothek werden die BeforeProperties verwendet und hier enthalten diese auch den alten, unver„nderten Wert.
Fazit: durchg„ngig konsistent scheint die Sache mit den SPItemEventProperties noch nicht zu sein. Warum BeforeProperties offensichtlich nur bei Dokumentbiliotheken, nicht aber bei Listen verwendet werden, ist mir unverst„ndlich. Vielleicht bringt eine Nachfrage bei Microsoft eine Erkl„rung – ich werde dies machen und ber das Ergebnis zw. die Antwort hier im Blog berichten.
oliver wirkus