Rusty's SharePoint Blog

Xsl Transformation Credentials

2008-12-05T14:44:00.003-06:00

There is a frustrating deficiency in the XsltLoader class with regards to permissions. This is the class called by the XslCompiledTransform class that loads the xsl source file. The standard call would be as follows:

StringWriter stringWriter = new StringWriter();
HtmlTextWriter writer = new HtmlTextWriter(stringWriter);

XmlUrlResolver resolver = new XmlUrlResolver();
resolver.Credentials = CredentialCache.DefaultCredentials;

XslCompiledTransform transformer = new XslCompiledTransform();
transformer.Load(xslPath, XsltSettings.Default, resolver);
transformer.Transform(sourceXmlDoc, null, writer);

return stringWriter.ToString();

This works fine if you are under standard NT security/permission setups for SharePoint/MOSS 2007. However, if you do something like bring in Forms Based Authentication, you will get a strange xsl compile error.

The problem is that although the XsltLoader.Load method accepts an XmlUrlResolver object as a parameter, it does not actually use it when retrieving the xsl file. So, we cannot call the XslCompiledTransform.Load method by passing the xsl path as a string. Instead, we need to load the xsl into an XmlReader object manually and pass the reader to the Load method instead. This allows us to pass the credentials to the XmlReader and it will do the work of retrieving the xsl file. The finally result would be as follows:

StringWriter stringWriter = new StringWriter();
HtmlTextWriter writer = new HtmlTextWriter(stringWriter);

XmlUrlResolver resolver = new XmlUrlResolver();
resolver.Credentials = CredentialCache.DefaultCredentials;

XmlReaderSettings settings = new XmlReaderSettings();
settings.XmlResolver = resolver;
XmlReader reader = XmlReader.Create(xslPath, settings);

XslCompiledTransform transformer = new XslCompiledTransform();
transformer.Load(reader , XsltSettings.Default, resolver);
transformer.Transform(sourceXmlDoc, null, writer);
return stringWriter.ToString();

Filter Dropdown based on Audiences

2008-10-08T09:06:00.006-05:00

I found this presentation that gives a nice clean example of how to use the Sharepoint 2007 Audience functionality in code. So here is a quick model for creating a dropdown that is filtered based on the audience(s) set for each list item in an SPList.

private void CreateAudienceFilteredSelect(SPListItemCollection listItems)
{
// define this object at the class level so that it can access on the postback
newDropDown = new DropDownList();
AudienceLoader audienceLoader = AudienceLoader.GetAudienceLoader();

foreach (SPListItem listItem in listItems)
{
if (listItem ["Target Audiences"] != null)
{
string audienceValues = listItem ["Target Audiences"] .ToString();
if (AudienceManager.IsCurrentUserInAudienceOf(audienceLoader, audienceValues, false))
{
newDropDown.Items.Add(new ListItem(listItem["Title"].ToString(), listItem ["ID"].ToString()));
}
}
}
}

To dispose or not to dispose

2008-08-28T15:01:00.001-05:00

Helpful guide for determining when you should dispose your SPWeb and SPSite objects manually.

http://blogs.msdn.com/rogerla/archive/2008/02/12/sharepoint-2007-and-wss-3-0-dispose-patterns-by-example.aspx

Where in the world is the Microsoft.SharePoint.ApplicationPages.dll located?

2008-08-26T10:12:00.002-05:00

SharePoint 2007 location for the Microsoft.SharePoint.ApplicationPages.dll:

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\CONFIG\BIN

Custom Web Part Properties (ToolParts)

2008-08-21T08:59:00.001-05:00

SharePoint 2007 Web Parts have a nice built in property management. As long as your properties are straight forward strings, booleans, etc. However, if you need a more complicated property such as a list or a radio group, you will need to create a custom property. These are called Tool Parts.

The ToolPart base class is laid out similarly to the WebPart base class. In essence, you will create your custom controls in the CreateChildControls method.

This example will do a little more than just create the controls though. Here we will style the Tool Part so it looks just like the standard SharePoint properties as well. For the record, I totally stole the formatting stuff from Liam Cleary.

First off, create a new class that inherits from Microsoft.SharePoint.WebPartPages.ToolPart.

public class SampleToolPart : ToolPart
{
    // First, override the CreateChildControls method. This is where we create the controls.
    protected override void CreateChildControls()
    {
        // create a panel that will hold all of our controls
        Panel toolPartPanel = new Panel();
        toolPartPanel.CssClass = "ms-ToolPartSpacing";

        // create a table that will put our controls in rows
        Table toolPartTable = new Table();
        toolPartPanel.Controls.Add(toolPartTable);
        toolPartTable.CellPadding = 0;
        toolPartTable.CellSpacing = 0;
        toolPartTable.Style["border-collapse"] = "collapse";
        toolPartTable.Attributes.Add("width", "100%");

        // create the first row that will contain a control
        TableRow firstRow = new TableRow();
        toolPartTable.Rows.Add(firstRow);
        TableCell firstRowCell = new TableCell();
        firstRow.Cells.Add(firstRowCell);

        // add formatting to the cells
        firstRowCell.Controls.Add(new LiteralControl("<div class='UserSectionHead'>Sample Dropdown:</div>"));
        firstRowCell.Controls.Add(new LiteralControl("<div class='UserSectionBody'><div class='UserControlGroup'><nobr>"));

        // create the actual control
        DropDownList sampleDropDown1 = new DropDownList();
        sampleDropDown1.ID = "sampleDropDown1";
        sampleDropDown1.Items.Add("Item 1");
        sampleDropDown1.Items.Add("Item 2");
        sampleDropDown1.Items.Add("Item 3");

        // add the new control to the table
        firstRowCell.Controls.Add(sampleDropDown1);

        // add formatting closing tags to the cell
        firstRowCell.Controls.Add(new LiteralControl("</nobr></div></div>"));

        // create a standard dotted line seperator
        TableRow seperatorRow = new TableRow();
        toolPartTable.Rows.Add(seperatorRow);
        TableCell seperatorCell = new TableCell();
        firstRow.Cells.Add(seperatorCell);
        seperatorCell.Controls.Add(new LiteralControl("<div style='width:100%' class='UserDottedLine' />"));

        // lather, rinse, repeat for all the controls you need

        // finally add the panel to the controls collection of the tool part
        Controls.Add(toolPartPanel);
        base.CreateChildControls();
    }

    // Next, override the ApplyChanges method.
    // This method is where we will persist the values that the user selects.
    public override void ApplyChanges()
    {
        // get the parent webpart
        SampleWebPart parentWebPart = (SampleWebPart)this.ParentToolPane.SelectedWebPart;

        // loop thru this control's controls until we find the ones that we need to persist.
        RetrievePropertyValues(this.Controls, parentWebPart);
    }

    // Recursive function that tries to locate the values set in the toolpart
    private void RetrievePropertyValues(ControlCollection controls, SampleWebPart parentWebPart)
    {
        foreach (Control ctl in controls)
        {
            RetrievePropertyValue(ctl, parentWebPart);

            if (ctl.HasControls())
            {
                RetrievePropertyValues(ctl.Controls, parentWebPart);
            }
        }
    }

    // Method for retrieving the values set by the user.
    private void RetrievePropertyValue(Control ctl, SampleWebPart parentWebPart)
    {
        if (ctl is DropDownList)
        {
            if (ctl.ID.Equals("sampleDropDown1"))
            {
                DropDownList drp = (DropDownList)ctl;
                if (drp.SelectedItem.Value != "")
                {
                    parentWebPart.Property1 = drp.SelectedItem.Value;
                }
            }
        }
    }
}

Now, we need to wire up the tool part to the web part. To do this, we override the GetToolParts() method and place our new tool part in the ToolPart array.

public class SampleWebPart : Microsoft.SharePoint.WebPartPages.WebPart
{
    public SampleWebPart()
    {
        this.ExportMode = WebPartExportMode.All;
    }

    // property that will be set thru our custom tool part
    // make sure to set the WebBrowsable attribute to false
    // so it will not show up outside of our custom tool part
    [Personalizable(PersonalizationScope.Shared)]
    [WebBrowsable(false)]
    [System.ComponentModel.Category("My Group")]
    [WebDisplayName("Property1")]
    public string Property1
    {
        get
        {
            return _property1;
        }
        set
        {
            _property1 = value;
        }
    }
    private string _property1 = "Default Value";

    public override ToolPart[] GetToolParts()
    {
        // resize the tool part array
        ToolPart[] toolparts = new ToolPart[3];
        // instantiate the standard SharePopint tool part
        WebPartToolPart wptp = new WebPartToolPart();
        // instantiate the custom property toolpart if needed.
        // this object is what renders our regular properties.
        CustomPropertyToolPart custom = new CustomPropertyToolPart();
        // instantiate and add our tool part to the array.
        // tool parts will render in the order they are added to this array.
        toolparts[0] = new SampleToolPart();
        toolparts[1] = custom;
        toolparts[2] = wptp;
        return toolparts;
    }
}

Setting Master Page For An Individual Page

2008-07-21T09:21:00.003-05:00

Settings the master page for a SharePoint 2007 publishing website can be done out of the box using the UI or programmatically. For guidance on how to set the MasterPage programmatically, Mike Hodnick has a good post.

However, if you want to set the Master Page for an individual page or pages within a website, things get tricky.

The @Page directive exposes the MasterPageFile property, but the value is immediately overwritten in the Pre-Init event of the publishing pages base class (PublishingLayoutPage).

To resolve this, we will have to set the MasterPageFile through code. Andrew Connell provides a nice tutorial on how to create a code-behind class for a layout page.

Once you have created the code-behind class, override the OnPreInit event method and set the MasterPageFile property immediately after the base.OnPreInit(e) call.

protected override void OnPreInit(EventArgs e)
{
     base.OnPreInit(e);
     // override the MasterPageFile which is set in the Pre-Init with our own.
     MasterPageFile = "mymaster.master";
}

Content Type is still in use error

2008-07-18T10:47:00.002-05:00

I spent an hour trying to delete a content type through the SharePoint 2007 UI with no success. I kept getting an "Content Type is still in use" exception even though I had deleted all layout pages that used that content type. I even went as far as de-activating the feature that installs the layout pages in the first place.

Finally I figured out that I have to remove the content type from any document library that contained any of the layout pages attached to the offending content type.

In my case, I had a publishing web site. So I clicked on "View All Site Content" and selected the Pages document library. From there, I went to the Settings page and, under the Content Types section, clicked on the content type I wanted to remove and deleted it.

Programmatically Creating a List from a ListTemplate

2008-07-16T12:47:00.002-05:00

Adding a list to a website in SharePoint 2007 from a ListTemplate is fairly straightforward. But there is one quirk that you need to be aware of.

The templates are located in SPWeb.ListTemplates. The indexer for the ListTemplateCollection has two overloads. The first one uses the index value of the ListTemplate. Since you will probably not know that value, the second overload comes into play. This one uses the "Name" of the ListTemplate.

Here's the catch. What Microsoft really means by "Name" is "Display Name". This seems like more than just bad naming conventions, but bad practice as well. As the "Name" of the ListTemplate should be the key.

Namespaces matter

2008-07-07T10:06:00.004-05:00

Thanks to Paul's post, I realized that SharePoint 2007 pays closer attention to namespaces than I realized. Your feature and it's feature receiver must have the same root namespace or the solution will not deploy.

I am still not sure what the difference is, because I could deploy to my local environment using WSPBuilder without issue. But when I tried to deploy to our test environment using the standard stsadm commands it failed with the following exception:

"Failed to create feature receiver object from assembly 'MyAssemblyInfo'... : System.ArgumentNullException: Value cannot be null."

Create an Anonymous Access Survey Programmatically

2008-07-03T22:26:00.001-05:00

Their are several good examples on how to use the UI to make a SharePoint 2007 survey work for anonymous users. So I took what I learned from them and came up with this method for doing the same thing programmatically.

The main catch was the AnonymousPermMask64 flags. The only ones that you see in the UI are the AddListItems and ViewListItems. But there are several others that are set behind the scenes.

private void AddNewSurvey(SPWeb web, SPListTemplate surveyTemplate)

    web.Lists.Add("Survey Title", "Survey Description", surveyTemplate);

    // once we have created the survey, find it again so we can set the permissions

    SPList surveyList = web.Lists["Survey Title"];

    web.AllowUnsafeUpdates = true;

    // break the role inheritance so we can set our own permissons

    if (!surveyList.HasUniqueRoleAssignments)

        surveyList.BreakRoleInheritance(true);

    surveyList.ReadSecurity = 2; // can read their own

    surveyList.WriteSecurity = 2; // can edit their own

    // set the permission flags for Add and View plus some internal flags

    surveyList.AnonymousPermMask64 =

        (SPBasePermissions.Open |

        SPBasePermissions.OpenItems |

        SPBasePermissions.ViewFormPages |

        SPBasePermissions.UseClientIntegration |

        //SPBasePermissions.UseRemoteAPIs |

        SPBasePermissions.ViewListItems |

        SPBasePermissions.AddListItems);

    surveyList.Update();

Adding Web Part to Page Layout

2008-06-27T21:03:00.001-05:00

It seems the standard method for adding a SharePoint 2007 Web Part to a page layout is by using the <AllUsersWebPart> tag in the <Module> tag of the page layout feature. However when I tried this method, I would receive an "No parameterless constructor defined for this object" exception that I could not resolve. So I came up with a different way of doing it that I actually like better. I can go directly to the page layout aspx file and add the Web Part there.

First, I need to register the Web Part assembly just as if I were adding a custom control to a standard asp.net page.

<%@ Register tagprefix="MyTag" namespace="My.NameSpace" assembly="My.Assembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f300fd2d8ae223d7" %>

Then, I can declare the Web Part control in the Web Part Zone of my choosing.

<WebPartPages:WebPartZone PartChromeType="None" ID="Zone1" runat="server" Title="Zone1">

        <ZoneTemplate>

                <MyTag:MyWebPart runat="server" PartOrder="1" ></MyTag:MyWebPart>

        </ZoneTemplate>

</WebPartPages:WebPartZone>

What's nice about this approach is that if I want to remove this Web part or add another, I can simple copy the aspx file to the proper 12 hive location and its ready to go. Instead of having to uninstall and re-install the feature.

Running with Elevated Privileges

2008-06-27T15:27:00.003-05:00

SharePoint 2007 offers a nice and easy way for elevating your permissions using delegates.

The main catch is to remember that you cannot use any of the Context objects such as SPContext to directly retrieve your objects. But this can be easily overcome by using the ID attribute of the Site object in the Context to retrieve a copy of the site.

 
        protected void MyMethod()
        {
            SPSecurity.CodeToRunElevated elevatedMethod = new SPSecurity.CodeToRunElevated(MyElevatedMethod);
            SPSecurity.RunWithElevatedPrivileges(elevatedMethod);
        }
 
        private void MyElevatedMethod()
        {
            // do not use the Context object directly since it uses the logged in credentials
            // instead create a new object using the site id retrieved from the Context
            using (SPSite site = new SPSite(SPContext.Current.Site.ID))
            {
                // do your stuff here
            }
        }

Modifying the SharePoint Web.config

2008-06-20T17:29:00.001-05:00

Modifying the web.config file for SharePoint 2007 is more complicated than a typical ASP.NET web application. Although modifying the file by hand does work, if your production environment is a large farm, or if you need your solution to be easily re-deployable, manual modification is not the answer. So SharePoint provides us with an SPWebConfigModification object to handle changes.

My example deals with adding appSetting keys. Typically, these keys should be added when your feature is installed or activated. I chose the FeatureActivated event for this example.

public override void FeatureActivated(SPFeatureReceiverProperties properties)

    using (SPSite site = properties.Feature.Parent as SPSite)

        SPWebApplication webApp = site.WebApplication;

        SPWebConfigModification configMod = new SPWebConfigModification();

        configMod.Name = "add[@key='" + key + "']";

        configMod.Path = @"configuration/appSettings";

        configMod.Value = @"<add key=""MyKeyName"" value=""MyValue"" />";

        // you can put whatever you want for the owner, but using the feature id is a good standard

        configMod.Owner = properties.Feature.DefinitionId.ToString();

        configMod.Sequence = 0;

        configMod.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;

        if (webApp.WebConfigModifications.Contains(configMod))

            webApp.WebConfigModifications.Remove(configMod);

        webApp.WebConfigModifications.Add(configMod);

        // I have seen several examples that only call ApplyWebConfigModifications

        // or that make the Update call after calling ApplyWebConfigModifications.

        // But the only way it works for me is to call Update first.

        webApp.Update();

        webApp.WebService.ApplyWebConfigModifications();

The ApplyWebConfigModifications works through a timer job, so there may be a slight delay in the update.

I stole this removal routine from Vincent Rothwell. I like it because it keys off the owner and since I use the feature id as the owner, it knows exactly which entries to remove. It also helps to clean up any goofs I may have made in the file earlier.

public override void FeatureDeactivating(SPFeatureReceiverProperties properties)

    using (SPSite site = properties.Feature.Parent as SPSite)

        RemoveAppSettingsByOwner(site, properties.Feature.DefinitionId.ToString());

public static void RemoveAppSettingsByOwner(SPSite site, string owner)

    SPWebApplication webApp = site.WebApplication;

    Collection<SPWebConfigModification> modifications = webApp.WebConfigModifications;

    int modCount = modifications.Count;

    for (int c = modCount - 1; c >= 0; c--)

        SPWebConfigModification modification = modifications[c];

        if (modification.Owner == owner)

            modifications.Remove(modification);

    if (modCount > modifications.Count)

        webApp.Update();

        webApp.WebService.ApplyWebConfigModifications();

Programmatically Create Workspace Linked to an Event (LinkWithEvent)

2008-06-19T13:08:00.006-05:00

In my SharePoint 2007 project, I created a workspace template that I wanted the customers to always use when they created their meeting workspace. So I needed to bypass the standard site creation page and programmatically add the sub site with the desired template.

Step 1 was to create my own custom list template based on the Calendar list. I need to do this so I could hide the Workspace column from the user. But more importantly, so I could add an event receiver that would do the work of creating the workspace site.

Step 2 was to create the event receiver for the ItemAdded event via a feature.

The feature.xml file is standard. Being sure to set the scope to "Web" as receivers cannot be scoped at the Site Collection level.

<?xml version="1.0" encoding="utf-8"?>

<Feature  Id="YOURGUIDHERE"

          Title="CalendarEventListEventReceiver"

          Description="Description for CalendarEventListEventReceiver"

          Version="12.0.0.0"

          Hidden="FALSE"

          Scope="Web"

          DefaultResourceFile="core"

          xmlns="http://schemas.microsoft.com/sharepoint/">

  <ElementManifests>

    <ElementManifest Location="elements.xml"/>

  </ElementManifests>

</Feature>

For the elements.xml ensure that the ListTemplateId attribute references the type of your list template.

<?xml version="1.0" encoding="utf-8" ?>

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">

  <Receivers ListTemplateId="10002">

    <Receiver>

      <Name>ItemAdded</Name>

      <Type>ItemAdded</Type>

      <SequenceNumber>10000</SequenceNumber>

      <Assembly>Events.Web, Version=1.0.0.0, Culture=neutral, PublicKeyToken=747f099a9bd1475c</Assembly>

      <Class>Events.Web.EventListEventReceiver</Class>

      <Data></Data>

      <Filter></Filter>

    </Receiver>

  </Receivers>

</Elements>

Now create the receiver and override the ItemAdded method. Remember that the ItemAdded event is an asynchronous event, so you might not see your new site right away.

using System;

using System.Collections.Generic;

using System.Text;

using Microsoft.SharePoint;

using Microsoft.SharePoint.Meetings;

namespace MyNamespace

    public class EventListEventReceiver : SPItemEventReceiver

        public override void ItemAdded(SPItemEventProperties properties)

            CreateWorkSpace(properties);

            base.ItemAdded(properties);

        private void CreateWorkSpace(SPItemEventProperties properties)

            using (SPWeb web = properties.OpenWeb())

try

                    //find the parent site

                    using (SPSite site = web.Site)

                    // get a list of the custom templates so we can find our event template

                SPWebTemplateCollection templates = site.GetCustomWebTemplates(1033);

                       SPWebTemplate template = templates["EventWorkspaceTemplate.stp"];

                       // create the new web site

                       SPWeb newWeb = web.Webs.Add(properties.ListItemId.ToString(), properties.ListItem["Title"].ToString(), properties.ListItem["Location"].ToString(), 1033, template, false, false);

                       // cast the web as a meeting so we can link it back to the event item

                       SPMeeting meeting = SPMeeting.GetMeetingInformation(newWeb);

                       meeting.LinkWithEvent(web, properties.ListId.ToString(), properties.ListItemId, "WorkspaceLink", "Workspace");

                catch (Exception ex)

                    properties.Cancel = true;

                    properties.ErrorMessage = ex.Message;

After installing the feature, be sure it is activated in the web site that your custom list exists.

CustomAction token bug

2008-06-14T17:39:00.002-05:00

Sheetal Jain again comes to my rescue by providing a very quick and easy workaround to an apparent SharePoint 2007 bug regarding tokens in custom actions. If you use the {ListId} token, it works fine if you are viewing the actual list. But if you view the list through a WebPart, it does not work. I found some other posts that came up with workarounds that were quite complicated. So I was very excited to find his solution.

To sum up, MOSS adds a context object (ctx) to the javascript side of each page. The object has a property called ListName which is actually the Guid for the list. So instead of using {ListId}, just concatenate "+ctx.ListName" to your url instead.

Update: This does NOT work if you are in a meeting workspace. I'll try to post my workaround later.

Adding a Checkbox to SPGridView in SharePoint 2007

2008-06-12T13:32:00.002-05:00

This example creates a very simple grid that as a checkbox on each row. Allowing you to select multiple rows at a time.

Note: You can do it in Html for simple controls, but if you need to add features such as grouping, you will probably have to build your grid programmatically. (see Oscar Medina's post for tips on how to do that)

1. Register the SharePoint web controls on the aspx page

<%@ Register TagPrefix="SharePoint"

    Namespace="Microsoft.SharePoint.WebControls"

    Assembly="Microsoft.SharePoint,

    Version=11.0.0.0,

    Culture=neutral,

    PublicKeyToken=71e9bce111e9429c" %>

2. Declare your SPGridView control in the Html with the first column being a TemplateField control holding your checkbox. You can also add a hidden field to hold the ID of the ListItem.

<SharePoint:SPGridView id="grid" allowsorting="true" autogeneratecolumns="false" runat="server">

    <Columns>

        <asp:TemplateField headertext="Select">

            <ItemTemplate>

                <input id="select" type="checkbox" runat="server" />

                <input id="itemID" type="hidden" runat="server" />

            </ItemTemplate>

        </asp:TemplateField>

    </Columns>

</SharePoint:SPGridView>

3. If you know the data columns, you can declare them here too. Or you can build them dynamically at step 5 (see my previous post)

4. In your code-behind page, add a reference to your grid

public class MycodeBehind : System.Web.UI.Page

    protected SPGridView grid;

5. Create a method to build the data fields dynamically (see my previous post)

6. Wire up an event handler for the RowDataBound event.

grid.RowDataBound += new GridViewRowEventHandler(grid_RowDataBound);

7. Create your Event Handler method. This method will set the itemID field value to the ID of the ListItem. You can use this field on the post back to identify the ListItem.

private void grid_RowDataBound(object sender, GridViewRowEventArgs e){     if (e.Row.RowType == DataControlRowType.DataRow)    {        HtmlInputHidden itemID = (HtmlInputHidden)e.Row.FindControl("itemID");        if (itemID != null)        {            DataRowView data = (DataRowView)e.Row.DataItem;            itemID.Value = data["ID"].ToString();        }    }}

8. Add this code to the post back event (OnClick most likely). This will loop through your grid and find all the rows that are checked. Once you have a checked row, you can use the itemID value to quickly find the corresponding ListItem.

 for (int i = 0; i < grid.Rows.Count; i++){     HtmlInputCheckBox selectCtl = (HtmlInputCheckBox)grid.Rows[i].FindControl("select");    HtmlInputHidden itemIDCtl = (HtmlInputHidden)grid.Rows[i].FindControl("itemID");        if (selectCtl.Checked && itemIDCtl.Value != "")    {         // find the row so we can retrieve the values         SPListItem myListItem = myList.Items.GetItemById(Convert.ToInt32(itemIDCtl.Value));                // do whatever you need to do            } }

SharePoint 2007: Custom Action That Opens A Popup Window

2008-06-11T15:22:00.003-05:00

Sheetal Jain points out something that no one else seems to mention when trying to create a custom action that pops up a new window in SharePoint 2007.

The standard method that all the samples show looks something like this:

<UrlAction Url="javascript:window.open('/_layouts/someForm.aspx')" />

However, this does not work. The new form does indeed popup, but the original window will then display just "[Object]". The solution is to add the keyword "void" in front of the window.open call:

Updated: fixed typos mentioned in comments

Build SPGridView Columns Dynamically From A View(SPView)

2008-06-10T08:50:00.003-05:00

Since the SharePoint 2007 SPGridView controls do not support autogeneration of columns, they typically have to be manually constructed by looping through the datasource and building a column for each field. This is straightforward enough if the datasource is an SPList. For an SPList, you can simple iterate through the Fields collection and add BoundField objects to the grid using the Title and InternalName properties for the HeaderText and DataField respectively.

In the case of an SPView, this is not so straightforward. The challenge is that the view object does not contain the display names of the fields it represents.

So here is how I have worked it out. The SPView object does have a ViewFields property which gives us a collection of the internal names for the fields. So we can use this collection to point to the fields in the parent list to find the other attributes such as the display name (or Title).

private void BuildColumns(SPView myView, SPGridView grid)

    SPViewFieldCollection viewFields = myView.ViewFields;

    for (int i = 0; i < viewFields.Count; i++)

        foreach (SPField field in myView.ParentList.Fields)

            if (field.InternalName == viewFields[i])

                if (!field.Hidden)

                    BoundField col = new BoundField();

                    col.HeaderText = field.Title;

                    col.DataField = field.InternalName;

                    grid.Columns.Add(col);

                break;

Bind SPList to DataGrid

2008-06-09T12:55:00.002-05:00

Simple enough, but I thought it would be good to document how to bind an SharePoint 2007 SPList object to an ASP.NET 2.0 DataGrid control.

SPList customerList = currentweb.Lists["Customers"];

DataGrid dg = new DataGrid();

dg.DataSource = customerList.Items.GetDataTable();

How To Set Url Field Value

2008-06-09T08:47:00.001-05:00

The standard way of setting a field value for an SPListItem in SharePoint 2007 falls a little short for Url fields. Url fields actually have two parts, the url itself and the text to display. The SharePoint 207 object model provides an SPFieldUrlValue object that resolves this issue.

SPFieldUrlValue redirectUrl = new SPFieldUrlValue();
redirectUrl.Url = "www.microsoft.com";
redirectUrl.Description = "Click here!";
data.ListItem["Redirect URL"] = redirectUrl;
data.Update();

A Nice Little Trick For Your Local web.config

2008-06-07T14:39:00.002-05:00

Here is a easy way to include the web.config file from your MOSS site into your Visual Studio feature project.

I learned this a while back but never really had a use for it until now. For me, this makes it easier to access the config file to add AppSetting keys and what not.

Right-click on your feature project file and select Add Existing Item.
Navigate to your website folder (Typically C:\Inetpub\wwwroot\wss\VirtualDirectories\80)
Select the web.config file.
Before clicking "Add", click on the arrow at the right of the button and select "Add as Link"

This method creates a link to the web.config and not a copy. So any changes you make will be made in the actual config file of the server.

Remember that this is only for fiddling around in your development environment. When its time to actually make permanent changes, use SPWebConfigModification so that changes are propagated throughout your farm (see this post by Mark Wagner).

Creating Lookup Columns Using Features in SharePoint 2007

2008-06-04T15:12:00.013-05:00

Chris O'Brien does an excellent job of explaining the difficulties in creating custom lists that contain Lookup columns. His solution, although more flexible since it relies on defining the column in CAML, leaves me a little uneasy since it relies on reading a file to retrieve the xml. I tend to want my deployment packages to be as simple as possible so there is little chance that the deployment team will run into complications.

So I created a hybrid between his approach and Waldek Mastykarz's walk-thru for programmatically provisioning lookup fields

There are three elements that are needed for this functionality

The existing source list that is the base of the lookup column.
A custom site column pointing to the source list (this is what we are creating).
A list that needs the lookup site column (this can be added later at you leisure)

First, the feature.xml: (Notice that no ElementManifest node exists)

<?xml version="1.0" encoding="utf-8"?><Feature Id="YOURGUIDGOESHERE"        Title="LookupColumnFeature"        Description="Description for LookupColumnFeature"        Version="12.0.0.0"        Hidden="FALSE"        Scope="Site"        DefaultResourceFile="core"        ReceiverAssembly="LookupColumnFeatureAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=614c3beb89d35e6b"        ReceiverClass="LookupColumnFeatureAssembly.LookupColumnFeature"        xmlns="http://schemas.microsoft.com/sharepoint/">  <ElementManifests>  </ElementManifests></Feature> 

Second, I created a feature receiver with the same name as referenced in the ReceiverClass node of the feature.

The first step in the FeatureActivated method is to find the subweb in which I want to add the column (If your column will be in the root site then this step is not needed).
Next, create a field object using the Sharepoint Object Model (see method CreateLookupColumn).
Finally, added logic in the FeatureDeactivating method to delete the site column as cleanup.

using System;using System.Collections.Generic;using System.Text;using Microsoft.SharePoint;using System.Configuration; namespace LookupColumnFeatureAssembly{    class LookupColumnFeature : SPFeatureReceiver    {         public override void FeatureActivated(SPFeatureReceiverProperties properties)        {            // feature is scoped at Site, so the parent is type SPSite rather than SPWeb            using (SPSite site = properties.Feature.Parent as SPSite)            {                SPWeb currentWeb = FindCurrentWeb(properties);                using (currentWeb)                {                    // find the subweb to add the column                    SPWeb mySubWeb = currentWeb.Webs["SubWebUrl"];                    // find the source list                    SPList sourceList = mySubWeb.Lists["SourceListName"];                     // build the lookup column                    CreateLookupColumn("MyLookupColumnName", "My Custom Group", false, false, mySubWeb, sourceList, "ColumnName");                 }            }        }         public override void FeatureDeactivating(SPFeatureReceiverProperties properties)        {            // feature is scoped at Site, so the parent is type SPSite rather than SPWeb            using (SPSite site = properties.Feature.Parent as SPSite)            {                SPWeb currentWeb = FindCurrentWeb(properties);                using (currentWeb)                {                    SPFieldLookup lookupColumn = null;                     // find the subweb to add the column                    SPWeb mySubWeb = currentWeb.Webs["SubWebUrl"];                     // we don't care if there was an exception retrieving the field from the collection,                    // since if it's not there we can't delete it anyway..                    try                    {                        lookupColumn = mySubWeb.Fields["MyLookupColumnName"] as PFieldLookup;                    }                    catch (ArgumentException argExc)                    {                     }                     if (lookupColumn != null)                    {                        try                        {                            lookupColumn.Delete();                        }                        catch (SPException SpExc)                        {                            throw;                        }                    }                 }            }         }         public override void FeatureInstalled(SPFeatureReceiverProperties properties)        {        }         public override void FeatureUninstalling(SPFeatureReceiverProperties properties)        {        }         private SPFieldLookup CreateLookupColumn(string fieldName, string group, bool required,        bool allowMultipleValues, SPWeb thisWeb, SPList sourceList, string lookupField)        {            thisWeb.Fields.AddLookup(fieldName, sourceList.ID, sourceList.ParentWeb.ID, required);            SPFieldLookup lookup = thisWeb.Fields[fieldName] as SPFieldLookup;            lookup.AllowMultipleValues = allowMultipleValues;            lookup.LookupField = lookupField;            lookup.Group = group;            lookup.Update(true);             return lookup;        }          private SPWeb FindCurrentWeb(SPFeatureReceiverProperties properties)        {            SPSite site = properties.Feature.Parent as SPSite;            SPWeb currentWeb = null;            Guid rootWebId = Guid.Empty;            if (site != null)            {                currentWeb = site.RootWeb;                rootWebId = currentWeb.ID;            }            else            {                currentWeb = properties.Feature.Parent as SPWeb;                rootWebId = currentWeb.Site.RootWeb.ID;            }             return currentWeb;         }    }}

p.s. Josh Gaffey has a method that uses only CAML but only seems to work if the list is scoped at the root level. However, I could not duplicate it at all. And several other bloggers were unable to duplicate it as well.

Custom Actions for Specific Lists in SharePoint 2007

2008-06-04T15:08:00.006-05:00

Most of the posts I have seen regarding custom actions have been too simple for practical use. They will walk you thru the process of creating a "CustomAction" feature, but that action will then show up on all of your lists (example here).

This post was the first I found that points you in the right direction for creating custom actions that will only show up for the specific list(s) you want the action to be performed on.

The main catch is that you will need a custom List type with a unique type number and you can then hook the custom action to this list type via the RegistrationId.

Content Type IDs

2008-06-03T14:52:00.000-05:00

When the time comes for you to make a custom content type using features, this link explains how to create a proper ID.