Montag, 5. Oktober 2009

Prevent expanding grouping in listviews

Recently I got the requirement from a customer to deactivate the auto-expanding of groups in a single AllItems.aspx-Default-Listview that was grouped and should show at least 700 items per page.
First attempts where in vain to deactivate viewStates from the control or change webpart-attributes. A more promising approach seemed to be deleting browser-cookies. Reloading Firefox after deleting cookies worked like a charm but I've got no success to reproduce this behaviour by code.

So I had to try another way and began to debug the SharePoint-JavaScript by using Firebug. That was a good decision because I discovered this method:

ProcessDefaultOnLoad(_spBodyOnLoadFunctionNames);

In here a simple array is iterated over that's items are getting executed by eval-function.
One of the array-items is "ExpGroupOnPageLoad". This function cares for expanding each group if it's found in the state-cookie.

A little bit googling about the JS-Variable _spBodyOnLoadFunctionNames gave me a little bit more overview and so I tried to remove the
ExpGroupOnPageLoad-entry in hope that the groups stayed collapsed after reload. And voila! It worked like a charm!

Just add this piece of code in your AllItems.aspx (or another view-file) and the list-groupings stay closed after page-reload, no matter, what groups the user expanded before:


<script type="text/javascript">
for (var i = 0; i < _spBodyOnLoadFunctionNames.length; i++) {
if (_spBodyOnLoadFunctionNames[i] == "ExpGroupOnPageLoad") {
// remove only this one element from array
_spBodyOnLoadFunctionNames.splice(i,1);
break;
}
}
</script>

Lange nichts gehört... / Long time ago...

Seit meinem letzten Post ist einige Zeit vergangen, in der ich auch ein paar Tage im Urlaub war. Schöne Grüße nach Mallorca, wo während meines Aufenthalts die schlimmsten Unwetter der letzten 40 Jahre herrschten ;-)

Seit letzter Woche bin ich zurück und ausgeruht um neue neue SharePoint-Abenteuer zu bestehen. Ich hoffe, dass ich zukünftige Postings in kürzeren Abständen schreiben kann. Diese werden dann, beginnend ab dem nächsten, komplett in Englisch sein. Ebenfalls habe ich vor, das etwas angestaubte Design des Blogs ein wenig zu überarbeiten.

Damit der Übergang zum Sprachwechsel nicht ganz so hart ausfällt, hier die englische Version:

English version:

Since my last post some time elapsed, which I used for making holidays and other lovely things.
Greetings to Mallorca, Spain that suffered from the heaviest thunderstorm since the last 40 years. ;-)

Now I'm back since last week and feel refreshed to look forward new SharePoint-Adventures. I hope to shorten the delays between my upcoming blogposts which I'll try to write henceforth completely in english. I also want to redesign the blog-layout a little bit.

So that the change-over for my reads isn't that hard, this posting is a mixture from german and english.

Dienstag, 18. August 2009

Länge des Mailbody in SPUtility.SendEmail begrenzt

Die Methode SendEmail der statischen Klasse SPUtility kann dazu verwendet werden, aus dem SharePoint-Kontext heraus E-Mails zu verschicken. Zu beachten ist dabei allerdings, dass der Mailbody nach 2048 Zeichen abgeschnitten wird. Für größere E-Mails, bzw. Inhalte mit aufwendigen HTML-Inhalten kann dies zum Problem werden.

Abhilfe schafft hier allerdings das Verwenden von New Lines innerhalb des Body-Strings.

Der Mailbody für SendEmail kann also mehr als 2048 Zeichen insgesamt verschicken, es dürfen allerdings nur maximal 2048 Zeichen pro Zeile stehen.


StringBuilder mailBody = new StringBuilder();
...
mailBody.AppendFormat("<tr style='{0}'><td style='padding-right:10px;'>{1}</td><td style='padding-right:10px;'>{2}</td><td style='padding-right:10px;'>{3}</td><td style='padding-right:10px;'>{4}</td></tr>", style, key, title, milestone, dueDate).AppendLine();
...

SPUtility.SendEmail(spWeb, false, false, toAddresses, "Subject", mailBody.ToString());

Donnerstag, 30. Juli 2009

Listeninstanzen - Cannot complete this action

Werden bei einer Solution ListInstances verwendet und sollen dann an speziell diese Listen CustomActions angehängt werden, empfiehlt es sich, anstelle der Standard-TemplateTypes (100, 101, etc..) eigene IDs ab 10000 zu verwenden.

Diese Änderung muss aber überall nachgezogen werden, sonst kommt es beim Erstellen der SiteCollection schnell zu der nichts sagenden Fehlermeldung "Cannot complete this action".



Die TemplateType-ID muss angepasst werden in
  • CustomAction
  • ListInstance
  • ListTemplate
  • Schema.xml

Donnerstag, 23. Juli 2009

verschwindendes WSPBuilder-Kontextmenü im Visual Studio

Ab und zu verschwindet nach dem Neustart des Visual Studios der Eintrag des WSPBuilders aus dem Projekt-Kontextmenü.



Den Grund dafür habe ich leider noch nicht gefunden. Abhilfe schafft hier aber folgender Prozess: Visual Studio schließen, WSPBuilder komplett deinstallieren und anschließend neuinstallatieren.
In den vorherigen Versionen war es dann noch nötig, die cablib.dll auszutauschen.
Seit der neuesten Version ist dies aber nicht mehr notwendig.

http://www.codeplex.com/wspbuilder

Mittwoch, 22. Juli 2009

Code-Debugging auf Tastendruck II

Um SPTimerJobs zu debuggen, muss sich zusätzlich an den OWSTIMER.EXE-Prozess angehängt werden.
Wie man das via Macro und ShortCut im Visual Studio bewerkstelligt, habe ich hier bereits einmal beschrieben.

Für den OWSTIMER gilt das gleiche Vorgehen; das Macro, welches den Debugprozess an w3wp.exe anhängt, kann bequem kopiert und leicht abgeändert werden:


' This subroutine attaches to owstimer.exe:
Sub AttachToOWSTIMER()
Dim attached As Boolean = False
Dim proc As EnvDTE.Process

For Each proc In DTE.Debugger.LocalProcesses
If (Right(proc.Name, 12) = "OWSTIMER.EXE") Then
proc.Attach()
attached = True
End If
Next

If attached = False Then
MsgBox("Couldn't find OWSTIMER.EXE")
End If

End Sub


In meinem Falle habe ich dann als ShortCut STRG+SHIFT+4 gewählt (STRG+SHIFT+3 hängt sich an w3wp.exe an), sodass ich dann die relevanten ShortCuts beinander habe.

Freitag, 17. Juli 2009

Erweitertes Debuggen

Oft stößt der SharePoint-Entwickler während seiner Arbeit auf solche Ärgernisse wie SharePoint-Fehlermeldungen á la "Unknown error" z.B. beim Erstellen einer SiteCollection mittels einer Solution. Wenn man dann noch richtig Glück hat, stehen in SharePoint-Log und EventViewer keine weiteren Details dazu, die Hilfe, die SharePoint hier von Haus aus bietet, ist in diesem Falle wertlos.

Hier empfiehlt es sich, ein paar zusätzliche Einstellungen im Visual Studio vorzunehmen, was den Erfassungsradius von auftretenden Exceptions wesentlich vergrößert und eine Hilfe sein kann, die Ursachen für eine Fehlermeldung wie die obige zu finden.

Zuerst wird unter Tools->Options->Debugging die Option "Enable Just My Code (Managed only)" deaktiviert. Dies weist den Debugger an, über den Tellerand des eigenen Codes zu schauen und auch andere Exceptions zu erfassen:




Als nächstes muss die Option "Common Language Runtime Exceptions" unter Debug->Exceptions aktiviert werden damit der Prozess auch weiß, bei welcher Art von Exceptions die Verarbeitung zusätzlich angehalten werden soll.



Damit sind die nötigen Vorbereitungen abgeschlossen. Nun wird sich an den w3wp-Prozess angehängt (wie man dafür einen VS-ShortCut anlegt, beschreibe ich hier) und wenn nun eine Exception auftritt, hat man, wie auf dem folgenden Bild zu sehen, die Möglichkeit, zusätzliche Informationen zur aktuellen Situation abzufragen:




Wer noch tiefer in das Thema "verbesserte Debugging-Möglichkeiten" einsteigen möchte, dem empfehle ich diese Seite, die das obige Vorgehen ebenfalls erläutert und noch weiter in die Materie eindringt: http://blog.thekid.me.uk/archive/2007/07/25/debugging-tips-for-sharepoint-and-wss-exceptions.aspx