Remember the good old days, before SharePoint 2010, when a dropdown on the top right of a List View Web Part (LVWP) allowed you to select different views, quicly and easily?
In SharePoint 2010 we have lost this handy feature. On some pages, a substitute does exist in the Breadcrumb on the title bar (which is part of the Ribbon, at the top of the page). It took us a little while to actually realize was there – but once we found it, it was very welcome.
But wait, all is not well. as Kerri from one of our partners – LookOut Software who develop CRM software for SharePoint – pointed out even the breadcrumb option disappears on the majority of pages. It disappears if you
- Add another list view web part
- Add any other web part such as a Content Editor Web Part containing things like instructions for the list
- 3rd party web parts like our PivotPoint or FilterPoint tools that work really well alongside list views for creating dynamic dashboards.
- use your list on a wiki page – and remember most of the pages in SharePoint 2010 are wiki pages by default now.
Also you don’t get it if you’ve created a new page and added a list view web part to it.
Once it’s gone, you have to resort to the following ninja moves to change a view. Select the list title (or something in the list) > List Tools > List, Current View dropdown > Then the view you want. 4 clicks? My finger is getting sore SharePoint!
This bugged me so much that I decided to look into it further and ended up developing a little tool which – well – rescues the view selector drop down.
If you just want the solution you can skip the rest of this post and download our free fix for this annoyance – ViewRescue
The class that generates this menu is ListTitleViewSelectorMenu.
Looking into this class with Reflector.NET you find the following snippet of code.
public override bool Visible { get { if (!this.SingleWebPartPresentOnPage) return false; else return base.Visible; } }Basically, it’s set to not show the view selector if there is more than one web part on a page. I don’t know why this might be but I suspect that it’s because if there are more than 2 list view web parts on a page then which one do you choose to show the views for. Rather than complicate the UI with multiple choices or simply choose the first web part on the page I suspect the SharePoint development team decided to show nothing instead.
From there I found a post describing how you can use SharePoint Designer to modify a view’s .aspx page to put the view selector back. The problem with this method though is that you have to edit each view page individually and that also produces un-ghosted pages.
Instead I wanted something a little more automatic that you could apply to an entire site in one go.
Normally Delegate Controls are the way to achieve this sort of customisation, but the ListTitleViewSelectorMenu isn’t wrapped by delegate control so that’s out.
But what you can do is implement a delegate for the AdditionalPageHead delegate control that is included with every page in SharePoint.
In the OnLoad event of our delegate control we can find the ListTitleViewSelectorMenu and check if it’s visible. And if it isn’t (as there are more than one web part on the page) we can change it to be visible. Job done!
Except we can’t – the Visible and SignleWebPartOnPage properties are read only and everything else is hidden…
OK – we can create our own, derive from that class and override the visible property. Except we can’t – its sealed…
OK – lets use the nuclear option then! Use reflection to set the private properties in the class. This has obvious dangers should the class internals change – so this technique should only be done when there is no other choice.
Add some appropriate error handling code and were done for the standard lists, but what about Web Part or Wiki pages we’ve created and added a LVWP to?
In this case there is no ListTitleViewSelectorMenu on the page at all – visible or not. So what we have to do is to add our own – inside CreateChildControls we find the PlaceHolderPageTitlteInTitleArea control and add some spans and a ViewSelectorMenu (which is the class that the ListTitleViewSelectorMenu actually uses to render the menu).
This class needs to be told which List View Web Part (lvwp) to render the menu for so we find the first LVWP on the page and create an SPContext (which is a RenderContext) with the view to pass onto the ViewSelectorMenu.
Job done! Download our free ViewRescue tool today and banish this SharePoint 2010 annoyance from your life!
Tags: Free, SharePoint 2010, Web Part
This is great, I read this article yesterday and thought v. interesting and I then proceeded to find a missing view on a Task list that I’d added a chart web part to.
Alright, so I ran into this today. And instead of having to get into the code, I basically put in a content editor and linked a table (with the view names) right above it. I don’t have access to all that stuff you mentioned to do (wish I did…).
Thanks!
Sometimes we do not even see the List or Library tools, so our “ninja moves” (love that!) are to either expand collapse a group in the view or click the + sign next to Add Item. Found out by accident that that causes the List or Library tools to appear. So yeah, lots of sore fingers around here! Our Admin team will not allow any fixes to be applied – even when they come from MS – so that leaves us with little choice but to remove CEWPs and all those helpful instructions that we use them for.
Is there any reason why I shouldn’t modify your wsp and run this as a sitecollection feature instead? Did you find performance issues when running this on every web in a collection?
@Jason – That will work fine, no reason for site scope apart from better granularity in usage. I’ve sent you an email with a WSP scoped to the site collection level. If there is demand for a site collection scoped version post here and I’ll make this an option on the main download/install.
This is really something I needed. I would nevertheless suggest not to pick the first ListViewWebPart found on the page but to use SPContext.Current.ListId instead to pick the right context – in getFirslListViewWebPart() change
“if (part2 != null)”
to
“if ((part2 != null) && (part2.ListId == SPContext.Current.ListId))”
This will usually activate the “right” ViewSelectorMenu.
@Ulrich – Nice idea, but I am afraid that won’t work on all page types.
SPContext.Current.List/ListID etc works OK on a list or view page (i.e. the pages that are created when you create a list or view).
But on Web Part Pages it will always be set to the list “Site Assets” and on Wiki Pages (the 2010 default page type) it will always be “Site Pages” – regardless of what LVWP’s are added to the page.
If you want I can get you a debug version that trace outputs all this so you can verify yourself that SPContext.Current doesn’t work in 2 of the 3 page types.
@Ryan – I understand your reasoning. I wonder if it would be clever to determine the “best” ViewSelectorMenu by iterating through all LVWPs on the page and returning
– the LVWP matching SPContext.Current.List if it is found on the page
– the first LVWP otherwise
@Ulrich – that would work, a slight variation would be to use SPContext.Current.List only on List View pages and the first LVWP otherwise.
Can I ask are you having problems with it picking up the wrong LVWP on a page and if so what type of page this is?
@Ryan The business case here is quite a complex page (within a team site) that combines 5 different LVWPs on a single page. Users are navigating there using tree view – so the SPContext is really pointing to the correct SPList in this case, as they do hit a ListView-Page. This list is a modified Issue list with different views (Active, Resolved, etc) – but its “own” LVWP is only second on the page. The first LVWP displays some general information contained in a single custom list element.
All other LVWPs are filtered using webpart-connections, (the filter basically depends on the seleced issue but kind of cascade from LVWP to LVWP) – so it is not neccessary to access any other views except for ones defined for the issue-list. Ah yes – and there are about 1800 of these team sites/pages, most of them still in MOSS 2007 but awaiting migration.
@Ryan I should probably also describe what is going wrong with this page when using the original DelegateControl: When I first hit the issue list (so this is the default view) the expected ListViewMenu appears – allthough the list`s LVWP is only second on the page. But as soon as a different view gets selected the ListViewMenu changes to the first LVWP`s one. Another click on the ListViewMenu switches the context to this list, leaving our complex page. I already built a modified delegate control (reflecting on your code) and can confirm that this version works as expected (i.e. stays within the original list´s context)
Ryan,
Great work, but I have a little issue.
I have a home page with 2/3 LVWP’s, your feature is picking the wrong list/web part to show the views. It doesn’t matter how I order the WPs on the page, is there a trick to force the feature to pick a specific list/webpart?
@Freddy – it should pick the first one that was added to your page (which is not necessarily the same as the order that they are in) can you try this please?
Thank you for this solution handling the “Missing View Selector” problem. It works really great for list view pages.
Unfortunately the feature also includes a View Selector on every page which has a ListView web part. So also default and publishing pages are holding the view selector which is a confusing behavior for our users and prevent use from using the feature.
Is there a possibility to just show the list view selector on list and library view pages and not on all other pages?
Furthermore a using a Site scope for this feature instead of a Web scope would be administrable.
Hi. Could I get a copy of the WSP package to deploy it as a sandbox solution scoped to a site collection? Thanks!
@Rodrigo – You can’t deploy this as a Sandbox solution as delegate controls are not supported in sandbox solutions.
Hello Ryan,
Do you think it’s possible to just show the list view selector on list and library view pages and not on all other web part pages?
Thanks,
Stephan
Ryan, in your October 10th comment to this post you mention a solution scoped to the site collection level. I am interested in this as well. Thank you.
you can do this by your own – just change the scope in the solution xml definition
@Julie – I’ve sent you an email with this – going to make it an option on the main installer shortly as well.
Can you provide the ViewRescue tool for SharePoint Online 2010 ? Instead of running an EXE (cant do in SP OL) , can you provide the webparts or code that can be uploaded to SP OL as a solution?
Thanks, Jost
@jost – it just won’t work for SharePoint Online I am afraid. Even if I give you a .wsp it won’t run as ViewRescue is a “DelegateControl” and they arn’t allowed in Sandbox Solutions that office 365 uses – there are a LOT of restrictions and this is just one of them. You can modify the pages manually though, see the links in the article.
If you wanted to double the usefulness of this tool, it would also automatically “select” the first list on the page and make the ribbon appear on the top.
This does help with the View issue, but users still have to click on the list to start manipulating it on the ribbon.
Excellent, just what I needed.
Hi Ryan,
did you have an answer for what Stephan asked a while ago? I have implemented this but now I’m seeing the same issue as him:
thelist view selector is now shown on all other web part pages (Homepage) and this is not desired.
“Setsch says:
January 9, 2012 at 8:43 am
Hello Ryan,
Do you think it’s possible to just show the list view selector on list and library view pages and not on all other web part pages?
Thanks,
Stephan”
Regards,
Robert
@Robert – no there is no way of turning it on and off for individual pages I am afraid. You’re best bet is to follow the article linked in teh post which shows how to use SPD to do this manually on a page by page basis.
http://vintentou.wordpress.com/2010/08/03/missing-dropdown-menu-for-choosing-of-views/
thanks, but that is not really a solution for me. I managed it using css “display: none” for the parts that by Default should not apear on the Homepage.aspx. As I already have an Web Part with a code, it was easy just to extent the code with the necesary style.
anyway, your solution saved me 😉
regards,
Robert
I’d appreciate the wsp that is scoped to the site collection level vs. the site level that you sent Jason Kutler way back in October of 2011 if I could get it.
Hi Sandy – on its way, check your email.
Hi Ryan – Great solution!
I was looking to use this on a Calendar view hoping it would preserve the ‘Calendar Tools’ tabs at the top of the page as they are vital for my view. Is there any way you can think of to do this?
Hi Ryan,
Can you send me the wsp? IT would not allow me to install an exe in the server.
Thanks in advance.
Regards,
Alex.
Thank you very much Ryan for the wsp.
Thanks Ryan, this post saved my users thousands of clicks. No one else has spoted the breadcrumb!
Good one Ryan. Thanks