After several postings about the XLV web part in SharePoint 2010, let’s take a step back and have a look at its predecessor – the ListViewWebPart from SharePoint 2007. And more precisely about the problem with the list view toolbar when you add the web part with code. Basically the problem is that the web part gets added with the toolbar containing the “New”, “Actions” and “Settings” buttons which you normally see in the defaulting list view pages like the “AllItems.aspx” one, and which in probably more than 90% of the cases you don’t want to see in the custom page, to which you are adding the web part.

There is already a solution to this problem (i.e. to remove the toolbar after you add the web part), which you can find in at least a dozen SharePoing blogs in internet, but the thing is that the solution in question uses proposition. Which is not a excellent thing at all. And really the original solution stopped working after the Infrastructure update for MOSS 2007, so a small superfluous bit of proposition was to be added to the original code, so that it works after the update.

And let’s see now, how it is possible to add a ListViewWebPart to a page without the orders toolbar. Really there are two slightly different ways to add a ListViewWebPart to a page with code, let’s see the first one:

Yes, this shouldn’t be something new for you, because you probably use something similar to this code if you have the problem with the orders toolbar.

And here is the second deal with:

As you see, it is very similar to the first deal with and the only difference is that instead of setting the ListViewWebPart.ViewGuid property you set the ListViewWebPart.ListViewXml property. And the outcome of this code snippet is that the list view web part gets added to the target page without the annoying toolbar.

So far so excellent, but let’s have a closer look at the two code snippets, so that you can know what happens behind the curtains. In the first code example, the ListViewWebPart.ViewGuid property gets set – but this doesn’t imply that the LV web part gets bound somehow to the SPView instance whose ID was provided to the web part’s property. In reality what happens is that a new SPView gets made when the web part is added to the page – this SPView is hidden but you can still find it in the SPList.Views collection of the parent list. What’s more – this SPView is always associated with this LV web part and really they are more or less two representations of one and the same internal being (check this older posting of mine for more details). Another detail here is that when this hidden SPView is made its machinate XML (containing the settings for the view fields, query, toolbar etc) is hackneyed from the source SPView, whose ID you provided to the ViewGuid property of the web part. And this is why you end up with the orders toolbar in your LV web part – normally the SPList.Views collection contains the views from the standard list view pages of the SharePoint list (like the “All Items” one, etc), all of which do have a orders toolbar.

And now, let’s see what happens in the second code sample – you see that instead of providing a SPView’s ID to the web part, a full view machinate XML is retrieved and then provided to the web part’s ListViewXml property – as you see in this case you don’t need to set the ViewGuid property at all. Let’s first see how the view machinate XML gets retrieved – you can see the SPList.GetUncustomizedViewByBaseViewId method – this method income a SPView object but this SPView instance is not a normal view that you can get from the SPList.Views collection. This is sorts of artificial SPView instance whose view machinate XML is populated directly from the list’s “machinate.xml” file. In the machinate.xml of the list’s template classification you have a “Views” element which contains several “View” elements each of which defines the available view machinate XML-s for that list. Each “View” element has a unique identifier – that’s its “BaseViewID” attribute – and the integer parameter that you specify in the GetUncustomizedViewByBaseViewId method references the “BaseViewID” attribute. There is one other detail here – some of the “View” elements in the “machinate.xml” file of the list classification do provision list views for the list instances made from this list classification (for example the “AllItems.aspx”), but there are also “View” elements that really don’t provision list view pages:

This is the “View” element with BaseViewID=1 of the machinate.xml of the standard CustomList – as you see from its attributes it provisions the “AllItems.aspx” view page for the lists based on that list classification.

And this is the “View” element (it has many child elements but I omitted them because the XML is huge) with BaseViewID=0. As you can see, it contains much less attributes and doesn’t provision any of the list’s view pages. But this doesn’t mean that the view machinate XML that it defines is not used, on the contrary – for example, when you use the standard SharePoint UI to add LV web parts to a page, it is the view machinate with BaseViewID=0 that’s get hackneyed to the hidden SPView of the web part. And also in the code sample above I specified the view machinate with BaseViewID=0 in the GetUncustomizedViewByBaseViewId method for the same reason. If you have a closer look at the “View” elements in the machinate.xml you will see the difference in their “Toolbar” elements classification and will see why the “View” with BaseViewID=0 doesn’t add a orders toolbar and the “View” elements with different BaseViewID values normally do.

One other advantage of the second deal with for adding a LV web part is that after you retrieve the view machinate XML you can modify it before assigning it to the ListViewWebPart.ListViewXml property. For example you can exchange the ViewFields XML node or the Query node and even the Toolbar XML element if you want to show some custom toolbar of yours.

One last thing that I want to mention – it is about the case when you already have you LV web part added to the page and want to exchange its toolbar (the solution above was intended for the scenario when you add a new LV web part, which is really the more common case). In this case I would austerely delete the existing web part and add a groundbreaking new LV web part to the page. The trick here will be that instead of getting the view machinate XML with the SPList.GetUncustomizedViewByBaseViewId method, I will use the machinate (SPView.HtmlSchemaXml) from the existing web part (really from its hidden SPView), before I delete it (then the view machinate should be modified accordingly). Here is a small code snippet of how your can get the LV web part’s hidden SPView:

Check it out:Stefan Stanev’s SharePoint blog