I've been saying to get the filename from Windows Desktop Search queries by combining the System.ItemFolderPathDisplay and System.ItemNameDisplay. This worked fine on my system, but I didn't realize that it might not work if you hide file extensions in Explorer. Apparently, ItemNameDisplay returns the filename minus the extension in this case (or at least I found this to be the case on Vista). The better choice is to use System.FileName. This returns the filename with extension regardless. You still don't get the path though -- for that, continue to use ItemFolderPathDisplay. So how do you combine them? Definitely don't just concatenate the strings.
In general, you should never just concatenate a folder name and filename. Then you need to worry about whether one string ends with a slash, the other begins with a slash, or if both have it. Plus, volume roots (C:\) are weird because of the colon. The better route is to use System.IO.Path.Combine(folderName, fileName). This beautiful little method returns a new string with a complete path. Just what you need!
On a final note, know that you can get the full path to an item using System.ItemUrl. Path.Combine won't help if the search item is a mail message, contact, or a file on a network share. Anything other than a normal file on your local filesystem will look very different. If you use System.ItemUrl, you get the entire path -- including protocol. This would give you a local file URL of file://c:/folder/name.ext. I don't like to use ItemUrl since many API calls won't work with filenames like that. On the other hand, if your only need is to open a file, ItemUrl is the absolute easiest. Just call Shell.Execute on the value of System.ItemUrl, and you can open just about anything in the search index. See, the cool thing is that all those protocols have registered protocol handlers. They will take care of finding the underlying object (contact, mail message, web address) and invoking the right application.
Bottom line: if you are presenting the user with the file path, or using it in various API calls, combine the System.ItemFolderPathDisplay and System.FileName properties. If you are opening the object, go for System.ItemUrl.
Am I missing anything? Finding info on WDS seems to be challenging. If there's a better (or more standard) way, feel free to let me know! There is a good list of categorized properties to be found here.
PS - I've seen some places mention using System.ItemPathDisplay to retrieve the complete file path. This works great for most files, but if you index files on a network share, you'll get wonderful values like "\\{s-1-5-21-3609757821-318721349-3049227614-1006}\n\documents\presentations\wds\windows desktop search.pptx" which won't really help you very much if you want to open the file or show the name to the user! It seems to be fine for other stores though (MAPI, FILE, etc.).