novolocus.com

I am suffering a common problem still, despite uninstalling Project 2003 previously to try to fix a dll clash.

My system was working fine. I could open and edit documents from SharePoint just fine. Something broke it - and I believe (as in the article at the start) that that was Windows Update.

Now when I try and edit a document, I get the error

‘Edit Document’ requires a Windows SharePoint Services-compatible application and Microsoft Internet Explorer 6.0 or greater.

Which is annoying, as I have this. I looked up the knowledgebase article, followed the instructions, and ended up trying to register/unregister the dll. Except that I can’t. When I try, and I get the error

The module “owssupp.dll” was loaded but the call to DllUnregisterServer failed with error code 0×80070716.

Apparently

This exit code means that “the resource name specified cannot be found in the image file”.

Ooookaaay. Risking my geek credentials, that is gibberish to me. Uninstalling and reinstalling SharePoint Support in the Office features did not fix the problem for me.I think I’m looking at a full Office reinstall. What a load…

Just [user] doesn’t cut it!

I was installing a MOSS system yesterday, and starting the WSS search service was causing me problems. I kept getting errors of the form

SearchServiceInstance.Provision (server ‘VM-AWB-MOSS01′) failed. Setting back to previous status ‘Disabled’.

Well, a google trawl turned up a fairly obvious solution - which just didn’t occur to me. Make sure the account name includes the domain!

Thanks Bergen!

I installed Black Pearl and when I went to the workspace, I had the error:

Unable to generate a temporary class (result=1).
error CS2001: Source file ‘C:\WINDOWS\TEMP\hq-r-kii.0.cs’ could not be found
error CS2008: No inputs specified

I found an article called “K2 - Read the Troubleshooting instructions” by Jeremy Hancock which was bang on. Just in case his blog goes offline, the solution was…

Give all “Authenticated Users” the following C:\Windows\Temp permissions: Read & Execute, List Folder Contents, Read, Write

That fixed it for me. Apparently it is in the troubleshooting in the manual - but who checks that before Google these days? Well spotted Jeremy.

Don’t be lazy like me. I put my Records Center in a collaboration site collection, ‘cos I was lazy and didn’t want to set up navigation links, etc., between site collections.

Unfortunately, I found that when I then tried to submit documents to the records center, I kept getting the error “Records Center Records Center is not properly configured for this request” (Note: my records center is called Records Center).

“Weird”, I thought. The URL to the web service used for submitting files was correct. The records center itself seemed to work correctly. SharePoint Logs and Windows Event logs showed the same error about not being properly configured, but that was all. I couldn’t see anything wrong with it.

So in the end I got hacked off, and just recreated my records center in its own site collection (as you’d problably want it, to be honest). And Bingo! It worked!

So kids, Don’t be lazy - put your Record Center in its own site collection.

Comments from my old blog:

Yup, I’ve found other people have had the same issue - and have done the same thing - use a separate site collection.

By Andy at 16:47:42 Tuesday 13th November 2007

I don’t know why this wasn’t working, but search on my SharePoint VM wasn’t indexing the collaboration portal that was our top level site collection - indeed, it wasn’t even crawling it. So I changed the start path to the fully qualified path (e.g. http://vm-moss07/ to http://vm-moss07.dev.deltascheme.com/), and now at least a few pages were crawled - those being, unfortunately, the pages that redirected to the ‘not fully qualified’ path. So I put both into the content source - and it crawled the whole site collection correctly.

I’m really not sure why, to be honest. I haven’t checked the alternative access mappings, but I don’t see why the search didn’t work without the fully qualified server name. The crawling of the My Sites and Central Admin site collections worked fine without being fully qualified.

I’m sure it’s something simple - any guesses anyone?

I was having a number of issues with Search - and getting lots of errors in the event logs. I followed these instructions on updating registry settings to make PDF indexing work - and it seemed to help. Certainly, I seemed to get fewer error messages in the Windows Event Logs.

More branding - I’d rebranded the SharePoint calendar. It looks nice, and not ‘SharePoint Blue’. “Great”, I thought, “I give that a quick check and move on to the next task”. So I gave it a check - and found that while the DatePicker that appears in the left navigation of the page was fine, the DatePicker control which appears for Date & Time fields had not picked up the styles I’d defined.

Arse. Mine was supposed to be red, not blue. So I began to wonder where this control was actually coming from. It wasn’t coming from my page - viewing the source, it wasn’t there, and if it had been I’d've expected it to be styled.

I didn’t think it was dynamically produced by JavaScript - I was sure there was an .aspx file behind it. I had a nasty feeling, so I went and checked the _layouts directory, but didn’t see anything that looked related to DatePickers.

Next up I tried the IIS logs - and found it. I was right - the DatePicker was being generated by iframe.aspx - and it was in the _layouts directory. (This makes me wonder - is this the only place where an iframe is used in SharePoint? Would something like datepicker.aspx or even datepickeriframe.aspx not have been a more obvious name?)

Anyway, so it’s in the _layout directory. It’s trivial to change it so that it also uses my stylesheet - but that will change it farm-wide, or configuration changes. I guess I’ll be looking at kb-944105 how to customize application pages in the layouts folder in wss 3 and moss 2007.

Okay, this is going to sound really pedantic, but this is really annoying me. In default SharePoint there are a number of buttons. These buttons have text on them. When you roll you mouse over the button, the background and text changes colour. However, as the text does not have the same area as the whole button, the regions in which the hover occurs are different. For example, see the image below…

So, as you can see, the button turns oranges, and then the link turns black.

Now, this isn’t a problem in the default styles - the change from blue to black is very small. But you can’t guarantee that this is the case for rebranded sites - and of course, in mine it was a big difference.

And the crazy thing is, well, the button area’s style is being changed by JavaScript - that’s what makes it turn orange. So you can just use that style change to change the colour of the link text. Why define an hover pseudoclass for it?

Anyway, that’s what I did while tidying up my design.

Okay, so I just made an interesting discovery. In the master pages on SharePoint there is a content placeholder called PlaceHolderTitleBreadcrumb. A slightly odd name - I’m not sure it should have ‘title’ in it, as that seems to make assumptions about how you’re going to use it - but in fairness, it is a placeholder for breadcrumbs. Great!

Except if you go the search page. Then, the search box is shown in the breadcrumb placeholder. WTF! Who the hell designed that? I mean, what idiot decided to put a large control, with LOTS of padding (discussed wonderfully by Heather Solomon).

Speaking of padding - that padding is hard coded into the control. It is fucking CSS, but they put it into the control. Nobody would ever want to get rid of that 50px padding above this control, right? Nobody would have designed space for the nice little breadcrumbs only to be caught out when the stonking search control sticks it’s flabby ass there, right?

Wrong. I’ve been caught, and I’m not the only one. As Tom says, the solution isn’t complicated - but I shouldn’t have to solve it. He’s right when he discusses the ‘contract’ of the master page. This design bug is just wrong.

And I don’t believe that I should have to write my own delegate controls all the time ‘cos someone was too lazy to write theirs in a generic way. I mean, this is supposed to be the office platform. Don’t hardcode styles into your delegate controls, don’t assume your control will be in a table row, and, in fact, could we stop using tables so we might make an accessible system? It’s kind of important in many countries…