You probably know that one of the cool new features of the Content Query Web Part in SharePoint Server 2010 is the support to QueryString and PageField filters.
This was achievable also in MOSS 2007, but you had to rely on Parameter Bindings applied to the CQWP control, which made it a little more complicated since it requires some more knowledge about the “DataView family”.
Just a small note, though: if you keep using the QueryOverride mechanism (i.e., you specify a custom CAML query overwriting the default CQWP behavior), you completely lose the new filters functionality.
More generally, any time you apply some override (Query, View, etc…) the CQWP skips its automatic CAML query/filter/projection generation, and all of the plumbing it’s up to you.
With great power comes a great reponsibility!!
Well, this is a tipical situation when you may say “it’s easy”.
And it is, indeed, but you have to be aware of a couple of “small” issues.
First of all, you know that the SPListItemCollection class exposes a count property, you invoke it and voila, you get the total numebr of items contained within a SharePoint list.
But… be careful, because you are fetching *all* items, possibly causing a hige load on the server (SharePoint and SQL Server).
A better approach would be using the ItemCount property of the SPList class.
Which is what I would suggest, with a little gotcha: ItemCount returns exactlt what the name suggests, i.e. the count of all list items, and doing so it *does not* apply any sort of security trimming. In other words, if the code is run within the context of a user who has the rights to view only 5 out of a total of 10 list items, this property returns 10.
Pay a lot attention when you are looping or indexing an SPListItemCollection this way!