Meine SharePoint-Notizen

Ein Mitarbeiter eines unserer Kunden rief mich vor kurzem an, um mir ein ungew”hnliches Verhalten beim Žndern seines Passwortes zu schildern. Nachdem er sein Passwort mit Hilfe eines unserer WebParts ge„ndert hatte, konnte er sich dennoch weiterhin mit seinem alten Passwort anmelden. Eine Fehlermeldung beim Žndern seines Passworts habe es nicht gegeben. Daraufhin habe er versucht, sich mit seinem neuen (also dem ge„nderten) Passwort anzumelden und auch mit diesem konnte er sich anmelden. Da er sich sowohl mit altem, als auch mit neuem Passwort anmelden konnte, vermutete er nun einen Fehler in unserem Passwort-Žndern-WebPart.

Unser WebPart zum Žndern von Passw”rtern greift auf ein ActiveDirectory zu. Und genau hier liegt die Erkl„rung zu diesem ungew”hnlichen Verhalten. Nach dem Einspielen des SP1 fr Windows Server 2003 verl„ngert sich das Zeitfenster in dem sowohl das alte, als auch das neue Passwort gltig sind, auf 1 Stunde. Dies bedeutet, dass das alte Passwort unter Umst„nden noch eine Stunde gltig bleibt, nachdem es bereits vom Benutzer ge„ndert wurde.

Dieses Zeitfenster l„át sich aber durch Žnderungen an einem Registry-Key auf 1 Minute verkrzen. Microsoft hat die n”tigen Žnderungen hier beschrieben: http://support.microsoft.com/kb/906305/en-us

Dieses Problem lies sich also schnell l”sen – auch deswegen, weil diese Žnderung keinen Neustart des Servers erfordert!

Das neue Jahr 2008 hat fr mich gleich mit einem interessanten SharePoint-Problem begonnen. Einer unserer Kunden berichtete mir von Abstrzen im Internet Explorer, wenn auf Dokumente (im vorliegenden Fall waren es PDF-Dateien) in einer SharePoint-Dokumentbibliothek geklickt wurde. Allerdings wrden diese Abstrze nicht bei allen PCs, sondern nur bei einigen wenigen PCs auftreten.

Ich habe mir die Sache also vor Ort angesehen und tats„chlich war es so. Beim Linksklick auf eine beliebige Datei in einer beliebigen Dokumentbibliothek kam es zu einer unbehandelten Exception im Internet Explorer und fr den Benutzer sah es wie ein Absturz des IE aus. Betroffen waren brigens sowohl IE6 als auch IE7. Und auch die zweite Aussage lies sich nachvollziehen: das geschilderte Problem trat nur bei einigen wenigen PCs auf. Die meisten der PCs vor Ort zeigten dieses Problem dagegen nicht.

Nach einigem Recherchieren und einem genaueren Blick auf die betroffenen PCs fand ich dann aber doch die Ursache des Problems: auf allen PCs war Office 11 installiert, auf den betroffenen PCs zus„tzlich noch eine Komponente aus dem aktuellen Office 12 – SharePoint Designer bzw. Groove. Diese Office 12-Komponenten registrieren im Internet Explorer ein AddOn (OWSSUPP.DLL), welches offensichtlich die geschilderten Probleme verursacht.

Es gibt nun mehrere L”sungsm”glichkeiten:

• deaktivieren des AddOns im Internet Explorer (m”glicherweise aber dadurch Verlust an SharePoint-Funktionalit„t)
• verwenden der OWSSUPP.DLL aus Office 11 (dazu muss diese aber systemweit registriert werden. N„heres dazu findet sich hier)
• Einspielen eines Patches von Microsoft. Hier der Link dazu: http://support.microsoft.com/kb/938888

Damit waren in meinem Fall die Probleme gel”st, allerdings nicht ohne noch eine Office-11 Reparatur durchzufhren! Ich werde das geschilderte Problem aber weiter beobachten und ggf. weitere Erkenntnisse an dieser Stelle posten.

Ein groáer Vorteil der SharePoint Suche ist die Erweiterbarkeit der Indizierungsengine. Dazu ein Beispiel: normalerweise werden z.B. PDF-Dateien nicht indiziert und somit bei einer Suche auch nicht bercksichtigt. M”chte man nun, dass z.B. PDF-Dateien, die auf einem Fileserver im Unternehmen abgelegt sind, indiziert werden, dann reicht es aus, einen sogenannten IFilter zu installieren. Ich mache es normalerweise bei allen Kundenportalen so, dass ich den Adobe PDF IFilter standardm„áig installiere. Diese Installation alleine reicht aber nicht aus – um eine mauelle Nacharbeitung kommt man leider nicht herum.

Die n”tigen Schritte, um den Adobe PDF-IFilter vollst„ndig in SharePoint zu integrieren, m”chte ich hier auflisten:

• den Adobe PDF IFilter kann man sich hier kostenlos herunterladen
• danach wird das heruntergeladene Setup auf dem SharePoint-Server installiert
• im Verzeichnis ProgrammeGemeinsame DateienMicrosoft Sharedweb server extensions12TEMPLATEIMAGES muá nun ein Icon fr den Dokumenttyp hinterlegt werden. Normalerweise heiát diese Icon-Datei: icpdf.gif – ich stelle hier eine Version zum Download bereit:
• im Verzeichnis ProgrammeGemeinsame DateienMicrosoft Sharedweb server extensions12TEMPLATEXML befindet sich eine Datei mit dem Namen DOCICON.XML. Diese muá auch editiert werden. Unterhalb der Zeile <ByExtension> muá die folgende Zeile eingefgt werden: <Mapping Key="pdf" Value="icpdf.gif"/>. Hierdurch wird die Verbindung zwischen dem Dokumenttyp PDF und dem zugeh”rigen Dokumenttyp-Icon hergestellt. Wichtig dabei: das hinter 'Value=' eingetrage Icon muss natrlich genauso heiáen, wie das Icon, welches im Verzeichnis IMAGES (siehe oben) hinterlegt wurde
• nun muá man noch in die SharePoint Zentraladministration wechseln und dort in den Sucheinstellungen des betreffenden SharedService einen neuen Dateityp "pdf" eintragen.
• nun sollte ein IISReset durchgefhrt werden
• damit sollte der IFilter fr PDF-Dateien in SharePoint vollst„ndig eingebunden sein. Um dies zu berpfen, sollte der Suchindex aktualisiert bzw. neu erstellt werden

šbrigens: unter http://www.ifilter.org/ findet man eine Liste von IFiltern, die u.a. fr SharePoint, aber auch fr die Windows Desktop Suche verwendet werden k”nnen.

Manche Leser haben es sicher bemerkt – in letzter Zeit wurde es ein wenig ruhiger hier im Blog. Der Grund dafr war die Vorbereitungszeit fr meinen Vortrag fr den Shared Solutions Day 2007, der von der ServicePortals GmbH organisierte wurde und gestern hier im Technologiepark Karlsruhe statt fand. Als einer der Gastredner durfte ich am Nachmittag einen Vortrag zum Themenkomplex "Anbindung von Microsoft Office (inkl. MOSS und DUET) an ein SAP-System" halten. Die positive Resonanz der geladenen G„ste auf meinen Vortrag hat mich sehr gefreut und die anschlieáenden Gespr„che haben mir gezeigt, dass "SAP und Office" bei vielen Firmen zu einem wichtigen Thema in der Unternehmensstrategie geworden ist.

Wer sich ber den Shared Solutions Day 2007 informieren m”chte, der findet das Programm ber diesen Link.

Bei der Vorbereitung zu meinem Vortrag, in dem ich unter anderem auch auf das Thema DUET eingegangen bin, habe ich einige Male mit dem Gold Partner Support und dem PreSales-Support von Microsoft telefoniert. Dabei habe ich einige interessante Neuigkeiten zur DUET-Roadmap erfahren:

Die Version 2.0 von DUET wurde abgekndigt! Ein Teil der geplanten Funktionalit„t wird bereits in der DUET-Version 1.5, die im zweiten Halbjahr 2008 erwartet wird, implementiert werden. Dies betrifft die Untersttzung fr Office 2007, MOSS2007 und Exchange Server 2007. Die Version 3.0 von DUET wird zusammen mit der n„chsten Office-Version (Versionsnummer 14) erwartet. Wie viele andere Software-Firmen auch, so scheint auch Microsoft eine Version 13 zu berspringen.

Nachtrag: ich wurde von einigen Lesern gefragt, ob ich meinen Vortrag nicht als Download zur Verfgung stellen k”nnte. Dies mache ich natrlich gern, ich wollte aber abwarten, bis alle Teilnehmer des Shared Solutions Day eine Kopie des Vortrags bekommen haben.

Da dies nun erfolgt ist, stelle ich meinen Vortrag als Download zur Verfgung: Vortrag zum Shared Solutions Day 2007

Ich bitte aber um die Wahrung meines Urheberrechts (Copyright). Dies bedeutet: wer Teile meines Vortrags weiterverwenden und/oder ver”ffentlichen will, ben”tigt dazu meine schriftliche Genehmigung. Deswegen bitte ich um vorherige Kontaktaufnahme!

Zur Entpannung spiele ich manchmal gern ein wenig Mahjong. Zugegeben: Windows Vista war fr mich auch deswegen interessant, weil es mit Mahjong Titans eine grafisch sehr sch”ne Umsetzung dieses Spiels bietet.

Als ich vor Kurzem abends noch ein wenig Mahjong Titans gespielt habe, muss ich mit dem Mauszeiger offensichtlich etwas verrutscht sein und habe einen falschen Stein angeklickt. Normalerweise taucht dann eine MessageBox auf, die mich darber informiert, dass diese beiden Steine nicht zusammenpassen. Ist bei zwei unpassenden Steinen aber einer ein Jahreszeiten-Stein, wird eine andere MessageBox angezeigt:

Ich frage mich, ob neben Deutsch noch andere Sprachen existieren, in denen es auch solche Wortungetme gibt?

šbrigens - mit Blumen gibt es das auch:

Bei Codeplex findet sich ein interessantes Webpart. Dieses wurde ursprnglich von Bamboo Solutions (http://www.bamboosolutions.com/) entwickelt und dient zur Anzeige von Wetter- und Zeitinformationen ausgew„hlter St„dte.

Was die Sache aber interessant macht, ist die Tatsache, dass neben dem eigentlichen Webpart auch der Sourcecode zur Verfgung gestellt wird. Jeder kann sich also das Webpart (inkl. Installer) und den Source dazu von Codeplex laden. Neben einem interessanten Gadget fr z.B. die Startseite eines Portals bekommt man so auch ein wenig Einblick in die Programmierung bei Bamboo Solutions und kann sich den einen oder anderen Programmiertrick abgucken. Sicher nicht uninteressant!

Hier der Link zu Codeplex: http://www.codeplex.com/Release/ProjectReleases.aspx?ProjectName=CKS&ReleaseId=7649

Bei mehreren SharePoint-Installationen ist mir aufgefallen, dass die Benachrichtigungsmail, die aufgrund eines gestarteten Genehmigungsworkflows verschickt wurde, eine etwas eigenwillige (um nicht zu sagen: defekte) Formatierung auswies. Ein Beispiel einer solchen eMail zeigt der folgende Screenshot.

Seltsamerweise war immer nur die erste eMail eines Genehmigungsprozesses betroffen. Alle weiteren eMails wurde korrekt formatiert verschickt. Nach einigem Recherchieren bin ich dann darauf gestossen, dass es hierfr von Microsoft ein Hotfix gibt. Es tr„gt die Bezeichnung KB937906.

Nachdem ich auf unseren SharePoint-Installationen dieses Hotfix eingespielt hatte (ein Neustart oder Žhnliches war nicht erforderlich), war das Problem gel”st – auch die erste Benachrichtigungsmail wird nun korrekt formiert verschickt.

Wenn doch nur alle SharePoint-Probleme so einfach zu l”sen w„ren

Obwohl es sich bei dem kleinen Bestellwesen eigentlich um keine groáe Sache handeln sollte, liefert es doch tats„chlich Stoff fr mittlerweile 3 Posts in meinem Blog.

Das besagte und bereits ”fters erw„hnte Bestellwesen benutzt Workflows und EventHandler, um das Genehmigen von Bestellungen zu realisieren. Da es mehrere Personengruppen und auch Einzelpersonen gibt, die eine Bestellung genehmigen drfen, haben wir eine SharePoint-Benutzergruppe erzeugt und hier einige Einzelpersonen und zwei ActiveDirectory-Benutzergruppen hinzugefgt.

In einem EventHandler ging es nun darum, zu prfen, ob der aktuelle Benutzer das Recht hat, eine Bestellung zu genehmigen. Prinzipiell ist diese Abfrage nicht besonders schwierig: sobald der aktuelle Benutzer ein Mitglied der SharePoint-Gruppe "Genehmiger" ist, darf er Bestellungen genehmigen. Da ein EventHandler beim Aufruf ber den Parameter SPItemEventProperties auch den aktuellen Benutzer bzw. seinen LoginNamen bekommt, beschr„nkt sich die Abfrage auf die Mitgliedschaft in der SharePoint-Gruppe "Genehmiger".

Der erste Ansatz, diese Abfrage zu realisieren, war dieser: ber den LoginNamen bestimmt man das zugeh”rige SPUser-Objekt. Dies k”nnte man z.B. ber die AllUsers-Collection des Webs machen, zu dem die Liste geh”rt, die den Event ausgel”st hat. Auch diese Informationen bekommt man ber die SPItemEventProperties. Hat man das SPUser-Objekt gefunden, kann man die Groups-Collection des SPUsers nach der Gruppe "Genehmiger" durchsuchen. Dieses Verfahren ist zwar naheliegend, funktioniert aber leider nur mit den als Einzelperson in der SharePoint-Gruppe "Genehmiger" eingetragenen Personen. Die ebenfalls dort eingetragenen ActiveDirectory-Gruppen werden hierbei nicht bercksichtigt.

Wie schafft man es aber nun, dass bei der Abfrage der Gruppenzugeh”rigkeit auch ActiveDirectory-Gruppen innerhalb einer SharePoint-Gruppe bercksichtigt werden?

Das klappt, wenn man den umgekehrten Weg aus dem ersten Ansatz w„hlt. Dies bedeutet: man geht nicht ber den SPUser und dessen Groups-Collection, sondern besorgt sich z.B. ber die SiteGroups-Collection des RootWebs des aktuellen Webs die ID der Gruppe "Genehmiger". Anschlieáend kann man die Methode IsCurrentUserMemberOfGroup() des RootWeb-Objekts benutzen, um herauszufinden, ob der aktuelle Benutzer Mitglied der SharePoint-Gruppe "Genehmiger" ist. Dazu gibt man der Methode IsCurrentUserMemberOfGroup() nur die zuvor besorgte ID der SharePoint-Gruppe "Genehmiger" mit. Mit diesem Aufruf werden dann auch die ActiveDirectory-Gruppen innerhalb der Sharepoint-Gruppe bercksichtigt.

Fr das bereits im vorherigen Post angesprochene kleine Bestellwesen muáte ich noch einen Eventhandler programmieren. Dieser sollte beim Hinzufgen einer neuen Bestellung aktiviert werden und den zu der eingegebenen Kostenstelle geh”renden Teamleiter aus einer anderen Liste auslesen und zur aktuellen Bestellung hinzufgen. Und dabei hatte ich wieder das Vergngen, 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 hinzugefgt 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, hinzuzufgen, benutze ich auch wieder die AfterProperties. In der Bestelllisten gibt es eine versteckte Spalte 'Teamleiter', die ausschlieálich vom Eventhandler ausgefllt werden soll. Mein Eventhandler hat anhand der Kostenstelle den Namen des Teamleiters gefunden und schreibt diese wie folgt in die Listendaten zurck:

SPEventProperties myProperties = properties;

Weil mir die Sache mit den Eventproperties etwas seltsam vorkam, habe ich noch etwas Zeit fr einen kleinen "Drill down" investiert. Beim Entwicklen von Eventhandlern ist es sehr wichtig, nicht die fr 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:

Zurck 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 ursprnglichen, 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.

Bei einem Projekt wurde gefordert, dass wir ein kleines Bestellwesen für Büromaterial auf einer Seite eines SharePoint-Portals implementieren. 'Keine große Sache' dachte ich mir und begann mit dem Design. Das Bestellwesen sollte auf einer einfachen SharePoint-Liste basieren und die Benachrichtigungen an die User sollten über Workflows erfolgen, die mit dem SharePoint-Designer erstellt werden. Wie gesagt – keine große Sache! (Anmerkung: die Anforderungen an das Bestellwesen waren natürlich größer, als hier dargestellt. Es soll hier nur als Beispiel dienen.)

Die Probleme begannen aber, als ich mir Gedanken über ein Status-Feld machte. Zu jeder Bestellung sollte es ein Status-Feld geben, in dem der Status der Bestellung (z.B. offen / genehmigt / bestellt / eingetroffen / abgelehnt) hinterlegt ist. Dieses Statusfeld sollte auch als Trigger für die Workflows benutzt werden. Gepflegt werden sollte dieses Statusfeld ausschließlich vom Sekretariat, weil hier auch die Bestellungen bearbeitet werden. Ein Mitarbeiter sollte nur eine neue Bestellung aufgeben, nicht aber seine Bestellung -und somit das Statusfeld- nachträglich bearbeiten können.

Somit war das Problem klar: bei der Eingabe einer neuen Bestellung sollte das Feld (bzw. die Spalte) 'Status' nicht veränderbar sein, beim Bearbeiten einer Bestellung hingegen schon. Beim Ansehen einer Bestellung sollte der Status natürlich auch ganz normal angezeigt werden.

Nach einigem Recherchieren und dem Hinweis eines Entwicklerkollegen habe ich eine Lösung gefunden.

SharePoint verwendet spezielle Forms, wenn Daten einer Liste hinzugefügt, editiert oder betrachtet werden. Beim Eingeben eines neuen Datensatzes in eine Liste wird die Form NewForm.aspx verwendet, beim Editieren eines Datensatzes wird EditForm.aspx verwendet und beim Betrachten eines Datensatzes wird DispForm.aspx verwendet.

Für das geschilderte Problem wäre es hilfreich, wenn die Status-Spalte nur bei 'EditForm' und 'DispForm' angezeigt werden würde, nicht aber bei 'NewForm'. Mitarbeiter verwenden beim Aufgeben einer neuen Bestellung 'NewForm'. Das Sekretariat verwendet 'EditForm' zum Ändern des Wertes der Status-Spalte (Mitarbeiter können eine einmal aufgegebene Bestellung nicht mehr verändern) und beide verwenden 'DispForm', um sich über den Stand einer Bestellung zu informieren.

Leider findet man eine entsprechende Einstellmöglichkeit nicht in den Eigenschaften einer SharePoint-Liste oder Bibliothek. Dennoch ist es aber möglich, für einzelne Listen festzulegen, welche Spalten in welcher Form angezeigt werden sollen – ein Blick in das SDK bzw. das Objektmodell von SharePoint hilft hier weiter.

Eine Liste wird im SharePoint-Objektmodell durch das Objekt SPList repräsentiert. Spalten werden durch das Objekt SPField repäsentiert und alle Spalten einer Liste werden in der Collection Fields des Objekts SPList zusammengefasst.

Um  eine spezielle Spalte bzw. deren SPField-Objekt aus dieser Collection zu bekommen, gibt es zwei Möglichkeiten. Die erste Möglichkeit besteht im bekannten Array-Zugriff (z.B. Fields["Status"]). Hierbei ist zu beachten, dass als Spaltenname der sprachabhängige Anzeigename (display name) verwendet wird. Die zweite Möglichkeit besteht darin, die Methode GetFieldByInternalName() der Collection Fields aufzurufen. Wie der Methodenname schon vermuten läßt, wird hier nicht der sprachabhängige Anzeigename als Parameter verwendet, sondern der sprachunabhängige interne Spaltenname (internal name). Die Unterscheidung zwischen display name und internal name ist also sehr wichtig und sollte bei der Programmierung beachtet werden!

Hat man nun das gewünschte SPField-Objekt und schaut es sich etwas genauer an, findet man u.a. diese drei Eigenschaften: ShowInEditForm, ShowInNewForm und ShowInDisplayForm. Alle drei sind vom Typ bool und sind standardmäßig auf null gesetzt. Um eine Spalte z.B. in der NewForm auszublenden, setzt man einfach die Eigenschaft ShowInNewForm der entsprechenden Spalte auf false. Um eine bestimmte Spalte wieder einzublenden, setzt man die entsprechende Eigenschaft auf true und um die Eigenschaft wieder auf ihren Standardwert zurückzusetzen, weist man dieser den Wert null zu. Diese Einstellungen brauchen nur ein einziges Mal vorgenommen zu werden, da sie wie alle anderen Listeneigenschaften auch gespeichert werden.

Zur Illustration (und weil ich es sicherlich auch noch öfters brauchen werde) habe ich eine kleine Windows-Applikation geschrieben (siehe Screenshot). Nach dem Starten der Applikation wählt man eine Site und eine Liste aus. Jetzt werden alle Spalten der ausgewählten Liste angezeigt und man kann einstellen, bei welcher Form welche Spalte angezeigt bzw. ausgeblendet werden soll. Zusätzlich kann man noch die Breite der Spalte (für NewForm und EditForm) einstellen und festlegen, ob diese read only sein soll. Um die Sache mit den unterschiedlichen Spaltenname (display name und internal name) zu verdeutlichen, kann zwischen beiden umgeschaltet werden. Dieses Tool kann man sich von unserer Homepage kostenlos (gegen eine kleine Registrierung) herunterladen – hier der Link.

Ich möchte an dieser Stelle noch erwähnen, dass es sich hierbei um ein Entwickler-Tool, welches direkt auf einem SharePoint-Server gestartet werden muss, handelt. Es dient ausschließlich als Anschauungsobjekt, kann und die Benutzung erfolgt auf eigenes Risiko!

Das SPField Objekt bietet aber noch einige weitere interessante Eigenschaften und Methoden. In nächster Zeit werde ich mich sicherlich noch mehrmals mit dem SPField Objekt beschäftigen. Weitere Erkenntnisse oder Updates zum genannten Tool werde ich dann hier posten.