I got a message through my Live Space today, but I couldn’t respond due to the sender’s preferences, so I decided that I’d reply here.
I’m having an issue with some Data View Web Parts I created via SPD. I create the data views in Designer using data sources from SharePoint lists. That works fine. Then I link my data views through Web Connections (all in Designer). That seems to work fine. They I test in a browser. That works fine. I make my radio button selections and all the data views switch to that linked items content. However, I’m the only one that can see this info from the browser. HELP!!!
My best guess based on what you’ve told me is that your users have different permissions on the content than you. Since you are able to edit the page with SharePoint Designer, it’s highly probable that you have Site Collection Administrator permissions. This would allow you to see all content in any list on the site. Check to see what your users’ permissions are on the same content that you are seeing.
Hope this helps. Drop me a comment if you have further questions.
There are occasions when the master page that is attached to a site is not valid. The master page connection is made with a URL, and if that URL isn’t valid, you will get errors like:
- File not found (This is SharePoint saying that the master page itself is not found.)
- / cannot be opened (or the like)
One quick check you can do is to go to the Site Settings page to check the master page connection. Do this by hacking the URL to point to:
Once there, you can set the master page something valid and your site will miraculously be back in business.
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!