This past week I have been working with a DataView that needed to filter a list by the title of the PublishingPage containing the DataView web part.  In order to provide this functionality, I created a straight-forward custom parameter:

public class PageTitleParameter : System.Web.UI.WebControls.Parameter
{
    protected override object Evaluate(System.Web.HttpContext context, System.Web.UI.Control control)
    {
        SPListItem listItem = SPContext.Current.ListItem;

        if (listItem != null)
        {
            try
            {
                return listItem.Title;
            }
            catch
            {
                return string.Empty;
            }
        }

        return string.Empty;
    }
}

Creating custom Parameters has been covered elsewhere, so I won’t bother going into that, it works pretty much the same in SharePoint as in any ASP.NET application.  Where things get different, is after you export your shiny-new DataView web part to SharePoint.  If your experience is anything like mine, when you add your web part to a page instead of seeing your rendered DataView, you see “Parsing Error:  Object reference not set to an instance of an object”.

So what went wrong?  If you look carefully at the parser error, you will likely see that the TagPrefix that you setup when you registered your custom parameter in SharePoint Designer has been replaced with something like “cc3”, “cc4”, etc.  In order to fix this, instead of exporting the web part from SPD straight into SharePoint, save it to a file first.  Open the .webpart file that you saved and add your @Register directive for “cc3” or “cc4” or whatever your custom parameter’s TagPrefix happened to become.  You can now go into the Web Part Gallery and upload your web part. 

Good luck!

For my own development efforts, I use Axosoft’s OnTime product which is free for a single user (yeah!).  I have a single SSL for Axosoft and for my WSS Team Site installation, so I needed for both to coexist peacefully in a single virtual server.  Out of the box Axosoft was throwing several errors, at which point I came across this link from Microsoft: 

How to enable an ASP.Net application to run on a SharePoint virtual server

After completing the steps in the article OnTime began working flawlessly!  Nice!

So you have probably used RDP about 5.1 gajillion times, but then you learn something new that shakes your foundation. Well that is what happened to me this past week when I learned 2 new things with RDP, and I am not ashamed to admit it either! Here goes nothing:

What we are looking at here are the command line parameters for MSTSC.EXE, our beloved RDP client. The 2 that jumped out to me this week were /span and /console. /span allows you to have a fullscreen RDP session that spans multiple monitors (difficult one for a screen shot, sorry folks!). The other, /console, allows you to connect to the console session (session 0) on the system, which as you can note above is only possible for Server 2003.

Hmm.. Alright, I confess, maybe it’s 3 things I picked up on this week. Last, but not least (actually probably my favorite for day-to-day), is that there was a Remote Desktops MMC plug-in that snuck into Windows Server 2003. Have a look:

What we have here is the ability to define various RDP server connections, and the connections will actually appear in the view pane. You can then click between the various servers and have it appear in the view pane. This makes it very simple to switch between multiple RDP sessions.

In order to get the Remote Desktops MMC you need to install the ADMINPAK.MSI from the SYSTEM32 folder of a Windows Server 2003.