
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:
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”:
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.
Leave a Reply