<script>
var reloadTimer = null;
var sURL = unescape(window.location.pathname);

function setReloadTime(secs)
{ if (arguments.length == 1)
   { if (reloadTimer) clearTimeout(reloadTimer);
       reloadTimer = setTimeout(“setReloadTime()”, Math.ceil(parseFloat(secs)*1000));
   }
   else
   { reloadTimer = null;
     location.reload(true);
     window.location.replace( sURL );
   }
}

setReloadTime(30);
</script>

Nach dem ich das Script mittels “Inhalts-Editor-Webpart” in die Seite eingebaut habe, wurde diese im 30 Sekunden Takt neu geladen. Das hat aber einen kleinen Nachteil, denn das Script läuft auch, wenn man im Seitenbearbeitungsmodus ist. Darum empfiehlt es sich, dass zuerst das Webpart ingebaut und konfiguriert wird und erst zum Schluss das Javascript in das Webpart eingefügt wird. Die vorgegebene Zeit von 30 Sekunden für den Reload sollte nicht unterschritten werden.

Im Blog “Path to SharePoint” findet sich der Artikel “Using calculated columns to write HTML”. In diesem Artikel wird die Funktionsweise und das Javascript erklärt. Wer das ganze lieber auf deutsch nachlesen will, sollte sich im Blog “MindBusines Blog” den Artikel “Formatierte Felder und Ampelfunktionen in SharePoint mit JavaScript” mal ansehen.

Und hier für alle Klickfaulen gleich direkt der Javascript-Code zu den Artikeln:

<script type="text/javascript">
//
// Text to HTML
// Feedback and questions: Christophe@PathToSharePoint.com
//
var theTDs = document.getElementsByTagName("TD");
var i=0;
var TDContent = " ";
while (i < theTDs.length) {
try {
TDContent = theTDs[i].innerText || theTDs[i].textContent;
if ((TDContent.indexOf("<DIV") == 0) && (TDContent.indexOf("</DIV>") >= 0)) {
theTDs[i].innerHTML = TDContent;
}
}
catch(err){}
i=i+1;
}
//
// ExpGroupRenderData overwrites the default SharePoint function
// This part is needed for collapsed groupings
//
function ExpGroupRenderData(htmlToRender, groupName, isLoaded) {
var tbody=document.getElementById("tbod"+groupName+"_");
var wrapDiv=document.createElement("DIV");
wrapDiv.innerHTML="<TABLE><TBODY id=\"tbod"+ groupName+"_\" isLoaded=\""+isLoaded+ "\">"+htmlToRender+"</TBODY></TABLE>";
var theTBODYTDs = wrapDiv.getElementsByTagName("TD"); var j=0; var TDContent = " ";
while (j < theTBODYTDs.length) {
try {
TDContent = theTBODYTDs[j].innerText || theTBODYTDs[j].textContent;
if ((TDContent.indexOf("<DIV") == 0) && (TDContent.indexOf("</DIV>") >= 0)) {
theTBODYTDs[j].innerHTML = TDContent;
}
}
catch(err){}
j=j+1;
}
tbody.parentNode.replaceChild(wrapDiv.firstChild.firstChild,tbody);
}
</script>

Danke an Christophe von “Path to SharePoint” für das tolle Script, aber Achtung; nur bei “Path to SharePoint” findet man immer die aktuellste Version des Script.

Genau dieser Fall ist bei mir aufgetreten. Selbst mit dem SharePoint-Designer konnte ich das Webpart nicht mehr löschen. Ich dachte schon, dass ich die Seite neu erstellen muss, aber dann habe ich folgenden genial einfachen Tipp bekommen.

Nr.	Bild	Beschreibung
1.		Die Seite mit dem defekten Webpart aufrufen und in der URL am Ende den Wert ?contents=1 eingeben.
2.		Die "Webpartseitenwartung" wird nun angezeigt. Hier werden alle Webparts der Seite aufgelistet.
3.		Nun das defekte Webpart markieren und anschliessend oben in der Navigation auf den Link "Löschen" klicken. Nun wird das Webpart aus der Seite gelöscht und die Seite kann wieder geöffnet werden.

]]> http://www.takeaphoto.ch/sharepoint/webparts-auf-seite-lschen/feed/ 0 http://www.takeaphoto.ch/sharepoint/fehlermeldung-bei-anpassen-eines-webparts/ http://www.takeaphoto.ch/sharepoint/fehlermeldung-bei-anpassen-eines-webparts/#comments Sun, 22 Nov 2009 07:13:49 +0000 bear64 http://www.takeaphoto.ch/?p=626 Wenn man versucht ein WebPart für eine Homepage anzupassen, kann es vorkommen, das stattdessen eine Fehlermeldung erscheint. Aus der Fehlermeldung geht aber nicht hervor, wo man das Problem zu suchen hat.

Als ich kürzlich mal wieder ein WebPart auf der Homepage unseres Projekts anpssen wollt, wurde stattdessen die nebenstehende Fehlermeldung angezeigt.

Das WebPart habe ich direkt über die Homepage aufgerufen.

Weil ich so nicht auf mein WebPart zugreifen konnte, wollte ich stattdessen via “Edit Page” zum WebPart gelangen, aber auch das ging nicht, da der Menüpunkt “Edit Page” ausgegraut war.

Nun würde man denken, dass an der Seite irgendetwas Faul ist. Dem ist aber nicht so. Die Seite ist lediglich von einem Benutzer ausgecheckt. Das kann man relativ einfach herausfinden, in dem man sich die “Page Editing Toolbar” via “Site Actions” anzeigen lässt.

In der Toolbar nun das Menü “Page” aufrufen.

Hier ist nun klar erkennbar, dass auch der “Check out”-Button ausgegraut ist und zusätzlich für Besitzer der Seite die Funktion “Override Check Out” zur Verfügung steht. Will man nun noch wissen, von wem die Seite ausgecheckt wurde, kann man via Toolbarmenü “Tools” den Page Status via “View Page Status” aufrufen.

In diesem Popup findet man den aktuellen Status der Seite und auch die Meldung, von wem die Seite ausgecheckt ist.

Nun hat sich die Navigation wie folgt geändert:

Infos zum Editieren im TechNet:

http://technet.microsoft.com/en-us/library/cc263080.aspx

In diesem Zusammenhang habe ich mich gefragt, weshalb SharePoint überhaupt diesen Eintrag im AD macht. Es scheint ja auch der einzige Eintrag zu sein, welche vom SharePoint in das AD geschrieben wird.

Im Internet bin ich fündig geworden. Die "My Site" kann direkt mit Office (2003 & 2007) interagieren. Dank der URL weiss Office, wo die MySite zu finden ist. Dadurch kann das Office automatisch in die MySite speichern. Da wir aber bei meinem Projekt die MySite so abspecken wollen, dass die Benutzer keine Dokumente in die MySite speichern können, sollte dieser Eintrag bei uns keinen Einfluss haben. Möglicherweise haben wir aber im Outlook nicht den gesamten Funktionsumfang zur Verfügung, was ich auf jeden Fall noch testen muss. Auf jeden Fall gibt’s auch dazu von Microsoft eine entsprechende Info:

http://office.microsoft.com/de-de/sharepointserver/HA101686391031.aspx

1. Systemsteuerung auf dem Server aufrufen
2. "Add or Remove Programs" aufrufen
3. In der Liste der installierten Programme den Eintrag mit dem "Microsoft Office SharePoint Server …" zu suchen und hier den Link "Click here for support" aufrufen.
4. Nun wird die Versionsnummer im Infofenster angezeigt.

Das ist schön und gut, aber wenn man auf dem Server keinen Zugriff hat oder wenn man die Versionen aller Server einer Serverfarm auslesen muss, ist das zu aufwendig. Meine Empfehlung ist da etwas einacher.

1. Die "Central Administration" aufrufen
2. Ins Register "Operations" wechseln
3. Hier gleich den 1. Link in der Liste "Servers in farm" aufrufen.

Nun wird die Version des Servers in der 1. Zeile angezeigt. In der Tabelle sieht man dann auch alle übrigen Server der Farm und deren Versionsnummer.

Welche Versionsnummern es für SharePoint gibt, kann man im Internet nachlesen. Leider habe ich keine entsprechende Seite bei Microsoft gefunden, aber im Blog "Penny Coventry, MVP" habe ich einen Eintrag mit allen Versionen gefunden.

Hier der Link dazu:

http://mindsharpblogs.com/penny/articles/481.aspx

Als ich die Betreuung von Livelink (einem sehr guten DMS) übernommen habe, musste ich erst einmal aufräumen. Viele Projekte waren verweist, niemand war zuständig und der Inhalt wurde nicht mehr verändert. Im SharePoint kann dies auch passieren, ausser man aktiviert die Funktion “Site Use Confimation and Deletion”. Wird eine Site Collection über eine längere Zeit nicht mehr verändert, wird automatisch eine E-Mail an den/die Verantwortlichen gesandt. Erhält man auf dieses E-Mail keine Antwort, wird die Site automatisch gelöscht.

Die Meldung ist etwas irreführend. Man hat so den Eindruck, dass unmittelbar nach dem Absturz von Word jemand das Dokument in Arbeit genommen hat. Dem ist aber nicht so. Effektiv ist das Dokument lokal im Cache. Manchmal genügt es dann, wenn jemand anderes das Dokument in Arbeit nimmt und abspeichert. Dabei können aber alle gemachten Änderungen verloren gehen. Es kann auch vorkommen dass auch dies und selbst ein Reboot des Arbeitsgeräts nichts hilft.

Mit einem kleinen Work a round kann man das Problem aber relativ einfach und ohne reboot umgehen. Dazu geht man wie folgt vor:

1. In Internet Explorer den Cache leeren
   
   
2. Nun mit dem Windows Explorer in folgendes Verzeichnis wechseln:
   C:\Documents and Settings\{Login}\Local Settings\Temporary Internet Files\Content.MSO\
3. Die Anzeige im Explorer so sortieren, dass die zuletzt bearbeiteten Dateien oben angezeigt werden. Anschliessend muss nun die gesperrte Datei gesucht werden (einfach auf die Datei mit Doppelklick öffnen. Ist die Datei korrekt, muss ohne zu speichern wieder geschlossen werden)
   
4. Die Datei nun aus dem Verzeichnis auf den Desktop verschieben.
5. Nun Versuchen Sie erneut die Datei im SharePoint zu öffnen.
   
6. Damit nun nicht die gesamte Arbeit verloren geht, kann man die zuvor auf den Desktop gespeicherte Datei öffnen, reparieren und anschliessend mit der Datei im SharePoint zusammenführen.