Text Files, Associations, and SharePoint

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?

1 Comment

  • .txt file handling is getting even worse if you use your Windows Explorer to connect to Sharepoint using WebDAV.

    It seems as if you are able to open the txt-files directly in your Windows Explorer (which is a good solution for the file association issue). The downside is, that you never check-in the files you edit this way. You won't notice as you see the files you checked out yourself. But everbody else sees nothing until you login to Sharepoint and manually check-in all txt-files.

Comments have been disabled for this content.