RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Wrapping Web Controls in a SharePoint Web Part

With so many useful ASP.NET Web controls available, you should be able to use them in SharePoint, right? Well, you can. This article presents two ways to wrap existing Web controls in a SharePoint Web Part.

ost of the time, creating a Web Part in SharePoint isn't about creating a totally new user interface; instead, the task usually involves connecting existing controls with SharePoint data or with SharePoint's toolparts so you can configure them. For example, you may want to connect a simple data grid with a SQL data source. Most of the visual interface isn't Web Part visual interface code—it comes directly from the data grid Web control. The Web Part connects the Web control with the configuration data that the user provided.

In this article, you'll see two basic ways of wrapping an existing Web control in a SharePoint Web Part and explore the strengths and weaknesses of each one. First, I'll show you the Render method, and then discuss adding the control to the control tree.

Using the Render Method
Perhaps the easiest and most straightforward method for managing an underlying Web control is to do it directly—first create the control and set its properties, and then make one quick call to the RenderControl() method to get the rendered HTML for the control, and another to add that HTML to the page output. That sequence, called the Render method, lets you obtain the output generated by a Web control quickly and painlessly.

The benefit is that it's fast and easy to trap errors, so it's possible to detect and resolve errors relatively easily within the context of SharePoint. A quick try/catch block around the code can capture and display any errors that occur during the process.

The result is a snapshot of the control as it would render itself with no outside information. The control doesn't have the benefit of knowing what kind of browser it was rendering for, and it doesn't have the ability to set up event handlers. It's just a straight HTML copy of what the control would do if you inserted it directly into the page.

One of the challenges of the Render method is that it circumvents the normal sequence of events fired for a control connected to the page—in other words, the events do not fire when you render a control through its RenderControl method. This has the nasty habit of causing third party Web controls to crash when you attempt to use them with the Render method.

The essence of the Render method is overriding the RenderWebPart method in a WebPart-derived class. Within the method, you create the underlying Web control, set the appropriate properties, and then call the RenderControl method. The following code (you can download the code) shows how.

   protected override void RenderWebPart(
      HtmlTextWriter output)
         System.Data.SqlClient.SqlConnection mySQLConnect = 
            new SqlConnection(connectionString);
          SqlCommand myCmd = new SqlCommand(
             sqlString, mySQLConnect);
          System.Data.SqlClient.SqlDataAdapter myAdapter = 
             new SqlDataAdapter(myCmd);
          DataSet ds = new DataSet();
          myAdapter.Fill(ds, "Data");
          DataGrid dg = new DataGrid();
          dg.DataSource = ds.Tables[0];
      catch (Exception excpt)

The crux of this example occurs in the last line of the try block when the code calls the RenderControl method of the DataGrid class in the line dg.RenderControl(output), passing the same HtmlTextWriter named output that the RenderWebPart method receives as an argument. This call adds the rendered version of the control to the output stream. The rest of the code sets up the DataGrid with the results of a SQL query. The variables connectionString and sqlstring are properties of the Web Part containing the connection string necessary to connect to the data source and the SQL query to fetch the data.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date