This one was suggested to me by my friend and colleague Mike Koffman. He always tries to take the time to go to Advanced in the Modify Web Part panel and take away the user’s ability to "close" the web part. Here’s the story why.
In working on other people’s sites in SharePoint, I’m often amazed at how many Web Parts are on the pages, but not visible to the users. This is usually due to false starts in implementation, trying things out and then abandoning them for some reason, etc.
Most people seem to just click the little "X" in the upper corner of the Web Part and assume that it has been deleted. But no, it’s still there. If you open the page in SharePoint Designer, you’ll see all of the "ghostie" Web Parts still hanging around. (I say "ghostie" because they are faded out in the UI. And because I have a four year old.)
Because the Web Part is still there, SharePoint still has to process it when the page loads. I heard through the grapevine that a Microsoft engineer said recently that it takes more work for the system to process the Web Part when it’s closed than it does when it’s visible, but I can’t vouch for that. In any case, SharePoint has to at least read the code for the Web Part to realize that it shouldn’t display it.
To really get rid of the Web Part, you should select the "Delete" option from the menu rather than clicking the "X". The problem is that, once it’s closed, it’s virtually invisible so you don’t even know it still exists. One trick you can use is to navigate to the page and add "?contents=1" to the end of the URL. This gives you a page with a list of all the Web Parts on the page, with a column showing whether the Web Part is open or closed. To get rid of the closed Web Parts, select the check boxes next to them and use the "Delete" option on the toolbar. The other option is the one which I prefer: open the pages in SharePoint Designer and delete those little "ghosties"!
Many of the gradients that you see in the default SharePoint branding (that dreaded blue and orange that everyone wants to change) are created by using an image that is the appropriate height and one pixel wide. The images are used as the background-image in the various CSS classes with background-repeat set to repeat-x. This is nice because the image will be repeated horizontally for as many pixels as are required, regardless of the width of the object.
If you can reasonably rely on your users having some flavor if Internet Explorer (Some of these tricks may work just fine in other browsers, but I haven’t done any testing other than with IE.), there are some nice tricks outlined in this article:
Instead of using images to create your gradients, you can use DXImageTransform.Microsoft.gradient in your CSS in a filter, like this:
filter: progid:DXImageTransform.Microsoft.gradient (GradientType=0, startColorstr=#596E9E, endColorstr=#000000);
What this does is to dynamically create the gradient, going from the start color to the end color over as many pixels as there are in your object. This means that you don’t have to worry about the size of objects ahead of time; the filter will adjust as needed.
I would still recommend setting a background color (as above) to handle the cases where the filter may not display correctly. I have run into some areas in the default master page where this is the case, but I haven’t been able to isolate the exact reason. I suspect it may be caused by some of the scripts that run on various controls.
I’m working at a new client and just getting the machine that they have me using working the way I like it. I tried to open a workflow in SharePoint Designer and got the popup dialog: “Failed to load the workflow.” (I had already loaded .NET 3.0 to get the Workflow Foundation Classes.)
A little searching, and I found the answer in Scott Muller’s blog
: Navigate to C:\Documents and Settings\<your user name>\Application Data\Microsoft\SharePoint Designer\ProxyAssemblyCache and delete the existing folder (12.x.x.xxxx). (You’ll have to shut down SharePoint Designer for the delete to work.) I’m not sure why it works, but it works!
If you’ve been using Office 2007 on a Vista machine for as long as I have, you may have just gotten used to the extra credential prompts when you open Office documents from SharePoint 2007. Well, Microsoft considers this a "known issue", but it’s not clear when it may be resolved for good, though it may be in Vista SP1.
In the meantime, there is a hotfix you can get, but you must ask Microsoft for it. See the article entitled ‘You are prompted to enter your credentials when you access an FQDN site by using a Windows Vista-based client computer that has no proxy configured’ for the details. The hotfix will only work for the SharePoint sites that you specify in the registry, so it is just a temporary workaround.
Serge van den Oever wrote this MSDN article about the functions that are available in the ddwrt namespace. He wrote it for SharePoint 2003 and posted it to MSDN in October 2005, but I’ve never found a newer or better reference for MOSS. I’ve used Serge’s postings many times to help solve challenges, and I recommend him if you ever run across them.
I’ve found a few additions to Serge’s list below, but I haven’t been able to find documentation for most of them:
||Called with (example)
||Encodes a string into the ECMAScript format.
Here are a few excerpts from Serge’s article (any references to FrontPage are still valid for SharePoint Designer):
Microsoft Windows SharePoint Services provides the powerful Data View Web Part that can perform an Extensible Stylesheet Language Transformation (XSLT) on XML data retrieved from a data source. When you are working with a Web site based on Windows SharePoint Services from within Microsoft Office FrontPage 2003, you can use the Data View Web Part to do the following:
- Define a query and data source from which to retrieve the XML data. Data sources can be SharePoint lists or external databases such as Microsoft SQL Server.
- Define the XSLT transformation that converts XML retrieved from the data source into HTML. FrontPage offers a WYSIWYG experience for editing these XSLT views, including live data preview.
During the XSLT transformation process, the Data View Web Part uses an XSLT extension object that provides several functions in the ddwrt namespace. These functions perform tasks such as accessing properties of a SharePoint list or firing events to connected Web Parts. This article describes the functions implemented by the extension object.
Following is information about the set of functions implemented in the ddwrt namespace. These functions are prefixed with ddwrt in the XSLT code that is generated by FrontPage.