Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Opening things

  Asked By: Charmaine    Date: Dec 01    Category: Sharepoint    Views: 934

I have been reading the PPT thread and I know about what I have seen with

I have played with file type associations in XP and the programs etc. in IE.

The thing is, WSS seems to have a wholly different mechanism for choosing to
open files in certain ways, and this seems to be dictated by the OWS.js

So in some way, I think the issue I have been fighting and the one about PPT
is the same.

Here it is:

1) If you click on a link, it brings up the file 'read-only' using the best
approximation of read-only for that application.
2) If you "edit in <application>" it brings it up in the native application
in full edit mode.

From what I can tell, it ignores much of how XP and IE are configured when
the application in question is an office application, instead choosing to
use (what I believe to be) a shaperpoint open document plug in that loads.
Look at your plugins and see it. It loads when you open an office document
from sharepoint.

This is why I am trying to 'code' into my web parts how I want to open the
file, so I can control it vs. sharepoint. In many cases, depending on where
the user is, they want to open in full edit mode, and in other cases (again
depending on where they are) its a read-only or 'viewer' type thing (which
seems to be the default).

Does any of this ring true with your guys or am I all confused again?



2 Answers Found

Answer #1    Answered By: Alexandra Patterson     Answered On: Dec 01

In my quest to better control opening  documents, I have discovered some
interesting things. I hope to summarize all of my findings some day,
however, this one deserves some air now I think because it seems like a way
to to some stuff that would be considered as impossible to do any other way.

Again, it seems that opening documents is done using the OpenDocuments
Control or IE. This appears to be unavoidable in sharepoint. This led me to
this: www.toomuchcode.net/.../customizing_sha_1.html

So what I was looking for was a way to intercept and adjust what sharepoint
does. Look at what this guy (Paul McBride??) says regarding a global onload
event handler ( www.toomuchcode.net/2005/04/customizing_sha.html ).

What I found is the same stuff works in a CustomJSURL file  for my site
definition's project and I can intercept and process Clicks in client-side
code before sharepoint  gets to them. This avoids the inherent problem Paul
has in modifying OWSBROWSE.js.

Does anyone have a comment? My code  is below (it has some alert statements
in it for debugging purposes and is by no means complete).

So in my site definition I have CustomJSUrl="/_layouts/1033/PUBSows.js"

In PUBSows.js I have:

window.attachEvent("onload",new Function("page_onLoad();"));
var isCalled=false;
var myHREF = ""

function page_onLoad(){
if (!isCalled){
//alert("click handler version "+location.href);
myHREF = extractDomain(location.href);
if (document.forms[0]){

var myAction = document.forms[0].action;
//alert("my action "+myAction);
if ((myAction.indexOf("Mode=Edit") == -1) &&
(myHREF.indexOf("1033") == -1) && (myHREF.indexOf("/Forms/") == -1)){ //Do
not handle click  events when in edit  mode
//alert("click handler version 2 "+location.href);

function onClick_handler(e)
{ if (!e) e = window.event;
var mySource = e.srcElement;

if ((mySource.tagName =="A") && (mySource.onclick)) {
mySource.onmouseup = mySource.onclick;
return false;
alert("mySource.href"+ mySource.href);
if ((mySource.tagName == "A") && (!mySource.onclick) &&
(mySource.href.indexOf("javascript") == -1)){
//if srcelement has an href property, and NOT a defined onclick
if (extractDomain(mySource.href) != myHREF) {
e.srcElement.target = "_blank"
} else if (mySource.href.indexOf("Publications") != -1) {
e.srcElement.target = "_blank";
return true;

function extractDomain(myHREF){
//alert((myHREF.indexOf("//") > 0) ? (myHREF.split("/")[2]) : '');
return (myHREF.indexOf("//") > 0) ? (myHREF.split("/")[2]) : '';

Answer #2    Answered By: Christop Mcfadden     Answered On: Dec 01

Rather than window.attachEvent (which is browser specific) I suggest you use a JavaScript function like the following:

//Utility to add an event to window.onload, if the browser supports it

function AddToWindowOnload(eventToAdd)


//First try to use attachEvent

if(typeof window.attachEvent != "undefined")


window.attachEvent("onload", eventToAdd);


//Then try to use addEventListener

else if(typeof window.addEventListener != "undefined")


window.addEventListener("load", eventToAdd, false);


//Append to existing window.onload events, if any,

//by creating a function

else if(window.onload != null)


var origOnload = window.onload;

window.onload = function(e)






//Finally, assign directly to window.onload



window.onload = eventToAdd;



In my last SharePoint Advisor article I explain how you can more than double your ability to override style and behavior when you implement my recommendations:

I ALWAYS implement AlternateCSS and CustomJSUrl in all Site Definitions. This can be incredibly useful for all kinds of situations (like the one you describe).

I also recommend that you put your alternate override files  into a Site Definition directory in a “Custom” directory in /_layouts/1033 rather than in the root with the hundreds of other Microsoft files. In other words, if your Site Definition is called “TODD” (if you’ve taken my class you know that you can name almost anything TODD) you would put your custom files into the following location:


Also, be sure to use Try Catch blocks in all of your JavaScript functions.
All that said, with CustomJSUrl in your Site Definition, I think there are easier ways  to get all links to open  in a new window. If you want, send me a direct email with your requirements and I’ll give you more specific feedback.

Didn't find what you were looking for? Find more on Opening things Or get search suggestion and latest updates.