Fear and Loathing

There was a really interesting thread (that I'm sure isn't finished) in the newsgroups around .txt files and their somewhat odd behaviour opening in IE and not the associated program (Notepad for most of us peons). Here's the original message that sparked this thread:

What is the story behind the .txt files being overlooked when it comes to document libraries?  Should all .txt files be converted to .doc files?  It's a pain having to open them into IE, then 'Save as' to the desktop, open them with notepad, edit them, save them back to the desktop, then re-upload them to the document library.  There is no version history with that method either. Why can't we open .txt files to an editor from within the document library?  Is there some way in SharePoint to change the association for .txt files from IE to some editor?

I didn't think it had anything to do with SharePoint or document libraries at all. File associations are an Internet Explorer/Windows Explorer thing, not SharePoint. True, SharePoint does do a little extra (through some cleverly embedded Javascript and some obscure onclick tags) but for the most part, it just does whatever any other .txt file does when launched from IE. It opens it in IE.

I did some digging and found a few things that may help:

Microsoft KB Article:
http://support.microsoft.com/kb/q185373/

Lengthy Article on File Associations (and mentiones IE and Text Files):
http://antivirus.about.com/od/windowsbasics/l/blfileassoc.htm

Contains "fixes" for file associations and includes one for text files:
http://www.dougknox.com/xp/file_assoc.htm

The last link *might* fix the opening of .txt files (I tried it but just seems to repair any .txt file association problem) but the other problem is that you can't get the Office like integration with Notepad for example. It just isn't there so you're never going to see Notepad have a task pane and Check in options like Word does. Nor are you going to see too many non-MSOffice products have this feature either. The entire Microsoft suite of products is something that continues to alter each other in behaviour and how say a Word document has new "features" when you open it from a SharePoint site rather than a hard drive.

Some interesting stuff indeed. I did some digging and found a few more things.

Okay, the Javascript I mentioned is the DispDocItemEx Javascript function (found in OWS.JS). If you look at how a SharePoint doclib displays it's files, it wraps a "<a href>" tag and assigns an onclick event with this for a Word document:

<a href="document.doc" onclick="DispDocItemEx(this,'FALSE','FALSE','TRUE','SharePoint.OpenDocuments.2')">Word Document</a>

Okay, fair enough. How about a text file?

<a href="document.txt" onclick="DispDocItemEx(this,'FALSE','FALSE','FALSE','')">Text File</a>

Hmmm. Different parameters and there's no last parameter. Looking at OWS.JS we find this:

function DispDocItemEx(ele, fTransformServiceOn, fShouldTransformExtension, fTransformHandleUrl, strProgId)

So the ProgId (the program to launch the file?) is something called SharePoint.OpenDocuments.2. Smells like COM or something but looking at the DispDocItemEx Javascript we find a call to a function StsOpenEnsureEx. Looking at this we find a LOT of code commented out! The commented out code contains this:

//@cc_on
//@if (@_jscript_version >= 5)
//@            try
//@            {
//@                v_stsOpenDoc = new ActiveXObject(szProgId);
//@                v_strStsOpenDoc = szProgId;
//@            } catch(e)
//@            {
//@                v_stsOpenDoc = null;
//@                v_strStsOpenDoc = null;
//@            };
//@else
//@end

Now my javascript is pretty rusty and this looks like a mish-mash of C# and various scripting languages but "new ActiveXObject(szProgId)" I recognize. Then I thought "okay, there's that KB article mentioned which is about downloading text files through an ActiveX object". Any connection?

So, walk with me on this one, suppose the commented out code invokes ActiveX on the client (IE) and launches the appropriate client side program? Is this the missing link to get .txt files to launch with the association they have on the desktop?

Also another thought is the order that .txt files are listed with their desktop associations. I looked at a few setups and default is that IE is first in the list, followed by others with Notepad mixed in there. Perhaps you can a) move Notepad higher up in the Association list chain [if there is such a thing] or b) delete IE as an association with .txt files altogether [who wants to open text files with IE]? Anyways, a few ideas around this mystery.

Unfortunately I don't have the resources to dig into this so hopefully someone out there will confirm or deny this and share with the rest of the class. Any takers or am I completely off my rocker here?

Just a quickie for those that are feeling the global warming in our fine city (-30 to +6 in a few days, that's Calgary for you). In Calgary we currently have 6, count them, 6 MVPS. Here's the rundown:

Blake McNeill (Windows Security)
Jason Dunn (Mobile Devices)
Daniel Mitchell (Exchange)
Daniel Carbajal (C#)
Bil Simser (SharePoint Portal Server)
John Bristowe (ASP.NET)

The last guy is a bit shady and I suspect really only knows about Microsoft Bob but I've included him here for completeness (actually he's the Microsoft Regional Director around here and a great guy but I have to get my digs in).

As I get ready to introduce Visual Studio 2005, .NET 2.0 and a raft of other things to our organization (no easy feat), I'm spending more time focusing on the Web Parts Framework that .NET 2.0 has to offer and how it will empower your web developers with things that were done with gobs of coding in the past. Personalization, customization, and all that good stuff that we're used to in SharePoint can now be put in the hands of any ASP.NET developer. It's really powerful stuff and will help get us to a common framwork no matter what the application content is.

Nikhil Kothari, a development lead on the ASP.NET team at Micrsoft, has an excellent post here on his blog about connectiing Web Parts together and provides a nice sample that hooks up a calendar with it's entries. No SharePoint needed (but the 20 .NET framework is). Also check out his article for an Introduction to Web Parts here on MSDN which gets non-SharePoint developers feet wet with what's coming and how this is going to change the way you think (and develop) ASP.NET apps.

As we SharePoint developers know (and those using SharePoint), Web Parts are the cat's meow when it comes to cutomization and personalization so armed with that, you can really empower your web-based application users with powerful capabilities for next to nothing in development.

So here I was trying to figure out some ways to manage mutiple parts of documents stored in SharePoint and Word, IE, SharePoint, or some combination of the above are all behaving badly and causing me (and from the newsgroups, others) grief. After many cokes and munchies, I've updated the blog with some ideas around how to do this without shooting yourself in the head (and the gotchas I went through to discover this).

The problem is to store say 10 (or some number) of different documents (potentially from different document libraries) in SharePoint and:

1. Allow users to edit the various individual documents AND (here's the kicker)
2. Send out a compilation of all of these documents into a single one AND (now it gets ever better kids)
3. Track the changes made by someone external to document AND (final nail in the coffin)
4. Merge the changes back into SharePoint (from say a copy of the document you sent out that came back as an email attachement).

Okay, besides having lots of ANDs there are a few challenges here. Some are easy to solve, and some that are driving me batty.

Problem #1. Store a number of different documents in the system, allow people to edit them, track changes, all that good stuff. Easy sleazy. Document library + Document + Word 2003 = Bob's your uncle. Boy, if only my job was this easy.

Problem #2. Create a compilation of these documents into a single document and send them to someone for editing. Okay, not too much of a biggie. Lots of ways to create a compound document. This KB Article says to not useWord's Master Document feature with SharePoint. They're just not compatible. The work-around is to use the RD or INCLUDETEXT fields. There's a great article by Dian Chapman (I have a lot of respect for anyone who puts Bill Gates on their resume as a reference) here on how to use this. It took me a few minutes to realize the RD field (reference document) wasn't going to pull in my sub-documents but rather be a facility to create an uber table of contents across all of them. The INCLUDETEXT field lets you specify a URL to a document and will basically pull the contents in with some nice options (formatting is always a problem with lots of different sources). Since all documents in SharePoint are URL addressable, I was all set. It creates what looks like to a user a single document in a document library. Click on it and it launches Word with all your documents brought together. Nice. Great. Bundling it to send out is a bit of challenge since this is compound document is just directives to include the other documents. The actual document will try to retrieve the others, which is great if you have access to them but we need to create a real 500 page (or however big it is) document to send to someone externally. In any case, the document can be exported or something to create this.

Like I said, this compound document isn't a document at all. It's just that original document you create with the INCLUDETEXT fields to go retrieve each sub-document. While it looks like a single document, it isn't but you can change this single document as if you're editing any regular document in a document library (no special codes or anything). Oh wait. Gotcha. Here's an image showing the setup:

So I open the compound document (indicated by A above), go down to page 50 (which happens to really be document B in Document Library 2), and merrily change the contents. Click File | Save and the typical Save dialog comes up (SharePoint aware). Any meta data on the document library will popup so I can enter this. Fantastic. However since the compound document isn't a copy of all my sub-documents, the changes must have been made in Document Library 2 right? Nope. Open the compound document again. Yup, the changes are there. Check the sub-document. Nothing. Flush the IE cache. Nope. 

In the picture above, the compound document is A which looks something like this:

{INCLUDETEXT "http://servername/sites/sitename/document%20library%201/doc1.doc" \* MERGEFORMAT}
{INCLUDETEXT "http://servername/sites/sitename/document%20library%202/doc2.doc" \* MERGEFORMAT}

One of the sub-documents is B which is what is being edited in the scenario above. However the B document doesn't get updated. For those that are still awake and keeping score:

• Edit A (the compound document). B (one of the individual documents) is not updated.
• Edit B. A shows the changes.

Remember, A is just 2 fields pointing to other documents. There's really nothing to edit there. Editing B will show the changes in the compiled document but only after you do a Select All then Update Field (F9). Otherwise, A will continue to show that last time the fields were updated (took me a few coffees to get that straight this morning).

Problem #3: Track the changes made by an external party. A couple of options here as Word has (and has had for awhile) a Track Changes option. You can password protect this option, but it's not hard to get past that. If you really want to secure the contents you need to drop in a Rights Management server and protect the document this way. Note: You'll need to expose your DRM server externally if you send a document out that has the contents protected and there's a whole bunch of things that have to be done with this (end users needing Office 2003, etc.) so it will take more than a click of a button to enable it but it's pretty slick overall once you get the infrastructure and processes in place.

Anyways, without tracking changes (or not trusting if someone can bypass it as the other end) it's not too difficult if you keep a copy of the fully merged document you sent out. Word 2003 has some nice Compare features to show you what's changed no matter what options were enabled, overridden, etc. Again a caveat here is that you actually have to unprotect a document (if it's protected) before you can compare one document with another.

Problem #4: Merge the changes back into the copies of the documents in the document libraries. And here's the rub. If you send the document out as a single (new) merged document, even with the ability to see where the changes happeed, how do you get any changes back into the various bits and pieces that made this thing up in the first place (without having your users jump through hoops editing large numbers of sub-documents individually).

So, bottom line...

1. You can use a compound document with SharePoint however you need to use the RD and/or INCLUDETEXT tags and not the Master Document feature of Word (see KB article above)
2. Do not edit the compound document directly, instead edit it's parts and regenerate/update the compound view.
3. If you have to send a compound document to an external editor, send them the parts and perhaps a read-only copy of the compiled set of documents (like a PDF). You won't be able to merge the compiled document into the individual parts

Clear as mud now?

Note: I keep reading this and parts of it still doesn't make sense, however I do think there might be value in putting together a coherent post/article on "How to Support Compound Documents in SharePoint" or something. Watch for this in a couple of days. We'll just pretend I was having a bad morning.

After watching my refridgerator die a horrible death (along with it's precious cargo [goodbye pork chops!] and the 3 hour cleanup I had afterwards), I needed a diversion. Thanks to Bruce Johnson, I killed a few brain cells and discovered that I was 97% nerdier than everyone else. Okay, so not everyone else, but those that took the test. Nope, no cheating.

 

I'm not sure if I should be happy or sad?

I came across Mads Nissen and his blog about using NAnt with SharePoint. I've been using NAnt for a couple of years now for Continuous Integration and automated builds of .NET projects. While MSBuild promises to come along and do all of what NAnt does (and more), it's awhile off and requires the 2.0 Framework (although there is a MSBuild Compatibility Toolkit) so for now NAnt is a nice substitute.

The idea of adding tasks to NAnt to support SharePoint just gets me all giddy (doesn't take much does it?). Deploying web parts, doing Enterprise deployments of portals or multiple team site creation through a NAnt task sounds great. While SharePoint templates are great, they only address half the solution. You still normally have to go in and setup security (even with custom site definitions) and if there's any special customization to be done (like corporate branding or maybe adding web parts dynamically to sites based on content) then it's usually a day or so of tweaking and changing things, settings up site groups, etc. All could be nicely done by a set of NAnt tasks and even better a nice rollout task for those deployments that go sour and your environment management people want to know how long it will take to undo what you've done.

So if you're a SharePoint developer or someone interested in getting into SharePoint and using NAnt, please check out the GotDotNet Workspace setup by Kris Syverstad and join in the fun. Thanks to Mads for getting me hooked up on this too!

So here I was, wanting to update my personal site, bilsimser.org, and give it some new features (especially after being hounded by a certain someone at work who shall remain nameless...). The problem was that my web host only provided PHP and MySQL based sites. I would prefer a .NET or even SharePoint site but I'm also a cheap-skate and like the rates I get now with my provider. Maintaining a website with lots of static content (like what I had) was so 2004 now and I didn't want to code my own PHP portal or content management system.

I had played with PHP-Nuke a long time ago and read-up on how you can completely change the look and feel to the site with it's theming capabilities. PHP-Nuke had a lot of nice features out-of-the-box that appealed to me like full searching across the site, downloads, links, announcements, etc. Hmmm, sounds very much like SharePoint. All the kind of stuff I didn't want to bother maintaining with static pages. I began to think about the whole PHP-Nuke themes and thought, "how close can I get it to looking like SharePoint without changing the codebase?". This is the result so if you do a double take on the site, it's all PHP powered with no .NET in sight.

PHP-Nuke bears a lot of resemblance to SharePoint (I guess all "portal" type software does, or maybe it's the other way around). The modules would make a good Quick Launch. Blocks seemed to have a Web Part feel to them. Search was there. All it needed was a visual overhaul and a few tweaks. After dissecting SharePoint for awhile and the DHTML it spits out, I grabbed some of the graphics and stylesheets from a default install of WSS and started on the new Nuke theme. A few days later, lots of tweaking of tables and pixels and telling PHP-Nuke all about these imaginary "ms-" classes, and my SharePoint theme was born for PHP-Nuke.

I still have some work to do. Namely the modules list isn't quite right but it's close to SharePoints own Quick Launch and there are no dynamic menus to hide/show Nuke blocks (think Web Parts) like you can with SharePoint. I did track down some mods and add-ins that I'm trying out and I think I can get the Quick Launch menu 100% there and at least add the minimize option to each Nuke-block. Overall I'm pretty impressed at the level of customization achievable with a little PHP coding. There are a few small bits that are not 100% customizable (like the page title has that annoying "-" in it which I can get rid if I slightly alter every page, but I didn't want to touch the Nuke codebase).

So if you're stuck like I was with running PHP on my webserver, drop by and take a look. You can download the PHP-Nuke SharePoint theme directly from here. Feel free to use it on your own PHP-Nuke site and claim back that SharePoint look and feel we all know and love.

Nothing like finding a solution to a problem for the end of the year. Don't say I didn't give you anything.

I was recently asked about how to tackle long questions in surveys with SharePoint, specifically there's a problem that long questions don't wrap so you get a really ugly looking website. Go ahead, create a survey and add a really long question to it. Notice how you're stuck with horizontal bars from hell? Here's how to get rid of it.

1. Create your survey as you normally would.
2. Select Respond to this Survey.
3. Click on the Edit with Microsoft Office FrontPage on the IE toolbar. This will launch FrontPage with the NewForm.aspx page loaded.
4. Right click on the Survey form in FrontPage and select Customize SharePoint List Form from the popup menu. This will convert the form to something you can edit. NOTE: It's not pretty as all the HTML tags are now literal so be careful editing these!
5. Scroll down and find a tag that starts with something like this:
   <Content xmlns="http://schemas.microsoft.com/WebPart/v2/ListForm">
   The rest of this tag will contain the HTML for your survey form (like I said all the HTML tags are literal so <TD> will look like &lt;TD&gt;)
6. Find the tag that looks something like this TR&gt;&lt;TH nowrap valign=top class=&quot;ms-formlabel&quot;&gt;
7. Change the TH nowrap to TH wrap
8. Save the page and return to your browser.

You'll see the change in FP and when you refresh the page in your browser. The text now wraps and all is well. Neat huh? Repeat this for each question (keep looking for the ms-formlabel class). These instructions are only for the NewForm.aspx page which is what users will see when they respond to a survey. There are still other pages which suffer from the "nowrap" tag so you'll have to edit each of those. They are:

• DispForm.aspx (used to view a single result)
• EditForm.aspx (when you edit an existing response)
• summary.aspx (when you want to see a graphical view of all responses)

AllItems.aspx and overview.aspx don't show the questions so you don't have to worry about this files.

Another way to do this is to open up the site, not the page, in FrontPage and expand the survey you want to edit using the Folder List (Alt+F1) from the View menu. From here you can just edit NewForm.aspx and the other pages directly and take out that nasty "nowrap" attribute.

Hope that helps and have a safe and happy New Year!