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>

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);
      }
    }
  }

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 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.

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.

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.

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.

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.

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”.