Cascading drop-down lists are a nice trick in a form — where the value from one DDL determines the given values in the next one, which winnow down the next one, and so on. In regular ASP.NET programming you do this by passing the selectedvalue or selectedindex of the first DDL as a parameter to the next DDL.

It’s not too difficult to do this in InfoPath, but we currently have a pretty extensive SharePoint document library project where this would be handy. So putting this feature in place there is on my current task list. As I was trying to gather resources for it, I ran across this helpful post on Datacogs.

Example of a cascading ddl


Since MOSS includes InfoPath Forms Services, it’s really nice to embed InfoPath forms directly in the web page and have SharePoint remain the interface — and so the user doesn’t have to own the IP desktop client. And it’s really pretty simple to plug the form into a MOSS forms library to collect the submitted results of the forms. But for something a bit more complicated, it would be nice to keep the form embedded but submit directly to a DATABASE. Again, this isn’t very difficult if you’re using a form template within the IP client, but if you’re embedding the form using Forms Services you *have* to access SQL by way of a web service.

Here’s a great posting from MSDN on just how to do it:

A new blog…

April 29, 2008

Interviewer: Why are you moving all your SharePoint-related postings to this new blog?

Neal: Well, it seemed like between posts of SharePoint tips and stuff from work, alongside posts of our daughter swimming in the pool at age 2 and political cartoons, it just seemed smart to separate them a bit.

Interviewer: Okay, I can understand that. But WHY on earth would you choose WordPress for this and not just host one on one of your SharePoint servers??

Neal: Yeah, I knew you were going to ask this. The blog feature in MOSS 2007 is okay, but not nearly as nice or full-featured as WordPress is. And, it just so happens that another division within the Union is rolling out some WordPress stuff and I had to get the server configured over the last few days. Maybe I’ll move it over there eventually, but this seemed as good a place as any to have an open, fully-accessible, rich repository of things I’ve come across and learned. It’s probably more for my own good than it is for everyone else’s!

Interviewer: Well, thanks for answering our very tough questions, Neal. It’s a stunning and remarkable job you’re doing, and we’re all in awe. Okay maybe not.

Custom Item Actions in MOSS

January 16, 2008

So the next trick is to learn how to customize the menu that pops up next to an item in a list or library. I am used to writing these within BDC Meta Man — to send a parameter to Google Maps or to compose an email message — but I want to be able to hide certain default actions, create new ones, or change the way they appear.

So I found this post on MSDNER which links back to MSDN “Custom Action Definitions” and the “Custom Action Element“. I knew this would all be in XML, so let’s see how helpful SPD2007 can be.

We had finally installed (and enforced the use of) our SSL certificate on our main production MOSS box, but I couldn’t figure out why the search was then completely down. It wouldn’t return *any* results, which was more than a bit frustrating. I had even made sure that in the Content Source I explicitly pointed it to https://servername/

So what can you do?

Thanks to this post I happened to find, I neeed to tell the search crawler to ignore certificate warnings — this is because as it searched on itself, it wasn’t using the FQDN that was written on the certificate, only the servername itself … which would understandably cause a certificate warning message. Mark Andrew’s post reads:

Try Application management/manage search service and under farm level search settings there is a checkbox to ignore SSL certificate name warnings

Once again … a key feature, sort of buried away down in the bowels of MOSS. But at least the option is there:


I had been looking for a way to strip down the regular “Advanced Search” web part, but also to restrict its scope without the user having to do anything. Found this post from Dattard who — of all things — uses the Content Editor web part to drop in some custom code. I’ll have to remember that web part for future tricks.

Anyway, all that’s really involved is setting up your own custom scope, grabbing the right ID that references that scope, and putting the right inputs in your content editor web part. Works really well, and doesn’t have too many options.

I wanted a stripped-down search utility since I think one of the main complaints about MOSS/WSS is the “overwhelming” user experience: getting lost, confused, unsure what to click on, etc.

After a few weeks of trying every fix known to humankind, I could not repair the once-working search engine on one of our MOSS production servers. Re-installed the Adobe iFilter a few times, tried registry fixes and recrawling the content over and over again. Turns out that the Adobe iFilter .dll for 64-bit doesn’t work too happily, despite Adobe’s best efforts.

And I then discover the wonderful Foxit iFilter for PDF documents:

Cheap and solved the problem perfectly. Thanks to this post from Filter Central most of all.