I am pleased to announce that the Metadata Search Web Part for SharePoint 2010 is now released! The Web Part allows users to do advanced search in SharePoint 2010 with very minimal configuration.

The Web Part has the following features:

• Search SharePoint lists – perform advanced searches on any SharePoint list or library using metadata
• Generate reports based on SharePoint list items – export to print-friendly pages or Word documents
• Adaptive styling – works with any SharePoint 2010 theme and styling
• Open-up SharePoint list items on the search result screen

You can download and try the product today!

When you are developing custom SharePoint web parts using SharePoint Object Model, it’s not enough that you can properly render contents in “Browse mode”.  Your web part must also take into account when the page it is attached to goes into “Edit mode”. In this blog post, I enumerate the different states the web part can be in in any given time. Sometimes, you would want to limit the functionality of the web part when it is not in “Browse mode”. And this is why you check what state the part is in before rendering contents for it.

You must also take into consideration the following use-cases that your web part will participate in:

• From the site’s Web Part Gallery, clicking the web part and rendering it in “Preview mode”.
• When editing the page that has the web part in SharePoint Designer 2010, that the web part renders properly as a user-control.

I want to focus on properly rendering the Web part in SharePoint Designer because this is a use-case that can be commonly missed. Today, I was testing a web part I am developing for Zenpo Software Innovations when I encountered the following error in SharePoint Designer 2010:

 

The web part’s OnLoad and OnInit event-handlers didn’t check that the page is in “design mode”. So, it tried to render its content as if it was in browse-mode.

The web part uses custom JavaScript. I have to register the scripts in order for the web part to use them. I implement the script-registration during the OnInit event of the web part like the following:

        protected override void OnInit(EventArgs e)
        {
                if (!Page.ClientScript.IsClientScriptIncludeRegistered("Script1"))
                {
                     scriptRegistered = false;
                     Page.ClientScript.RegisterClientScriptInclude("Script1",
                            Page.ClientScript.GetWebResourceUrl(this.GetType(),
                            "Zenposoft.Script1.js"));
                }
        }

This script registration code works fine on the web browser. The problem is when this code is invoked during SPD-editing of the web part page, Page.ClientScript.GetWebResourceUrl returns empty string (under normal browsing state, it would have returned the URL to the WebResource.axd file). And you cannot pass an empty string URL to the Page.ClientScript.RegisterClientScriptInclude method (it will throw an exception if you pass an empty URL). The web part really had no business trying to register scripts during design-time.

You might say to yourself, “this shouldn’t be an issue since Web part pages are edited through the browser anyway”. Think again! Web designers at your organization will use SharePoint Designer at some point to edit SharePoint pages and if your web part cannot handle “design mode” correctly, the designers will see the ugly “Error Creating Control” in SPD. You cannot instill confidence in the use of your web part if it’s throwing exceptions in SharePoint Designer!!!

So, how do we fix this? You can use the one of the following or both:

• SPContext.Current.IsDesignTime
• Control.DesignMode

I found this Microsoft SharePoint Designer Team Blog post that has nice explanation on how to create “designer friendly controls”. SPContext.Current.IsDesignTime and Control.DesignMode are mentioned in that blog post.

First, I modify the OnInit event-handler such that I register scripts only when “not in design mode”:

        protected override void OnInit(EventArgs e)
        {
            if (!this.DesignMode && !SPContext.Current.IsDesignTime)
            {
                if (!Page.ClientScript.IsClientScriptIncludeRegistered("Script1"))
                {
                    scriptRegistered = false;
                    Page.ClientScript.RegisterClientScriptInclude("Script1",
                            Page.ClientScript.GetWebResourceUrl(this.GetType(),
                            "Zenposoft.Script1.js"));
                }
            }
        }

After deploying the modified Web part, we check SharePoint Designer and the errors are gone:

Yes, the errors are gone but we need to display something where the web part(s) are embedded. If the web part in on the page, the designer should render something there; it can’t be just white-space.

In order to render something in “design mode”, we override the Render method of the web part:

        protected override void Render(HtmlTextWriter writer)
        {
            if (this.DesignMode || SPContext.Current.IsDesignTime)
            {
                writer.Write("<input type="button" value="Web part is in edit mode..." />");
            }
            else
            {
                base.Render(writer);
            }
        }

If the web part is in “design mode”, we render a simple HTML button. Otherwise, we let the base class (WebPart) handle the rendering. Deploy the updated web part and you should now see the following in SharePoint Designer:

To summarize, you will want to render web parts correctly in designers such as SPD 2010.  The likelihood that Web designers will edit SharePoint pages in SPD is high enough that you will want to “design mode” for your web part to run properly.

Back in SharePoint 2007, it was pretty popular to use the built-in Javascript function MSOTlPn_ShowToolPane2Wrapper to put the Web part page into edit mode and have the Web part properties editable. Typically, you would put something like the following in your Web part class code:

protected override void OnPreRender(EventArgs e)
{
   if (this.Page != null)
   {
      if (string.IsNullOrEmpty(SelectedListName))
      {
            placeHolderLiteral.Text = "
Web part is not configured. Please <a href="\&quot;javascript:MSOTlPn_ShowToolPane2Wrapper('Edit',">edit the Web part</a> and choose a list or library.

";
      }
   }
}

In the example above, I render a “please configure the Web part” message whenever the SelectedListName of the Web part is not set.

I’m currently developing a Web part for SharePoint 2010 and I wanted to have a “configure” link displayed for the Web part whenever Web properties (i.e. list name, view ID etc.) are not set or specified . I embed a code similar to the above snippet where I use MSOTlPn_ShowToolPane2Wrapper. It didn’t work!

So, thinking like a developer, I observe how the out-of-the-box Web parts render an “open tool pane” hyperlink. I add an Image Viewer web part to a web part page and look at the structure of the hyperlink. Here’s what I saw:

I replaced my output code in my web part class from MSOTlPn_ShowToolPane2Wrapper to ShowToolPane2Wrapper and it works!
Please note that I encourage that you put ‘this’ (object) as the second argument instead of ’129′, or ’16′ as you see in some blogs out there. The second parameter is supposed to indicate which Web part to edit. Do you really know at run-time that your Web part is ’129′ or ’16′? You don’t! So simply use ‘this’.