SharePoint provides a handy control commonly known as a "people picker" that allows users to search for and select users defined at some specified scope.  This control is normally associated with Personnel field in a SharePoint List.  However, what happens when you need to add this functionality to some custom component and need to access it programmatically?  It gets a lot more complicated!

This article is meant as more of a repository of knowledge that I've discovered while working with this control rather than a "how-to".  If you are looking for How-To articles, try these: Eric Kraus or SharePoint Tips.   Likewise, please let me know if you have any additional information about the actual workings of this poorly documented control.

Where to find the control

The control is actually called a "PeopleEditor" and is in the 'Microsoft.SharePoint.WebControls' namespace.  You will need to add a reference to 'Microsoft.Sharepoint.dll' to your project in Visual Studio, which is something you probably already have if you are writing anything that works with SharePoint.

What is it?

The PeopleEditor is simply a standard UserControl with it's own hierarchy of elements.  If you were to walk the tree of controls used, you would see the structure shown below  (control IDs are in green italics).

Microsoft.SharePoint.WebControls.PeopleEditor
|-System.Web.UI.HtmlControls.HtmlInputHidden (hiddenSpanData)
|-System.Web.UI.HtmlControls.HtmlInputHidden (OriginalEntities)
|-System.Web.UI.HtmlControls.HtmlInputHidden (HiddenEntityKey)
|-System.Web.UI.HtmlControls.HtmlInputHidden (HiddenEntityDisplayText)
|-System.Web.UI.WebControls.Table (OuterTable)
|- |-System.Web.UI.WebControls.TableRow
|- |- |-System.Web.UI.WebControls.TableCell
|- |- |- |-System.Web.UI.WebControls.Table
|- |- |- |- |-System.Web.UI.WebControls.TableRow
|- |- |- |- |- |-System.Web.UI.WebControls.TableCell
|- |- |- |- |- |- |-System.Web.UI.HtmlControls.HtmlGenericControl (upLevelDiv)
|- |- |- |- |- |- |-System.Web.UI.WebControls.TextBox (downlevelTextBox)
|- |- |-System.Web.UI.WebControls.TableCell
|- |- |- |-System.Web.UI.WebControls.HyperLink (checkNames)
|- |- |- |-System.Web.UI.LiteralControl
|- |- |- |-System.Web.UI.WebControls.HyperLink (browse)
|- |- |- |-System.Web.UI.LiteralControl
|- |- |- |-System.Web.UI.HtmlControls.HtmlInputButton (CreateItem)
|- |-System.Web.UI.WebControls.TableRow
|- |- |-System.Web.UI.WebControls.TableCell
|- |- |- |-System.Web.UI.WebControls.PlaceHolder
|- |- |- |- |-System.Web.UI.WebControls.Label (errorLabel)
|- |- |- |- |-System.Web.UI.WebControls.Table
|- |-System.Web.UI.WebControls.TableRow
|- |- |-System.Web.UI.WebControls.TableCell
|- |- |- |-System.Web.UI.WebControls.Label

Of particular interest are upLevelDiv and downlevelTextBox as those are the controls used when a person is manually entering a name.

Developing With It

The default behavior and styling is sufficient in most cases.  However, if you need to do more than the very basics with the control then I strongly recommend that you subclass it so that you can hook into the control behavior at a much deeper level.  Some of the things you get with this approach are:

• Control over Formatting.  Microsoft hard-codes much of the formatting in the control and buries it behind protected methods so that you can't touch it from the outside.  Microsoft applies the style between the PreRender() event but before the SaveViewState() event.  In order to change the style used, you will need to override the Render() event and apply your style changes immediately before the actual control is rendered.
• OnChange event.  There is none exposed but by subclassing it you can create your own and then hook into the RaisePostDataChangedEvent() method in order to raise your own.
• Access to the actual controls used.  All of the controls used by the people picker are available as protected properties which means that your subclass has direct access to them without having to walk the hierarchy.
• Future Changes.  By subclassing this control at the beginning and coding to your new class, you are laying the foundation so that you don't have to redo tons of code later on in the event that you find yourself needing some of the protected behaviors.

Quirks

• Normally, you will want to work with the .Entities collection as that has the most information available about a selection but there is a great big "Gotcha" here.  You need to reference .CommaSeparatedAccounts property before calling .Entities because the collection seems to only get populated after that property is referenced.
• Another Gotcha is that the control will do an Active Directory lookup of all the names you enter in .CommaSeparatedAccounts so it can be a bit of a performance hit - especially if one of those names isn't in AD.  In my environment, populating this with one valid name takes 0.1 seconds.  Not much, but if you have several of these controls populated with several names then that quickly adds up to real time.
• The .Entities collection is sometimes null so you have to be careful when working with it.  Given that normal development practices dictate that all public collections exist but have a .Count of zero, I have to assume that this is either developer oversight or an indication of some internal state.  In either case, watch what you are doing when working with this and always check it against null before referencing properties of it.
• The RaisePostDataChangedEvent event seems to fire whenever the page is posted back a second time even if the value hadn't changed. 
• Since this is actually a SharePoint control, it expects a few things to be in place - specifically that SharePoint's "core.js" be included on the page.

Styling the Control

Microsoft embeds the formatting for the control deep inside and then makes use of the .Style attribute rather than the .CssClass attribute which makes styling it somewhat problematic as the .Style attribute will override anything in your CSS.  To make this a little bit worse, this control renders differently in IE than in other browsers like Firefox so you will have to solve styling for both browsers.

Here is what the control renders as in Internet Explorer (I've highlighted the key styling areas and their associated class)

Here is how it renders in Firefox.  Note that the resolved user name shown is the Domain ID instead of the user name like in IE.  Also, this is a simple textbox instead of the textbox/div combo that IE uses.

Tracking down what style is used where is made considerably easier with tools like the Developer Toolbar for IE and FireBug for Firefox - both free.  These tools allow you to inspect page elements as they are currently rendered, showing the hierarchy of styles, controls and such.  They are invaluable if you will be doing considerable tweaking to the layout of the People Picker.

Validation

There is an internal validator that allows you to validate the names entered (both on client and on Page Postback) and it works like any other validator in Asp.Net.  You can enable this by setting the .ValidatorEnabled property to "True".

It is worth noting that this is merely an implementation of the IValidator interface so it cannot be cast as one of the standard Validator types (CustomValidator, RangeValidator, etc.).  This can be problematic if you are trying to work with it via the Page.Validators() collection as the IValidator interface doesn't really provide enough information to be useful.  In my case, I had to cast it as my subclassed version of the PeopleEditor control and then get the values I needed that way.

Helpful Links

• PeopleEditor on MSDN

The SharePoint Timer service is handy for what it does but it occasionally gets very hungry and devours hundreds of megs of RAM and keeps it for hours.  This isn't a problem on most production environments because of the memory those machines typically have but it can be a killer on a memory challenged dev Virtual Machine.

The most common symptoms that I've run across is that starting Visual Studio in Debug Mode takes 2-3 times as long as normal and stepping through the code is painfully slow.  When this happens, I restart the timer and all is well again.

I used to do this from the Control Panel but found that there is a much more efficient method: use a batch file with the commands below and just run it periodically.  I have a shortcut to this in my Quick Launch menu and run it before starting any development.

net stop "Windows SharePoint Services Timer"
net start "Windows SharePoint Services Timer"

Of course, if you happen to be doing work that doesn't rely on the Timer functionality (which is most likely the case) then you could always turn off the service and avoid the problem entirely.

There is a trend out there where people are taking perfectly good machines running Windows Vista and then uninstalling it in order to install the venerable Windows XP.  This process hasn't had a name up until now but I think I have come up with a good term for it : Devistafication. 

Here is how I would define it:

de-vis'ta-fy:
tr.v. de-vis'ta-fied, de-vis'ta-fy-ing, de-vis'ta-fies
The act of removing Windows Vista from a computer and then installing a different operating system, such as Windows XP.

de-vis'ta-fi-ca-tion  n
de-vis'ta-fi-er  n

I hope this helps to ease the language burden often associated with this task :)

Microsoft has released a Hotfix for the incredibly annoying performance issues when working in the Design view of an Asp.Net form that contained custom user controls.

The installation info is on the MSDN Blog and is pretty self explanatory.  It takes a few minutes to install but it is worth the wait.  Before the patch, simply switching to Design view for one of my Asp.Net forms could take upwards of 30 seconds.  After the patch, it takes around 3 seconds and half of that is the pulling together the nested master pages behind the form. 

I've also noticed that the properties window now switches almost immediately when I click on a control.  Before, it would take 5-10 seconds to change and sometimes never did.

I have worked in numerous programming languages and the one thing that I find most irritating is that every language feels the need to reinvent Nothing - literally - and then applies their own rules to it.

In VB, Nothing is Nothing.  In C# and JavaScript, Nothing is null.  Ruby's Nothing is nil.  Nothing can also be Null or Empty or undefined, although it can sometimes be NaN, which is not necessarily Empty or Null.  Something that is undefined is sometimes null and sometimes not but something that is null is rarely undefined.

Throw in the mix how badly empty strings are handled where "" is not Empty or null, but is an EmptyString and could be NaN.  It could also be a NullString, which is still not a null or even a Null and certainly not an Empty or undefined.

Nothing/Null/null/nul/nil is a basic part of any programming language.  Is there any chance that we could pick one term, like Null (or null even), and use it across languages?

It's just a word, what is the big deal?  The word itself is trivial but the need to use a new term for something so basic is the root of my aggravation.  Each language feels that they have to use their own terms to be "cool", yet are just rebranding well established concepts without adding functionality.  That isn't innovation, that's marketing.  It's "New and Improved" without being either.

All it accomplishes is that it adds one more tiny step in the learning curve for that language and slows adoption.  Further, assuming that the "cool" factor won out in other areas, then there will be hundreds of other such tiny steps as well, all without any added benefit.

Tell you what, I'm going to create my own programming language called Presidents.Net, where all of my core data types are named after past Presidents.

private Jefferson ProcessRequest(Washington pRefID, Jackson pAmount)
{
   Lincoln User = getUserID(pRefID);
   Eisenhower AccountNumber = getAccount(User);
   ...
   return applyTransaction(AccountNumber, pAmount);
}

What is the value added?  Nil, or ... null ... or ... Polk.

They have stories from the dawn of computing, about the problems with tape backup, data layouts using bitmasking to save single bytes wherever possible and can regale you with tales of horror about the era of punchcards.  While they can expound for hours on middling details of tech found only in museums, they are surprisingly quiet on the merits of any recent technologies.  One could say that their value is historical but I think they serve a far greater purpose.

They are warning posts, put in place to remind you about the perils of complacency.  About what will happen to you if you let your skills lapse or get too comfortable with any one particular technology.  This field moves too fast and they are glimpses into your own future if you stop moving with it.

Talk with them.  Listen to them.  Consider them the career equivalent of a car wreck.  They hit the brick wall so you don't have to.

The other day, I found myself in need of a way to access SharePoint list data as XML but the only method available to me was a simple http GET.  This is not too bad, but what can I get from SharePoint via GET?  RSS is too limited and scraping the page is too painful and error-prone to even contemplate. 

It turns out that there is an option available in 2007 that was carried forward from SharePoint 2003 / FrontPage days: owssvr.dll.  But this isn't some forgotten FrontPage artifact, it is still a central part of SharePoint.  In fact, if you pull up a list view and then view the source looking for owssvr.dll, you will see that this is the mechanism behind both the Export to Spreadsheet and Open with Access options on the list Actions menu.

How It Works

Simply put together a URL like this:

http://MyServer/[site]/_vti_bin/owssvr.dll?Cmd=Display&List={listGuid}&XMLDATA=TRUE

This will only return the fields that are defined on the default view of the list.  If you need specific fields then you need to create a view with those fields and pass the View ID as well, like this:

http://.../owssvr.dll?Cmd=Display&List={listGuid}&view={viewGuid}&XMLDATA=TRUE

Specifying Fields to be Returned

There is also a Query parameter that lets you specify which fields are to be included in the resulting XML, regardless of how the view is defined.  For example, if you wanted just to bring back the Title and Status Fields, you would add the field names separated by spaces (URL Encoded, of course) like "&Query=Title%20Status".  If you want to return all fields, use an asterisk (*) instead of field names.

http://.../owssvr.dll?Cmd=Display&List={listGuid}&query=Title%20Status&XMLDATA=TRUE

Filtering Data

Regardless of whether you pass a view or use the default it will still use the filter defined by that view.  Not bad, but you can trim this data even more by including a filter of your own using the FilterFieldn and FilterValuen arguments in the querystring.  These are the same values that are passed when you use the filter options in the column headers of a view which makes it pretty easy to track down exactly what needs to be passed.  Simply pull up the view that is your starting point and use the column filters to create your desired filter.  Once you have it, grab all of the FilterField and FilterValue items from the querystring and add them on to yours.

http://.../owssvr.dll?Cmd=Display&List={listGuid}&query=Title%20Status&XMLDATA=TRUE&FilterField1=Status&FilterValue1=In%20Progress

For a full list of what can be done with this technique, check out the URL Protocol or the older Using the URL Protocol on MSDN.

I've spent the better part of two days tracking down an extremely nasty bug in InfoPath that corrupts an InfoPath form completely and almost terminally after connecting to a WCF (Windows Communication Foundation) web service.  Each time you try to open the form in design mode, InfoPath kicks out the error below and then refuses to open the form.

"InfoPath cannot open the following form: C:\long\path\to\form.xsn.  The XML Schema file specified in the form definition (.xsf) file for dataObject 'xyz' cannot be used"

Once this happens, there is no way to get InfoPath to edit the form again.  However, there is a fix.

The Fix - Recovering your work

First, we have to get you so you can edit your form again.  Since the actual error hides itself completely during the initial design session it is possible to lose a lot of work, depending on how much you worked on the form during the session where you connected it to the web service.  Either way, you have to fix both problems in order to get the form working properly anyway.

1. Create a new folder and copy your "corrupt" .XSN file to that folder. 
2. Rename it from .XSN to .CAB (Yes, .XSN is really just a .CAB)
3. Use a compression utility that can read CAB files (like WinZIP) to unpack the contents of the file into that folder. 
4. Open the Manifest.xsf file in a text editor (NOT in InfoPath) and look for "<xsf:dataObjects>"  under that node, you will see several <xsf:dataObject> nodes. 
5. Delete all <xsf:dataObject> nodes that point to WCF web services.  You can spot these easily because they usually have ".svc" somewhere in the wsdlUrl attribute of the <xsf:webServiceAdapter...> child node.
6. Save the Manifest.xsf file. 
7. Now right-click on the manifest.xsf and select 'Design'.  This should open InfoPath and will give you a warning that the form has been moved.
8. Click ok. At this point, the form should open in design properly.  You should also see "[Read-Only]" in the title bar.
9. Go through all views in your form and disconnect any controls that were bound to the WCF data sources.  Sometimes this is as simple as converting them from whatever type they are to text boxes.
10. Click File -> Save As and save the file to the folder where you want the file to reside.  This will automatically save it as an .XSN file again.
11. Close InfoPath (very important- don't just close the form)
12. Browse to the the new folder and find the new .XSN file
13. Right-click on it and select 'Design'.
14. Click 'Preview' to preview the form.  If you get the error "InfoPath cannot open the selected form", it means that one of your controls is still bound to one of the data sources you removed earlier.  Check your controls again and also check any Rules you may have defined under Tools -> Form Options -> Open and Save -> Open behavior.

At this point, you should now be back editing your form as normal, just without the web service data.  Warning: do NOT reconnect to the web service until the next part of the fix is completed.  Doing so immediately lands you back at step 1!

The Fix - Fixing the Web Service

This will require the help of the author of the web service who will probably deny that there is an error and try to blame InfoPath because it works in all of his loosely typed test applications.  You must convince them that the problem really is with the way the service is defined.  Perhaps this entry will help, perhaps not.  Either way, he will have to do something with his web service if he wants that data exposed in your form because it won't work as it is right now.  I was lucky that the developer of the web service was every bit as curious about this error as I was so we were able to troubleshoot this from both ends.

The root of the problem is that one or more of the underlying data types is defined with an improper Namespace in the [DataContract] attribute or one that doesn't match all of the others.  InfoPath is extremely particular and if the namespaces don't match precisely, it will cause the error mentioned at the start of the article.  It is case-sensitive.

To track down exactly where the problem lies involves a little bit of detective work and some of the files extracted from Step 3.  When you created the Data Connection to the web service call in InfoPath you gave it a name like 'GetSomeDataFromJoe'.  If you look in the folder from Step 3, you should see 4 or 5 files called GetSomeDataFromJoeXX.xsd where XX is a number between 1 and 99.  These are the actual schema files that InfoPath pulled down when you connected to the web service.  Send these to the developer.  If he looks through them, he will find one (usually the second in the series) that shows the data types found in the web service.  One or more of the types he is using should be missing completely from the XSD files which means that those are the ones with the broken namespace.

After fixing this, the developer will need to build and then publish the web service before you can attempt to connect to it again.

Putting it All Back Together

Now that the developer has assured you that the fix has been made you will need to reconnect to the web service. To reconnect safely, try it this way:

1. Backup your current working form (.xsn) from the first part of the fix - just in case the developer hasn't gotten the fix quite right yet.
2. Open the form for design in InfoPath
3. Reconnect to the web services
4. Save the form and close InfoPath
5. Reopen the form in InfoPath. 
6. Switch to Design mode.
7. If it opens properly then the developer cleaned up his namespaces and it is safe to reconnect your controls to the web service data.
8. If you still get the "... XML Schema file ... cannot be used" error, then the problem is still in the web service.  Delete the .XSN (because it is now corrupted again) and restore it from your backup.  If you jumped ahead and reconnected without backing up, then you get to do this whole thing all over again starting with Step 1 under "Recovering Your Work". 

Behind the Scenes (IMO)

The reason for the error is because of the way that InfoPath pulls the schema for a WCF web service.  When it connects and pulls down the schema info from the WSDL, it also pulls down all of the schemas for the data types used in the service.  In this case, the namespace of one of those schemas didn't match precisely so it couldn't be found later on, which is logical and expected behavior. However, InfoPath itself ignores that error during the session in which you originally connect to the web service.  It is not until you close InfoPath and then go back in that you get bitten by it.  What would be nice is if InfoPath kicked out the error when you connected to the service rather than laying a trap for you later on.

The truly curious part of all of this is that despite having an invalid schema, you can still open the "corrupt" .xsn file for data entry in InfoPath and it works perfectly.  One would think that something as substantial as a broken schema would kill the form no matter what.

I just ran across this article on MSDN that is a fantastic read.  If you do any work where you manipulate SharePoint objects via code, especially SPSite and SPWeb then you must read this.  The article is outlines many of the gotcha's lurking in the object model that you may not be aware of.  There is also another article that touches on object disposal as well but lists a few other areas to watch for.

If you are seeing performance, memory and stability issues in a SharePoint server that is running custom code then that code should be probably be reviewed while the above articles are fresh in mind.

I'm trying to open a local copy of an InfoPath form that was originally opened from SharePoint.  The actual .xsn file that I've been working with is on my local file system and that is where I'm opening it from.  However, when I open it, I get the dialog below:

Ok.... so ... I know the template on my local machine is the one I want to open and I know that it is different than what is in SharePoint, so I naively click on the "Keep Form Template on Your Computer" button, thinking that it will, you know, keep the one that is on my computer rather than the one in SharePoint.  Silly me.  That option actually opens the original template from SharePoint, which is a "replace" of my local copy in my way of thinking of things.

Now, I realize that a very careful reading of the actual message (which nobody actually does until after the fact) will somewhat point you to the right answer, but having to click "Replace..." in order to keep local changes and "Keep..." to replace local changes is just a little bit counter-intuitive. Maybe a "use this one" button under each option might have been clearer?  Just a thought...

Microsoft has finally released the much awaited Service Pack 1 for SharePoint.  Unfortunately, not all of the links provided on the Microsoft download pages seem to go to the right places.  Here are the actual links that I've found.

SharePoint Service Pack 1 Resource Center

Planning and Deployment Guide (Word Document)

Windows SharePoint Services 3.0 SP1 - Download / List of Fixes / Excel

Microsoft 2007 Office Servers (includes MOSS) SP1 - Download / List of Fixes / Excel

SharePoint Designer SP1 - Download / List of Fixes / Excel (includes Office 2007 SP1)

Revised SP1 SDK for WSS / MOSS / AJAX in SharePoint

System Center Operations Manager 2007 Packs - Announcement / Download

The Excel versions of the fixes are far more useful as they include the actual problem fixed rather than links to hotfixes that you have to sift through.

Update: Fixed the Excel links as Microsoft changed all of them overnight.  They also split out the changes for WSS from the main Excel file for Office Servers.

The intent is for this to be one of those links that you send to your family when they ask: "What is RSS? Why would I care about such a thing?". If you are already familiar enough with RSS to know what it means, then this article is not for you. Move along.  Nothing new to see here. You can go about your business.  These are not the droids you are looking for.

Good, now that they're gone, lets get down to business.

Why do I care about RSS?

Definitions can wait; this is the meat of it. RSS is basically a way to get the news you want from the sources you want in the format you want, when you want it. Think of it as your own personalized Associated Press service. There is even a little bit of dark pleasure involved as you are the editor in this whole process and you can "fire" sources you dislike by unsubscribing to their feed (explained later). Don't lie, I'm sure there are a few columnists in your local paper you'd like to fire and with RSS, you can!

Much more than news

It is true that the most common use for RSS is news feeds, but it can be used for anything that might be of interest to other people. Some sites use it for press releases, some for bug reports, some for articles of interest, others are just for fun and, of course, there are some focused on the latest and greatest deals.

Best of all, you can include sources that most newspapers can't or won't use. Opinions, technical journals, Alumnus organizations, hobbies, etc. Almost anything that you have an interest in has an RSS feed available somewhere for it.

Ok, got it. Now what is it?

RSS stands for Really Simple Syndication and it simply is an agreed upon way for web sites to make anything of interest available to anyone that might be interested in it. These items are available in things called "feeds" that are nothing more than a bunch of news items grouped together.

Think of a feed as something like a newspaper. You "subscribe" to your daily paper, and you "subscribe" to a feed. There's just no messy ink to smear or double-collecting paperboys to deal with. The difference is that a newspaper is actually what is known as an "aggregate feed" meaning that it is a bunch of different topics (news, politics, sports, entertainment) all bundled into one big paper. If all you read is sports, then the rest of the paper just gets in your way. Likewise, on a properly designed site, you can get an aggregate feed of everything, or you can subscribe to just the sports. Try telling your local paper to only deliver the sports section and see what response you get!

FoxNews and CNN are both good examples of this. You can subscribe to only what you are interested in and ignore the rest. Yes, that means you can almost completely filter Britney Spears out of your news.

Hopefully, I have your attention about why you should be interested in RSS. The next steps are the mechanics of actually setting yourself set up to be able to read feeds.

How do I get a started?

First off, you need some software called a reader (a.k.a. Feed Reader, RSS Reader). This software is available in two formats: online and desktop application. The largest online reader is Google Reader and it happens to be free. The interface is a little strange, but it works for a lot of people.

There are several free desktop reader applications out there as well, such as FeedReader and SharpReader, but I strongly recommend Omea because it has plenty of features to grow with. Technically, Internet Explorer 7 has a reader built into it as well, but it is so limited that you will probably outgrow it in the next 10 minutes.

The next thing you need is a feed to subscribe to. Think about your interests; What sites do you visit regularly? Where do you get your news from? Go to some of those sites and look for one of the RSS feed icons (  ). Some sites hide the feed link in text in footers and you have to actually search for "RSS", "XML", "feed" or "subscribe" in the page to find the link for it. Annoying, but if it is a site you like, it's worth hunting for.

Clicking on the link or the icon should bring up a page that only has the news items in it, usually with no advertising or even site identification. In some cases, you will bring up a page that almost looks like computer code. Don't worry, this is the actual feed that the reader uses but you won't have to see it in this form again. In other cases, the link is actually a list of feeds available, in which case, click on one of the feeds that interest you. Now go to the address bar of your browser and copy the URL. You will need this in order to tell your reader what to subscribe to.

Next, you need to actually subscribe to the feed. The term subscribe is a bit of a misnomer here in that you don't really subscribe to anything in the traditional sense as that implies that you are having something delivered. Instead, you are telling your reader to keep checking this feed and to let you know when it changes. You don't have to provide any personal information or any money to subscribe, not even your email address. The feed you are subscribed to has almost no information about you.

The actual mechanics of subscribing depend on the reader you have chosen to use, but they all have an option called something like "Add Subscription", "Add feed" or "new feed" or even simply "subscribe", usually found on the File menu. Click that and paste in the URL you copied earlier, accept any defaults listed for the other options and click OK. Don't worry about those other options for now, they aren't too important and the defaults are usually good enough for most people.

Your reader should now load the feed from the site and give you a list of news items from that site that you can pick and choose from to read. This is great, but you don't get much benefit from one feed! Go find more! Be sure to look for RSS feed options on all of the sites that you visit regularly. Subscribe to anything that interests you - you can always unsubscribe later.

Here is where it gets fun: as long as your reader is open, it will periodically check your feeds and update with the latest articles. Depending on the reader, it might also put a little popup on the screen with the latest news or play a little sound. All automatically. You no longer have to try to remember all the sites you were interested in or keep track of changes or anything. If it is new, it will be in your reader waiting for you. If you close your reader, it will simply look for new items the next time you open it.

I WANT MORE CONTROL!!!

Ok, ok, sheesh. All you "Type A" people out there. Fine, you want control? You’ve got it! Remember those options I told you not to worry about when you subscribed to the feed? Take another look at them (in most readers, right-click on the feed and click on "properties"). The main one that most people change is the update frequency. Most feeds are ok with the default, which is usually 8 hours, but some feeds (like FoxNews and CNN) update very regularly. Change that value to 1 hour to get frequent updates and satisfy your inner news junkie. Odds are that you can also rename the feed to something more meaningful than the default name of the feed. Some readers offer dozens of properties that you can fiddle with.

Ok, you got me hooked but what if I want to change readers?

Ah, but you don't want to lose all those feeds you set up, right? Fear not! Nearly every reader on the planet has an Import and Export feature that supports OPML. What is OPML? You don't really care, other than to know it is an agreed upon way of listing all the feeds you have subscribed to. You Export your feeds as OPML from your current reader. Then Import it into your new one. Voila! You might have to go mark everything as read again because the new reader doesn't know where you left off reading, but that's about it.

What reader do you use, personally?

Omea. I find it easy enough to get started with and it has plenty of features so that when I find myself thinking: "If only I could…", odds are good that Omea already supports whatever I had in mind. It was just in there waiting for me to realize I needed that feature :) With the 158 feeds that I watch, I end up needing a lot of features that I hadn't imagined needing when I first started using RSS.

And, in conclusion...

Hopefully, that is enough to get you into the exciting world of information via RSS. Once you start using it, you will have a hard time going back to reading sites to get your news or even (gasp) picking up a printed paper with its "ancient" 12 hour old news :)

There is a multitude of blogs that discuss how to access SharePoint data from SQL Reporting Services, so why another?  Simply because I had not found one that exposed all of the land mines I seem to hit when doing this.  So, I thought I'd try my hand at creating a detailed guide-map to the mine field.

The Requirements

In order to do this, you must have :

• Visual Studio 2005 (I'm sure this works in 2008 as well, but I haven't tried it yet)
• SQL Reporting Extensions.  These are installed by default when you install SQL Server
• A SharePoint list exposed Anonymously or via Windows Integrated Authentication (more below)
  

Accessing the List

The Report Designer requires that the Data Source either require no authentication or uses Windows Integrated authentication.  Other options are available when defining the Data Source but you will not be able to use them as they are not supported for web services by the designer.

Note: If your SharePoint list requires Windows Authentication then your development machine *must* be in the same domain or a trusted domain as the SharePoint server.  If you are developing on a system that is not in the domain of the SharePoint list you are attempting to access, you will not be able to proceed.  Brutal, but there you have it.

The Steps

Start Visual Studio

Select File -> New Project -> Business Intelligence Projects -> Report Server Project.  Name and save the project.

In Solution explorer, right-click on Shared Data Sources and select Add New Data Source

Make sure you specify the Type as XML and put the proper URL to your server's list.asmx web service page.  This is usually simply http://<server>/<path>/_vti_bin/lists.asmx, replacing <server> with your server name and <path> with the path to the site with the list you are trying to access.

Click the Credentials tab and make sure you set it to Windows Authentication (default) or No Credentials (if your SharePoint site allows anonymous access). 

The other options are not supported by the Designer and will throw an error along the lines of "An error occurred while executing the query..." when you try to fetch the data.

<Query>
    <Method Namespace=http://schemas.microsoft.com/sharepoint/soap/ 
            Name="GetListItems"/>
    <SoapAction>http://schemas.microsoft.com/sharepoint/soap/GetListItems
</SoapAction>
</Query>

From there, click on the Parameters tab enter your parameters.  See the Parameters section below for more information.

Parameters

There are 5 parameters that can be passed: listName, viewName, query, rowLimit and queryOptions and yes, they must be this exact case.  The catch here is that if you define all those parameters you will get data in the Data view, but then the Preview will fail with a multitude of messages, usually along the lines of "The Value expression for the parameter ... contains an error ... ".  To get around this, define only the parameters you are actually passing values for. 

listName

This tells the web service where to get the data from and it is the only required parameter.  You can give it either a list name or a Guid.  If you are unsure how to get the Guid, fire up Stramit CAML Viewer and browse to the list or simply click Settings->List Settings while viewing the list.  The list Guid will be URL encoded in the querystring after 'List=".  You can quickly decode it here.

viewName

The viewName tells the web service what view of listName to query in order to pull back data.  This is not required but strongly recommended because the Report Designer mangles the query parameter with severely limits your options for filtering data from the designer side of this process.  This is also an extremely picky parameter and I have yet to be able to get it to work consistently with a actual name of a view and have had to always use a Guid.

Note: If you do not specify a viewName, it will use whatever view is defined as the default for the list as the filter/sort for the data.  This is usually the All Items view and will likely include way more data than you want.

query

Do not use this parameter.  It is extremely useful for people calling the web service from code but does not work with the report designer.  I suspect that designer does some extra encoding of the CAML that this parameter normally accepts which confuses the web service to no end.  If someone finds a way to actually use this parameter from designer, please let me know!

rowLimit

The number of items to return.  SharePoint defaults to 100 so if you need more than this, you will need to include this parameter along with a number exceeding the number of rows you are likely to get.

queryOptions

Do not use this parameter for the same reason as query: it gets improperly encoded by the report designer.

Click OK and then try to get your list of fields by clicking the Refresh Fields icon ( ) in the data view.  A small + should appear next to your report name.  Click on that to see all the fields it found.  If you don't see all the fields you were expecting, be sure to read the tip in the Annoyances section at the end of this posting.

Last step - get some data by clicking the Run icon ( ) on the Data tab.  It should pop up a dialog with the parameters you defined earlier.  Make sure all the parameters and values are there that you expect and click OK.

That's pretty much it.  I do have some general thoughts on the whole process that I've tacked on below.  Hopefully, this covers most of the quirks and oddities associated with this process.

General Troubleshooting

I cannot recommend Fiddler highly enough.  With this running on the dev machine you can easily see everything that is going on in the actual SOAP calls that are responsible for those vague errors that the designer throws out.  (click to see details)

Guid's versus Names

Ok, so do I reference the list using the Guid or name?  There isn't an easy answer here as this is the classic catch 22.  The Guid is the ID of the item regardless of the name and is the natural thing for developers to want to use.  Unfortunately, if you are in an environment where code is migrated from a Dev farm through test/qa and then to Production, that Guid will change in each environment.  The Name is much friendlier and works across environments, but names have a tendency to change over time which will break your report.  Choose what works best in your environment.

A Word About Formatting

SQL Reports has no clue what to do with many of the columns used in SharePoint, so you might end up having to write some code to handle these.  The first you will probably see of this are the SharePoint fields that contain lookup values because these will show up on your report as something like "245#;My real name".  Pretty nasty.

What you can do is add the snippet of code below to the Code section of the report.  To get there choose the Layout view, then Click on Report -> Report Properties from the main menu.  Click on the Code tab and paste the code below in the window

function GetNameFromSP(pFullID as string) as string
  dim strRet as string
  dim iPos as integer

  if pFullID = nothing then return ""
  if pFullID = "" then return ""
  iPos = Instr(pFullID, ";")
  if iPos < 1 then return pFullID

  return Mid(pFullID, iPos +2)
end function

Then right-click on the field in the report that you want to fix this with and select Expression.  In the Expression Builder window, set it to the following:

=Code.GetNameFromSP(<your field reference>)

It is possible to use a .Net assembly for this function as well, but that is way beyond the scope of this article.  Besides, this method doesn't require any special installation steps on the target server.  If you are creating dozens of reports where you need this behavior or others like it, then it makes sense to look into the assembly approach.

A Word About Sorting

Odds are that the second place that you will hit the formatting snag mentioned above is when attempting to sort the report by one of the fields containing such values as it will sort by the ID part of the value string and not the name.  The easy fix is to use the same Expression as above in the Sorting and Grouping section of the report, which now allows you to sort on the real name.

Annoyances About the Report Designer in Visual Studio

Overall, working with the Report Designer in Visual Studio goes pretty good, but there are some soggy areas that you are bound to step in eventually.  I'm pretty sure these are related to working with either web services in general as a data source, or SharePoint web services specifically as I'm not seeing a lot of people reporting this problem over the net.

Vanishing Parameters

For reasons known only to designer itself, it will occasionally completely delete your list of parameters.  If you suddenly start getting errors or the wrong data and haven't changed anything substantial, make sure your parameters are still defined.  Just make sure you have them written down somewhere where you can refer to them in order to enter them again.  I guarantee you will hit this one at least once.

Erroneous Errors

Sometimes something gets stuck in memory and designer will keep throwing an error when you try to get data or preview what should be a good data call.  Nine times out of ten, just closing the report and re-opening it will take care of this.  It's very easy to lose an hour or more chasing a problem that isn't really there from this.

Now you have data, Now you don't

Fetching the data / previewing the report will work occasionally fail one attempt, then work perfectly the next with *no* changes in between.  This is a minor irritation and can usually be fixed by closing and re-opening the report.  After a while, you get used to trying everything twice.  If it fails on the second attempt, you probably really have an error.

Missing Columns

When you build the list of columns available for the report in Designer, it takes only the data in the first row of data returned.  If any of those columns are null, it won't include the column.  Make sure all the vital columns have data when you create the report and you should be fine, even if that means manually editing them for a short time to put temporary data in.  Update: Maria has offered a solution to this.  I'm not able to try it at this moment but it looks promising - thanks Maria!

Note: if you know of fixes to any of the above, please, please post it in the comments!

Some Helpful Links

• Accessing SharePoint List Items with SQL Server 2005 Reporting Services very good checklist approach to this topic
• How to: Publish a Report to a SharePoint Library from Report Designer
• Fiddler - Good for snooping on web service requests to find the root causes of those errors
• Stramit CAML viewer
• Reporting Services: Using XML and Web Service Data Sources

It looks like Microsoft has finally put together the first installment of a true Resource Center focused on SharePoint.  It has direct links to a lot of existing content that was previously scattered all over MSDN, some of which you might not have seen before.

http://msdn2.microsoft.com/en-us/sharepoint/bb964529.aspx

It is still kind of light on content but we can hope that Microsoft will continue the effort and turn this into a key launch point for all things SharePoint related.

I started using Windows Live Writer late last week to author my blog entries and have to say that I am very impressed.  In fact, the last 3 posts on this blog were all done with it.  Once configured, it is fast, extremely easy to use and focuses solely on the task of editing and posting blog entries.  This means that there is no menu/UI clutter from a bunch of bloat (yet) so it is pretty easy to find what you are looking for.

Some of the cool things I've found so far:

• Save drafts locally
• Save drafts on the blog site as an unpublished post
• Publish blog entries to the blog site (kind of required!)
• Web Preview mode that shows the post using styles and layout from your actual blog site
• Edit and post entries to different blogs from the same editor
• Auto-upload embedded images (if the site supports it)
• Insert images from several sites (I use Flickr and SmugMug but there is a Community Server plug-in as well)
• Ability to scale images using the thumbnails created by the Image Hosting site

To make blogging even easier, I've discovered a few related goodies that work well with pretty much any blog editor.

• An add-in for SnagIt that uploads my screen captures to Flickr right from the SnagIt editor
• A "Send To ..." utility for both Flickr and SmugMug that will upload an image file from the right-click menu

Wonderfulness (?) aside, this is still a "dot OH!" product from Microsoft so there are a few small bugs yet to be worked out as well as the occasional crash but it is a strong enough product that I can easily overlook those. I've been spoiled now and can't see myself ever going back to Word or OneNote to compose my blog posts.

It is great when you are in a field where you can learn at least one new thing every day.  For example, I've been using generics since they became available in .Net 2.0 and yet, somehow, this was the first time I've seen this particular way to use one of them:

This creates a strongly-typed dictionary object and that uses a string as the key and an object as a value.  Super simple and wonderfully powerful yet I had missed that in all of my readings and experimentation.  This just made my day!

Whenever you customize the default list forms (NewForm.aspx, Dispform.aspx, or EditForm.aspx) in SharePoint designer, never, ever, under penalty of torture using Ed Wood movies, ever, I mean ever, delete the default ListFormWebPart that is on those pages.  Doing this will subtly corrupt how your list is defined in SharePoint and can cause you all sorts of grief.

The most minor problem I've seen is that you lose the ability to specify the Supporting Files for the list.  Oh sure, it will look like you can set them and it will even save and refresh properly in Designer.  However, SharePoint will simply ignore that and go right along showing the default files instead.

The bigger problem is that deleting the ListFormWebPart from the NewForm.aspx page can effectively disconnect the "New" option on the list toolbar resulting in the ever annoying "Invalid page URL" dialog box when anyone clicks on it.  This is a known issue and the only way to fix it is to delete and recreate the list.  Not Fun.

Instead, save yourself some grief when editing these pages and just leave those web parts on there and add a new DataFormWebPart above or below it and customize that to your liking. 

Note: make sure that you insert the new web part into the existing WebPartZone or else you will lose the 'Edit Page' option for that page on the Site Actions menu.

Once you have the customizations you want in place, you will need to hide (not delete!) the original ListFormWebPart.  To do this in Designer, simply change the IsVisible element in the WebPart XML to 'false'

Alternatively, you can hide it using a browser as well.  Simply browse the page and edit it, either by using SiteActions -> Edit Page or by adding "&PageView=Shared&toolpaneview=2" to the querystring in the browser.

Then edit the web part properties for the original ListFormWebPart and hide it

This keeps the original web part on the page which keeps SharePoint happy.  Your users only see the customized list view that you want them to see, which keeps everyone else happy.

I've been using SnagIt for years and absolutely love it.  Recently, I needed to grab a picture of menus but also needed to apply some effects to the unimportant areas so as to draw more attention to the menus themselves.  I stumbled a bit with the freehand selection tool, largely because I can't draw a straight line for diddly.  The rectangular selector was *so* close to what I wanted but it kept bringing in parts of the image that I didn't want to highlight.  Out of curiosity, I tried the old Shift trick and it worked exactly like I'd hoped!

What is the Shift Trick?

• Use the Selection tool of your choice and make the first selection
• Hold Shift and make another selection such that it partially overlaps with the first. 
• SnagIt will merge the two selections
• repeat as needed

This allows for some really odd selection shapes but is quite handy when you need to outline complex areas.  In this picture, I was able to select just the menus and then dim and blur the background.

(and for the record, yes, I could have applied the Torn Edge effect to the selected area which resulted in torn edges on each of the menus.  Interesting, but lost clarity)

Just for fun, I wanted to see what I could do with this - pretty neat, actually.

A few days ago, my journey through the vast wasteland of dysfunctional RSS readers took an unexpected turn for the better.  After my most recent experiment (FeedReader) ate its own database, I decided to take a look at one that I have been seeing a lot of in my blog stats - JetBrains Omea Reader.  So far, I really like what I see.  The tool is visually appealing and is the first Reader I've tried in years that didn't leave me saying: "Oh, how I wish SharpReader was being updated..."

It has everything I expect from an RSS Reader and does most of it pretty well and pretty darned fast.  One of the nicest features I've found is the ability to create a View based on search criteria, allowing you to keep an eye on any hot items/keywords that you might be interested in, automatically.  Now I can easily keep tabs on how Visual Studio is going to take over World of Warcraft add-in development.

As a bonus, Omea also has a good Usenet News reader built into it.  This is something I had pretty much given up on since Anawave Gravity (the greatest Usenet reader of all time) was killed off.

I have tried quite a few RSS readers over the past few years but none quite fit what I was looking for.  Here are a few of them:

SharpReader - My personal favorite because of its speed and the tight focus on the tasks related to RSS but it has not been updated in quite some time.  It also suffers from the rather annoying habit of corrupting its own database every few months or so.  It recovers from this but it does require that I go through and mark thousands of entries as read.

Google Reader - fast but far too few options for managing large numbers of feeds.  Nice if you only have a few feeds or if you need access to feeds from multiple computers that you might not have control over (i.e. kiosk/walkups/guest machines).  The UI does take a little bit to get used to.

NewsGator - As a consultant, I rarely have Outlook open as most of my clients either use Notes or don't allow consultants to have accounts on their Exchange servers.  As such, I really don't like being that tightly tied to an app I never use (Outlook).  It also had WAY too few features for me to use to manage the number of feeds that I have.  I have read that it does work very well for consultants who travel a great deal because it caches feeds so that they can then be read while disconnected, like while on a plane.  My only travel is the drive to work and I'm pretty sure the other drivers would get a little upset if I was reading news feeds during that time.

FeedReader - good generic reader but pretty shallow on the features.  It lasted several months but then terminally corrupted its database  - no recovery whatsoever.

Omea - This is day three for this reader so only time will tell.  So far, it is very good.

After searching the net, it appears that the generic "RENDER FAILED" message (below) appears when customizing certain views for a multitude of reasons, each with its own unique combination factors and its own solution.  So, here is one more set of parameters / solution to add to the chorus.

I had a view that was grouping on a single field and also had to provide the AVERAGE of a number field.  When trying this with the default Group By settings, I would get the <!-- #RENDER FAILED --> error message.

The fix was obscure but simple.  Change the Group By options to Expanded and the problem was solved.

There has been a lot of discussion over software bloat over the years (the latest entry at: http://www.codinghorror.com/blog/archives/000973.html)  The question is not whether it is bloated or not, it is.  The question is, how did it get that way?

The biggest reason software gets bigger over the years is because companies keep adding features (duh!).  Yet, people condemning "bloat" in all forms seem to think that companies and marketing departments exist in a vacuum and just pull new features out of the amazingly thin air of said vacuum.  The truth is that most of these features are requested by end-users and they are adding in order to keep the customer base happy.  A pretty important point in a market economy.

Once software is released in the wild, it tends to take on a life that the original developers never dreamed of.  People come up with all sorts of creative ways to use it and, naturally, hit limitations that they think should be removed.  With each broadening of the software's focus comes the infinite loop of new uses followed by further broadening.  Over time, you get products like Word and Excel which do pretty much everything but make mounds and mounds of Julienne french fries. 

Not all products should have all features and the business should exercise restraint on many of the features that are added.  You might want to add that as a standard question in your feature review: Should WordSheetViewer Deluxe Pro XXL be able to broast chicken while still fitting into a pocket and alleviating lower back pain?

It's hard to say "No" to a paying customer but perhaps the business should look on those situations as opportunities.  Each of those requests is a customer telling you that they have a need, and that your product is very close to filling it.  They are also telling you that you have achieved a modicum of trust in the relationship as well, otherwise they wouldn't talk to you at all.  What is the feasibility of some of those requests being rolled up into stand-alone products?  Even niche products have a market.  The benefit here is that development time would likely be small since you already have a substantial amount of the code written.  Support costs would also be reduced because the new product is based on a (hopefully) proven code base.

Where do we go from here?

I think that the add-in model is the way to go but instead of installing everything but the kitchen sink as part of the base product, include only the barest minimum as the core.  Then make all of the other features available as free or easily accessible add-ins.  That way, people who only use 50% of the functionality will only need to install 50% of the features.

Most importantly, make the API for your App and Add-ins detailed and readily available so that third parties can easily extend the product.  You might just gain a loyal following from people who would have been your competition's testimonials.

I have been a user of Gmail for years and still love it as much today as I did back when I was able to first sign in.  That's why I was pleasantly surprised when I came up with yet another way to use it.

I deal with many servers that cross numerous system boundaries and I find myself occasionally having to copy textual information from one server to another and, in some configurations,  mapped drives and copy-paste simply aren't available.  This leaves the old stand-by of manually re-typing the information or getting a server support monkey involved and spending an hour talking it through a 3 minute change.  However, almost all of these systems have internet access, which is where I my idea came in.

The problem with commonly available internet applications is that there is no quick, easy and reasonably secure way to put data onto a public server on the internet that can be easily managed from multiple locations.  Those that are available involve setting up some form of CMS or FTP, and FTP is almost always disabled or blocked at the firewall. Then my idea struck - use the drafts feature of Gmail to move data across systems.

How it works

• Sign into my Gmail account on the source machine and the destination machine using https://mail.google.com/
• Create a new message on the Source machine and paste the text to be copied into the message body
• Save the draft
• I switch over to the destination machine and open  the draft
• Copy the text and do whatever I need to with it
• On rare occasions, I've also used the attached files option of the draft to move files between machines.

Advantages

• Easily, quickly and securely copy data across systems without risking typing errors
• The draft is shared between computers so you can make changes to either copy and have that change immediately available on the other computer with a simple refresh of the page
• Drafts can be saved for quite a while or even forwarded on to someone else so that they can see what you had to change.  It's always nice to have changes saved in something a little more permanent than a clipboard buffer.  (Yes, I know, in large corporations, this is handled by a change control process.  This is for the 90% of us that don't work in that type of environment)

Ok, so how does this even remotely touch on SharePoint?  One word: Web.config .  The changes that often need to be made in the SharePoint Web.Config tend to be rather difficult to type without error.  Things like GUIDs and Keys abound and are amazingly annoying to type.  This way, those items can be copied intact and I won't have to spend hours troubleshooting a fat-fingered GUID.

Obviously, this will not always work due to firewall, proxy, policy and security restrictions but it has worked well the few times I've needed it.  Also, be aware that it likely a violation of company policy to host confidential data on a public server (even temporarily) so be careful what you use this for.