Thursday, 9 January 2014

Hiding the Sharepoint 2010 ribbon from users without losing the scrollbar or title bar area when using a list webpart

There are many blog posts suggesting techniques to hide the Sharepoint ribbon using security trimmed controls in the Sharepoint masterpage, however I have found that none of them properly address the issue of how Sharepoint processes user clicks with the ribbon: namely that the titlebar area will disappear if the ribbon has been hidden with CSS!

In my site I use this area to display location specific information taken from a BCS connection, and provide location specific buttons and actions (all using sharepoint delegate controls), so there was no way I could lose this section of the page. I have therefore had to work out how to stop this from happening.

In order to solve this we must first implement the standard method of hiding the ribbon with CSS, and use a security trimmed control in order to decide which users get to access the ribbon and which do not. This has been gone over in detail elsewhere so I will only briefly recap this now.
First, edit the masterpage and set a style element in the "s4-ribbonrow" div to hide it:
<div class="s4-pr s4-ribbonrowhidetitle" id="s4-ribbonrow" style="display: none;"%>
<%--added display:none to hide Ribbon--%>
Next, add a security trimmed control to make the ribbon visible for administrators (in my case this is users with delete permission, hence I have used the "DeleteListItems" PermissionsString:
<%-- Show the ribbon to power users -->
<sharepoint:spsecuritytrimmedcontrol id="RIBBONHIDE_SPSecurityTrimmedControl3" permissionsstring="DeleteListItems" runat="server">
    <script type="text/javascript">
        document.getElementById("s4-ribbonrow").style.display = "block";

Installing this masterpage and applying it to your site will hide the ribbon from users without delete permission. Hooray!

When implementing this techniques you will find a major flaw: if a list webpart is on the page then when a user who has not got the ribbon clicks on the list webpart in a section that would normally cause the ribbon to show, the user will lose the title area at the top of the page. This includes the logo, the breadcrumb trail, and the social icons. After investigation I determined that this is caused by the Ribbon javascript replacing the title area element with the ribbon, and since you have hidden it, this mean that the whole title area is removed. I've followed this through the whole code and it seems to be related to the custom javascript scrolling function that Sharepoint 2010 uses.

The fix

In order to get around this, we have to make changes to a couple of other areas.

First, we must update the following javascript fuction "OnRibbonMinimizedChanged" that is found in the standard Sharepoint INIT.JS javascript file in the 14 hive. DO NOT edit the file directly! It can be simply overriden by including another javascript file later on in the masterpage (see below). To override this function, first create a file called "HideRibbon.js" with the following in it:
var g_spribbon = new Object();
g_spribbon.isMinimized = true;
g_spribbon.isInited = false;
g_spribbon.minimizedHeight = "44px";
g_spribbon.maximizedHeight = "135px";
function OnRibbonMinimizedChanged(ribbonMinimized) {
    ULSxSy: ;
    var ribbonElement = GetCachedElement("s4-ribbonrow");
    var titleElement = GetCachedElement("s4-titlerow");
    if (ribbonElement) {
        ribbonElement.className = ribbonElement.className.replace("s4-ribbonrowhidetitle", "");
        if (titleElement) {
            titleElement.className = titleElement.className.replace("s4-titlerowhidetitle", "");
            if (ribbonMinimized) {
       = "block";
            else {
                // = "none"; // MODIFICATION -  Commented out - do not hide this element, or it will hide the whole title area when it thinks a ribbon is required
    var wasInited = g_spribbon.isInited;
    g_spribbon.isInited = true;
    var lastState = g_spribbon.isMinimized;
    g_spribbon.isMinimized = ribbonMinimized;
    if (lastState != ribbonMinimized || !wasInited)
Upload this file to your site somewhere (in this example I will use the "Shared Documents" list), and add the following to your masterpage in order to including it:
<asp:scriptmanager enablepagemethods="false" enablepartialrendering="true" enablescriptglobalization="false" enablescriptlocalization="true" id="ScriptManager" runat="server">
        <asp:scriptreference path="<% $SPUrl:~sitecollection/Shared%20Documents/HideRibbon.js%>" runat="server"></asp:scriptreference> 
Put this section after the body element, directly after the form element. I.e. after the following two lines of the masterpage:
<body scroll="no" onload="if (typeof(_spBodyOnLoadWrapper) != 'undefined') _spBodyOnLoadWrapper();" class="v4master">
  <form id="Form1" runat="server" onsubmit="if (typeof(_spFormOnSubmitWrapper) != 'undefined') {return _spFormOnSubmitWrapper();} else {return true;}">

Now change this line in you masterpage:
<div class="s4-pr s4-notdlg s4-titlerowhidetitle " id="s4-titlerow">

Change it to this to remove the class that tells the javascript that this is the bit to hide:
	<div class="s4-pr s4-notdlg " id="s4-titlerow">
<%-- Changed class to remove to s4-titlerowhidetitle so ribbon does not fire up over top of this --%>

Now you should find that the title bar remains active even when the ribbon is active (thus losing some screen real estate), but that restricted users with no ribbon do not lose their title area when they perform an action that would normally have opened the ribbon :)
Best of luck and happy coding!

Click here to see the top ten best selling Omega watches in the USA right now

Tuesday, 17 September 2013

Online tools to convert code between VB and C#

Using .Net and the CLR means we have sometimes have to use both VB and C#. If you are anything like me you will forget the more subtle syntactical differences between the two more often than not, a situation I found myself in earlier today when trying to work out how to rewrite an old VB function in C#.

Rather than doing this myself (I very rarely use VB anymore) I decided to try to use some of the resources on the internet.  The following sites will all allow you to convert freely between the two languages by pasting code into a browser control:

CodeTranslator: Code Translation From VB.NET <-> C# - CarlosAG - my favourite - this one managed to convert things the others couldn't.

Convert VB.NET to C# - developerFusion

Convert VB to C# or C# to VB provided by Telerik

Hope this helps!

Saturday, 22 June 2013

Changing the name and URL of a document in Sharepoint using c#

Changing a document's name in Sharepoint programatically, particularly in a webpart for example, is not a trivial process.  In theory, we can use the SPListItem.Item("Name") property and update this.  However you may find that non-administrative users can receive  "permission denied" error when they save this back to the database (using a web.Update()).

This is generally because in order to move (rename) a file in Sharepoint, the user must have "delete" permission on list.
Provided the users have enough permission, then the code below works.  The trick here is to use an SPFile object to update the "Name" property, whilst using an SPListItem object to control the files checkin/out status.

Keen readers will see that I am doing a ValidateFormDigest() in order to prevent the "Page Validation" error if this is caused from a form's POST action, but there is also a "web.AllowUnsafeUpdates = true;" command.  I would prefer not to allow unsafe updates and would recommend you keep this line uncommented, but I have left it in in order to give you an option if you find that this still does not work properly in your situation.

 using (SPSite site = new SPSite(SPContext.Current.Web.Url))
     using (SPWeb web = site.OpenWeb())
             SPListItem target = web.GetListItem(fileUrl);  // fileURL should be set to the full path of the document you are changing

             if (target.File.CheckOutType == SPFile.SPCheckOutType.None)
                  //web.AllowUnsafeUpdates = true;         // Shouldn't need this with the validateformDigest
                  {                      target.File.CheckOut();
                      SPFile filet = web.GetFile(target.Url);
                      filet.Item["Name"] = newName;     // newName is the new name of the file                               
                   catch (Exception ex)
                       web.AllowUnsafeUpdates = false;
                       ShowErrorMessage("Error validating document: " + ex.Message);  // Deal with error
                   target.File.CheckIn("", SPCheckinType.MajorCheckIn);  // Make major version
                   web.AllowUnsafeUpdates = false;


            catch (Exception ex)
                ShowErrorMessage("Error: " + ex.Message);  //Deal with error
                web.AllowUnsafeUpdates = false;


Friday, 19 October 2012

SharePoint workflow - Delay activity never ends, workflow waits forever.

Developing Sharepoint workflows using the Windows Workflow Foundation and Visual Studio can be pretty painful. 

By far the most painful part I have come across is the dreaded delay activity never waking up problem. This occurs when you place a delayActivity object in your workflow in order to wait for something to happen (for example in a while loop).  This is pretty fundamental stuff in a workflow, so you would expect this to be a basic requiredment, but for some reason SharePoint has a HUGE flaw in this department: when you are developing your workflows, they seem to get stuck in the delay and never wake up!

A WWF DelayActivity in a while loop

Workflow history - it never wakes up after delay :(

After much head scratching, I have found a solution.  The delayActivity passes control to the SharePoint Services Timer (OWSTIMER.EXE), and this gets confused if you redeploy the wrokflow.

To fix, follow these instructions.

First run this command on your farm:
stsadm -o setproperty -pn job-workflow -pv "Every 5 minutes between 0 and 59" -url http://yoursite

(note apparently doesn’t like being anything but 5 minutes! )

I rebooted my dev box after this but this is probably not required.

The key part is that now provided I restart the Microsoft Sharepoint Timer service between deploys, it actually completes a delay!  So remember to recycle the "Sharepoint 2010 Timer" service before you depoly a new version of the workflow to the farm.

OWSTIMER service

Note that this was supposedly a bug fixed in 2007 that is back in 2010.  See this hotfix for 2007 systems:

To debug any code that runs after a delay, you have to attach Visual Studio to the timer service (owstimer.exe), not the w3w process.  I do this by switching off "auto retract after debugging" in the "Sharepoint" page of the project's properties file and manually attaching to the OWSTIMER.EXE process.

Friday, 8 June 2012

Unexpected Error when deploying web part pages using Visual Studio solution

It is good practice to wrap any Sharepoint web part pages you develop in a feature, and deploy them as a solution using Visual Studio. There are many walkthroughs on how to do this on the net, including this excellent Microsoft effort so I won't go into the details here.

If you follow this technique, the basic steps to developing a deployable feature are:
  1. Make your web part page in the Sharepoint front end or Sharepoint designer 
  2. Once development complete, export the page to a site solution file 
  3. Copy the appropriate section to your Sharepoint deployment soluting project
At this point you will end up with something like this:

Note that my solution includes much more than just a web part page - it also has a masterpage, many images, CSS and javascript/jQuery - in other words all the things you need to make a nice custom web part page all in one deployable feature.

So everything is fine, but then you deploy the solution, and ARGHH! it throws an error! Worse, it throws an "Unexpected Error". This is the least useful error message you can imagine. So whats the solution?

Well after going through all the XML for my features I found the following:

The highlighted line is:

This is the ID of the web part file WHEN IT WAS EXPORTED.

When you deploy this solution to a site, the ID of the file is whatever the next ID available (it's basically an incremental integer). Therefore by leaving in this piece of declarative XML, we are attempting to force the file to use this ID. This is what is causing the "Unexpected error" on deployment.

Simply comment out this line and your solution will deploy. 

Friday, 25 November 2011

Integration between Word 2003 and SharePoint 2010 using Managed Meta-data

You cannot check out/edit/check in directly from Word 2003 if you are using managed meta-data in the list.  Word 2003 does not seem to integrate properly with managed meta-data columns, and will refuse to check in the document.

This leaves teh document in an unsaved, checked out state if a user attempts to edit it directly from Sharepoint.

My only solution to this has been to create a new content type and remove the managed meta-data from it.