I was just trying to get a multi select list set up so that when I mouse over one of the options in said list, it would show information in an adjacent div.   In FireFox this worked just fine by adding an onmouseover to the option tags and have it update the div’s innerHTML.  But for IE, there was no happiness.   IE apparently won’t handle onmouseover or onclick for an option tag.  Cause who cares about option tags.   Well I finally came up with a solution, at least for my case.

In trying to find a solution, I kept trying to use the (propriatary) attachEvent method to attach an onmouseover or onclick event to my options.  Again, no luck here.  However I did find that I could use the test for attachEvent support to at least isolate IE and only use my solution for IE.  So here’s the code I ended up with:

My select list. I’m listing groups of skills and I want to show which skills are included in each group.

<div style="float: left;">
  <select size="5" name="listSkillGroups" multiple="multiple" id="listSkillGroups" onclick="getText(this)">
    <option value="20"
      title="Small Equipment Operations, Hammering"
      onmouseover="getText(this);">
      Carpentry Skills</option>
    <option selected="selected" value="2"
      title="MS SQL, Oracle Database"
      onmouseover="getText(this);">
      Database</option>
    <option value="4"
      title="A+ Certification, PC Repair, Microsoft SMS"
      onmouseover="getText(this);">
      Desktop Engineering Skills</option>
    <option value="18" title="MySQL, Apache, PHP Development, CSS, HTML"
      onmouseover="getText(this);">
      FOSS Experience</option>
    <option value="5"
      title="Microsoft Word, Microsoft Excel, Microsoft Sharepoint, Microsoft InfoPath"
      onmouseover="getText(this);">
      General PC Skills</option>
    <option value="3" title="Small Equipment Operations, Small Equiment Repair, Tree/Plant Identification"
      onmouseover="getText(this);">
      Landscaping Skills</option>
    <option selected="selected" value="1"
      title=".NET, IIS, CSS, HTML" alt=".NET, IIS, CSS, HTML"
      onmouseover="getText(this);">Web Development</option>
  </select><br />
  <span>
    (Use Ctrl or Shift Key to select multiple.)
  </span>
</div>     

<div id="SkillDetails" style="padding: 10px; float: left; width: 250px;"></div>

Now the javascript function for both the mouseover and onclick versions.

<script type="text/javascript" language="javascript">
   <!--
   var oSelected = ",";
   function getText(ctrl) {
     if (window.attachEvent) {
        for (var o = 0; o < ctrl.options.length; o++) {
            if (ctrl.options[o].selected == true && oSelected.indexOf("," + ctrl.options[o].value + ",") == -1) {
                oSelected += ctrl.options[o].value + ",";
                document.getElementById('SkillDetails').innerHTML = "<strong>Included Skills:</strong> " + ctrl.options[o].title;
            } else if (ctrl.options[o].selected == false && oSelected.indexOf("," + ctrl.options[o].value + ",") != -1) {
                oSelected = oSelected.replace(ctrl.options[o].value + ",", "");
            }
        }
     } else {
        document.getElementById('SkillDetails').innerHTML = '<strong>Included Skills:</strong> ' + ctrl.title;
     }
   }
-->
</script>

 

As part of a recent request to customize the header of a SharePoint (MOSS 2007) site, I ran into a little problem when trying to dynamically replace a stylesheet using Javascript.  The page had two stylesheets loading, one core stylesheet and one theme stylesheet, in that order.  I was trying to replace the core stylesheet with an altered version for certain parts of the site, however when I did it was as if the theme stylesheet was being overwritten too.  The problem was in how IE handles the DOM and Stylesheets (this was not a problem in Firefox).

I started by creating a new stylesheet link element, then replacing the existing one with the new one (see code below).

var newElement = document.createElement("link");
newElement.type = "text/css";
newElement.rel = "stylesheet";
newElement.href = "/_layouts/1033/styles/core_orig.css";
newElement.media = 'screen';

var oHead = document.getElementsByTagName("head")[0];
var aLinks = oHead.getElementsByTagName("link");

for (var li = 0; li < aLinks.length; li++) {
if (aLinks.href.indexOf("core.css") > -1) {
oHead.replaceChild(newElement, aLinks[li]);
}
}

This was the first instance of seeing the problem with my theme.css being overwritten.  I then tried just doing a simple replace on the link href to replace core.css with core_orig.css.  Again, the same results.  In both cases it seemed as if the replace just wasn’t happening at all.  After some exploring using the ever helpful Firebug and the IE Dev Toolbar I realized the replace was happing, it just wasn’t behaving as expected.

So finally I realized it was just a matter of the order of things occuring, as it often is.  In this case, IE was loading core.css, then theme.css then in javascript I was loading core_orig.css which because of similar classes was basically overwritting them both.  In Firefox this wasn’t an issue as it just replaced the core.css as I wanted but IE reinterpreted it again after the other two had already loaded.  So now all I had to do was just drop and recreate the theme.css after replace the core.css and I was done (final code below).

var url=window.location.href.toLowerCase();
  if (url.indexOf('/sites/') > -1 || url.indexOf('/sitedirectory/') > -1) {
    var oHead = document.getElementsByTagName("head")[0];
    var aLinks = headID.getElementsByTagName("link");

    var newElement = document.createElement('link');
    newElement.type = 'text/css';
    newElement.rel = 'stylesheet';
    newElement.href = '/_layouts/1033/styles/core_orig.css';
    newElement.media = 'screen';	

    for (var ci = 0; ci < aLinks.length; ci++) {
      if (aLinks[ci].href.indexOf('core.css') > -1) {
        var newHref = aLinks[ci].href;
        newHref = newHref.replace("core.css", "core_orig.css");
        newElement.href = newHref;
        oHead.replaceChild(newElement, aLinks[ci]);
      } else if (aLinks[ci].href.indexOf('/_themes/') > -1) {
        var newNode = aLinks[ci].cloneNode();
        oHead.removeChild(aLinks[ci]);
        oHead.appendChild(newNode);
      }
    }
  }

The other day I started having a strange problem with a DetailsView control inside of an AJAX Tab Panel.  When the control would load, the paging links looked normal, but when I’d click on one they would all become disabled.  In actuality, they were only being disabled in appearance since the paging function is associated with an onclick event rather than the actual href of the link.  So why would these all become disabled?

To make things even more confusing, I had another DetailsView control on the next tab over on the page.  This one was almost identical in code, only differing in the data being loaded, and it worked just fine.  I tried many a thing to try and fix it.  The magical Firebug extension was a big help in trying to debug the javascript that the AJAX controls generate.  From what I could tell, something, somewhere thought that these controls should be disabled so on that first post back, all the links disabled attribute was added and set to disabled.

Next I started looking at what could be causing it to disable, and how to renable it.  I tried various enabled, visible, etc. options but nothing worked.  Finally I started looking at the code around this tab.  Just to see if it was replicatable, I tried switching the order of the two tabs (one working, one not) and behold, the working one did have the same problem and the broken one started working.

So to make an already long story short, I finally narrowed it down to the one thing that was being disabled, the next tab panel.   As part of the web application, the user has the option to turn certain features off, one of which makes this tab unnecessary.  So in this case I was disabling the tab when not needed.  I had a couple other tabs on the page also not turned on but they weren’t causing a problem.  The key was how I turned them off.  Instead of disabling the tabs, I was actually removing them from the tab container collection.

I’m sure I’ll be the only .NET programmer ever to run into this, but should you ever be in the need to hide a tab, remove it don’t disable it.   I have no idea why it makes a difference and would affect the functionality of a control in the tab next door, but now we at least know the fix.

I’ve started using the RSS Viewer web part but it wasn’t obvious how often it would update the feed.  There’s a cache setting in the web part settings but that didn’t seem to control when it updated.

I finally found in the Site Settings, there’s an option for RSS under Site Administration.  There you can specify a site-wide setting for Time to Live.

I was trying to use javascript to do some trimming of content coming in on an RSS feed in SharePoint.  I created a function to do this which worked fine but I found that running it viawindow.onload was running before the RSS feed could load.   I needed a way to watch the div it loads in for a change of content.   Using the javascript watch function seemed like a reasonable solution but after much playing with it I realized IE doesn’t appear to support it.

Instead IE has it’s own event, obj.onpropertychange.  In fact, in my case, this event worked better for me than obj.watch.   In the case of obj.watch, you specify the property to watch and the function to fire off when there’s a change.  So you can do something like myDiv.watch(‘innerHTML’, updateMyContent) to update some content when the content of the watched div changes.  I’m sure this is being done already on a lot of ajax-y sites, but it was new to me.

The only problem in my case with obj.watch is that it expects a value back from the function and uses that value as the new property value.  In my function, I was trying to make changes to the content that had been changed which was then being overwritten when the function completed through the normal flow of obj.watch.

For me, obj.onpropertychange worked much better.  It fires my function on a change, allows me to change the content and doesn’t do any overwriting after I’m done.  Unfortunately, this only works in IE.  Fortunately in my case this is for an intranet where that’s all that is used.  So just be aware of differences in functionality and browser support.

I’ve seen this a couple time and have found help elsewhere, but thought I should add it here too.  If you’re messing with the header on an InfoPath form and end up not being able to open it due to an error with a header tag in your .xsf file, it’s fairly easy to fix.  Kinda.

1. First rename the .xsn to a .cab.
2. Use WinZip or what ever archive program you want and extract the contents of the .cab.
3. There you’ll see the Manifest.xsf.  Open it in Notepad or other text editor and find your offending <header> tag and delete it.
4. Save the file (make sure it keeps the .xsf extension).
5. Now you’ll want to zip these back up into a cab file again.  If your archive program supports this, use it.  If not, try iexpress.exe (Start -> Run -> iexpress) which is likely already on your machine (new to me).  It’ll walk you through creating a cab file from the files you previously extracted.
6. Finally, rename the .cab back to a .xsn and you’re good to go.

Apparently the default for allowed upload size in IIS is around 200k. In many cases, this is not enough. Upload scripts in asp/vbscript will report “Operation not allowed”, which is oh so descriptive. Found a quick and easy post on how to fix this.

At some point our install of MOSS 2007 (SharePoint) started causing problems on the server it was installed on.  If you opened the IIS MMC, it was unable to connect to the local server and display any web sites on the server.  Makes making changes and adding new sites a little difficult.

I found a number of references to this being caused by an incorrect password or user specified to run one or more of the SharePoint related services.  Tried updating all the users to be sure they were entered correctly and this seemed to have fixed it for a while but recently experience the problem again.

While I continue to find a long term solution, I thought I’d at least post the temporary solution.  You can reboot the server to fix this, but most people don’t like having to do this to a production server.  Instead you can just restart SharePoint services, such as the Timer or the Administrator and this will typically fix it without affecting access or functionality of the site or server.

In some cases of users trying to open Word or other documents from a secured external SharePoint site, they are prompted for authentication to the site again as Word doesn’t know they’re already authenticated.  If using Forms Authentication, this doesn’t really work.  There’s an easy IE setting you can change that will have the document open in the browser, maintaining the authentication and not prompting the user again.

1.  Click Start -> Programs -> Accessories -> Windows Explorer (not IE, but Windows Explorer).
2.  On the menu, click Tools -> Folder Options.
3.  Go to the File Types tab.
4.  Scroll down and select the DOC extension (Or xls or what ever you’re changing it for).
5.  Click the Advanced button.
6.  Select the “Browse in same window” option and click OK twice.

Now when the user clicks to open the document, it will load in word inside the browser window without an additional prompt for authentication.

If you create a basic web page in WSS 3.0, the page title in the browser title bar just shows up as “Basic Page”.   You can change this on a per file basis using SharePoint Designer, but you can also make a change system-wide.

My solution was to edit the template file for basic pages located at:

drive:\Program Files\Common Files\Microsoft Shared\web server extensions _
\12\TEMPLATE\1033\STS\DOCTEMP\BLANKPGS\pstd.aspx

Locate the section at the top:

<asp:Content ContentPlaceHolderId=”PlaceHolderPageTitle” runat=”server”>
… </asp:Content>

Replace it with:

<asp:Content ContentPlaceHolderId=”PlaceHolderPageTitle” runat=”server”>
<SharePoint:ListItemProperty runat=”server” Property=”Page_x0020_Title”
id=”ListItemProperty1″/>
- <SharePoint:ProjectProperty Property=”Title” runat=”server”/>
</asp:Content>

Finally, in the document library where you’re going to store your basic web pages, create a new column called “Page Title”.  Now when you create a new basic web page, fill in this column with what ever you want the title to be.  The result is that you’ll end up with a page title of “Value of Page Title Column – Site Name”.  The Site Name comes from whatever you specified as the title of your site.  You can of course change the title elements to be whatever you want, but this worked for my purposes.

Pros:  Pages end up with a logical page title with a fairly easy process.  Easy for normal users to update the page title without the use of SharePoint Designer.

Cons:  This is server wide, so will affect all sites on a server.  But at least if you use pages in a library where there is no “Page Title” column it will still show the site name in the title which is still better than “Basic Page”.