Sorry, we found 0 results. Please try another query.
Showing max 10 of results

The file is not checked out. You must first check out this document before making any changes.

If you ever got this message and don’t know where it came from, here is the solution.

I got it if I click on “Edit Page” on a publishing page. So after some investigation it seems to be a problem with the web parts on the page.

My page layout contains some EditModePanels, so the user have different views in display and edit mode of the page. Therefore we also have one web part in a web part zone which is in one of the EditModePanels for display only.

<PublishingWebControls:EditModePanel PageDisplayMode="Display">
  <WebPartZone ID="zone1" ...>
      the web part added through the onet.xml site definition

The same web part zone “zone1” does not exists for editing, because I do not want the user to edit the web part. There is another web part zone “zone2” which lives outside of any EditModePanel.

Now comes SharePoint.

If you check out the page and then click on “Edit Page”, everything is working. Except of, that the web part from zone 1 has moved to zone 2! Automatically! Thank you SharePoint…

It seems that SharePoint think it has to show the web part in edit mode. And because the original web part zone is not visible, SharePoint moves the web part to the next available zone which is visible also in edit mode.

So remember:

Never put a web part zone in an EditModePanel which is only visible in display mode.

Maybe the solution is to make the web part not editable, but I didn’t tested this. My fast workaround hack is to create a div instead of the EditModePanel and makes it “runat=server” and give it an ID. Then I wrote this code on top of the page:

<script runat="server">
protected override void OnLoad(EventArgs e)
{
    base.OnLoad(e);
    this.navleftdiv.Visible = (this.SPWebPartManager1.DisplayMode == WebPartManager.BrowseDisplayMode);
}
</script>

Now it works like a charm.

Publish a page with onet.xml as “published”

If you ever tried to publish one or more pages with your site definition (by onet.xml), you see in Visual Studio (with the SharePoint XSD schemas selected) only one valid value for the “Level” attribute which is “Draft”:

image

But for this attribute you can choose between every value of the SPFileLevel enum. So for publishing the page automatically, set the Level to “Published”. Thats it.

If you already know how to enable XSD schema validation and IntelliSense support stop reading here.

Enable Schema Validation:

  1. Open your xml file, e.g. onet.xml (works with all SharePoint related xml files)
  2. In the property pane, click the ellipsis next to the “Schemas” property
  3. Add the wss.xsd. This file is located in the 12\Template\XML directory
  4. Now add the following xml Namespace attribute to the root element (here Project in onet.xml):

Now you should have IntelliSense and schema validation enabled.

SharePoint Page Version History without Web Parts

Today I found a version history “bug” in SharePoint publishing pages:

The version history system of SharePoint covers only Page Fields, but not Web Parts.

In detail:

  • Create a new page (e.g. “Blank Web Part Page”) within a publishing web.
  • Now add text and a Web Part. Save changes and check-in.
  • Check out and change the text and some properties of the Web Part.
  • After that, check-in again, and open the “Version History”

If you now try to recover the first version, it seems to work, but only the page fields are recovered. The Web Part is always the latest version, because the Web Parts are saved in a totally different location, so they are not covered by the version history system.

Lets have a look on a cool solution:
Garry Lapointe created a web feature which replaces the version history system and saves a whole page with all Web Parts on every check-in through an Event Receiver on the Pages list.
The version is Alpha 0.0.1 but it is working very well, so download it from codeplex.

Telerik RadEditor for SharePoint: Problem with custom tools

The RadEditor for MOSS 2007 version 4.5.3.0 has a Bug, which is very annoying…

You create a new custom tool in the ToolsFile.xml and set the “showtext” property.

<tool name="CustomToolName" showtext="true" /> 

Then you create a corresponding javascript method in the RadEditorCommandList.

RadEditorCommandList["CustomToolName"] = function(commandName, editr, oTool)

{

  (...)

}

/images/
If you now click on this new Tool Button, the RadEditor shows the message “Could not find the command xxx. Please update your command list.”

radeditor_error

The solution for that: Remove the “showtext” property from your tool in the ToolsFile.xml and everything is working as expected.

.NET Framework 3.5 SP 1 und SQL Server 2008

Seit heute habe ich das Service Pack 1 für das .NET Framework 3.5 und den SQL Server 2008 auf meinem Server installiert. Ein paar neue kleine private Projekte warten und können nun mit den neuen Features ausgerüstet werden (z.B. Entity Framework und auch ASP.NET MVC obwohl das nur eine CTP ist).

An der Stelle kann ich das .NET 3.5 Enhancements Training Kit empfehlen! Sehr guter Überblick über alle Neuheiten.

Außerdem werde ich vielleicht die Datenbank von WoIstMarco? auf die neuen SQL Server 2008 Geo Datentypen upgraden. Mal schauen, was das so für Vorteile bringt.

Jetzt brauche ich nur noch viiel Zeit…