I'm creating several lists (and their views) programmatically, based on custom list definition templates.

When these views display more than 30 items, the following link is displayed:

(More items...) link

Whereas on views generated from native templates, the following paging method is shown:

1-30 >

Normally this wouldn't bother me, but the "(More Items...)" link doesn't actually work; it redirects back to the first page of the default view. So how would I go about setting the view up to use the normal paging method?

Here is the relevant section of the view in the list definition:

<RowLimit Paged="TRUE">30</RowLimit>

And the contents of the "(More items...)" link:

<a href="http://morzine/t1/_layouts/listform.aspx?ListId=%7BE0B59C1D%2D2D71%2D49F7%2DB207%2D23A5A43F4FAC%7D&amp;PageType=0" id="onetidMoreAnn">(More Items...)</a>
  • Your rowlimit is set to 30, but you say: "when these views display more than 30 items..."? Commented Feb 4, 2012 at 20:10
  • Did you change your mail.xsl in any way? You can have a look at it in the _layouts/xsl/ folder. Also, you could write your own custom xsl. Commented Feb 5, 2012 at 8:13
  • @VardhamanDeshpande: Nope, the main.xsl is untouched, and the problem is reproducable on a variety of dev and QA servers. The fact that it happens for some lists referencing it but not others would seem to outrule it as the cause of the issue.
    – Stu Pegg
    Commented Feb 5, 2012 at 12:16

2 Answers 2


I expect you have "BaseViewID" attribute set to "0" on the "View" element of your custom list definition. You should change this attribute to some other value (in range 1..255) and the problem should vanish then.

Although this is actually all you need to solve the issue, I anticipate you might want some more detailed explanations :)

Actually, BaseViewID is a curious thing! On MSDN it is described as:

Optional Integer. Specifies the ID of the base view.

But in the point of fact, there is no any "base view" out there. AFAIK, it is just an abstract term which I guess should have meaning only when displaying different views of standard lists (like Links, Announcements, Tasks, etc.). But as you can see, sometimes it influences custom lists, too. Accidentally, I guess.

Although "base view" is an abstract thing, it's ID amusingly has a very specific meaning when it comes to displaying a list view :) In 14/TEMPLATE/LAYOUTS/XSL/vwstyles.xsl you can find an astonishing number of BaseViewID matches. And vwstyles.xsl is one of the most important files for the XsltListViewWebPart, which in SharePoint 2010 is the essential block and it is responsible for displaying almost every list view (with the only exception of Calendars, actually).

In particular, the BaseViewID="0" secret meaning is revealed by a comment in the vwstyles.xsl file:

<!-- BaseViewID = 0 is summary view (home page view)-->

So BaseViewID 0 is intended for using in views, which are added to home page! Remember, when you're adding a XsltListViewWebPart to a page, you can select to display "Summary view" in webpart properties. This is actually "BaseViewID=0" view. Feel the difference:

Ordinary announcements view

enter image description here

Summary (home page) announcements view

enter image description here

As you can see, the views look completely different! While the only thing which changed in their definitions was BaseViewID property.

That is what happened with your particular view, actually. Since it was unknowingly marked as a home page view (BaseViewID=0), it's paging had been hidden and the link to default view was added. Obviously, since this was the default view and at the same time it was a homepage view, the thing didn't work as it should.

By the way, you might have noticed that in your link code, you have id="onetidMoreAnn" attribute, where "onetidMoreAnn" stands for "onet identifier for more announcements". Thus, the link was originally intended for using with the announcements view. And in summary view of the standard Announcements list view, if you add more than 30 items, you will behold the same link.

Hope it's clear now, but please, feel free to ask any further questions.

  • 1
    Genius! That solved the issue. Word of warning though: Removing the BaseViewId attribute stops the view from showing any results at all in my experience (and I reproduced this issue just now). However, setting it to 1 did the trick. :) Thanks!
    – Stu Pegg
    Commented Feb 5, 2012 at 12:34
  • I'll award the bounty once the cool-off has expired (after 5 hours).
    – Stu Pegg
    Commented Feb 5, 2012 at 12:35
  • Hmmm, that's strange, BaseViewID marked as optional. Thanks for mentioning, I'll reflect the answer for further readers. Commented Feb 5, 2012 at 12:37
  • 6
    Thanks :) Actually I've merely missed that question, I would be happy to answer even without any bounties :) Thus, if you have more XSLT-related, Ribbon-related or clientOM-related questions please point me to them before starting bounty, this could save you a good bunch of reputation points :)) Commented Feb 5, 2012 at 12:41
  • 2
    It was well worth the reputation to save me chasing my tail for hours!
    – Stu Pegg
    Commented Feb 5, 2012 at 21:35

Create your views in the UI, examine them in SharePoint Designer or SharePoint Manager, look for differences between the native views and your 'bad' views and import them in your Visual Studio Solution.

  • Good tip, but I've already done a side-by-side SPM comparison, which turned up no differences.
    – Stu Pegg
    Commented Feb 4, 2012 at 20:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.