Tuesday, September 22, 2009

Troubleshooting SharePoint 2010 Ribbon buttons

While I was preparing to my presentation on SharePoint 2010 in Las Vegas next month, I wanted to show how to add some new cool buttons to the new ribbon menu.

I came across a lot of bloggers writing about this new feature (ribbon),
here is a nice how-to published by Sandeep K Nahta back at July:

But what it does not say and took me a while to understand is few things that makes this not work according to plan...


Keep in mind your feature must be at a site collection level otherwise it will not work.
Farm level will not load anything and site level will work in strange resutls like:
Adding the buttons twice, or if you activate it on 2 sites in the same collection - adding the buttons permanently even after you deactivate the feature and uninstall it.


I wanted to name my actions SLFE.SomeAction (product code.actio name) for our SharePoint List Forms Extensions ( hence SLFE :) ), Now the buttons I added were disabled all the time. Took me a whilte to figure out that the action name must not containt special characters including ... so - keep that also in mind.


The easiest way I found for adding buttons or groups into the existing ribbon is:
- find the location you want to add it in the existing ribbon definition file (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\GLOBAL\XML\CMDUI.XML)
- locate the XML node you wish to insert you XML addition, and keep it's ID value.
- simply inject your XML in your feature elements file to that node's children collection like so (note the CommandUI. and ._children in the custom action's location):
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <CustomAction Id="KWizCom.SLFE.Ribbon.Library.Groups.SLFE" Location="CommandUI.Ribbon.Library.Groups._children" Sequence="2000" Title="SLFE">
... XML as in the CUI schema ...


If you don't see any buttons when you add a group - you must add "scaling" properties for that group!

Also - make sure your chosen template (i.e. Ribbon.Templates.Flexible) support your control's TemplateAlias (i.e. o1). Don't you just hate these XML cross references?!

I will post back here with more info on the ribbon as I find it, check back to update!

Thanks, Shai.

Tuesday, September 15, 2009

Performance issue using SPUtility.GetFullNameFromLogin

Recently we had a strange support call regarding our rating solution.

The customer experienced very bad performance using our rating field type, when opening the comments page for an item.

everything else was working very fast, pages loaded within a blink of an eye, only opening the popup that displays the comments and ratings from other users took anywhere from 10 to 40 seconds...

So, we created a debug version that prints out the time stamp of every stage of the page.
What the page does is basically, load all comments and ratings into a list and binds them into a repeater control.

So, we found out that while loading the comments we get the user login name, and since we want to show the user display name we use this SharePoint API method to get the display name from the login name:
SPUtility.GetFullNameFromLogin(site, "domain\\user_login");

well, to keep it simple, calling the method above to get the user display name took 8 seconds every time we called it, so for every comment on the item the page load time would take 8 more seconds!!!

The customer opened a support call to microsoft while we were investigating other alternatives for getting the user display name.

The answer the customer got from microsoft team was simple and did resolve the issue.
Simply instead of using SPUtility.GetFullNameFromLogin, they recommend using:


so, the web.EnsureUser method works much faster and the performance problem was resolved!

Since I did not see any post about this on the web I thought I might as well write one myself - hope this helps some of you in the future.

Shai Petel.

Tuesday, September 8, 2009

Tired of "Obsolete" warnings on your project?

If you are like me, find yourself marking old code bits as "Obsolete" but have to keep them in your project for backward compatibility - you must be tired of all the visual studio warnings regarding using obsolete code - especially if it is your own code.

In most cases I have an "Upgrade" method that identifies old version installations and upgrade them to newer version constructs, but in this upgrade code I have to use some of the old obsolete code generating these annoying warning.

BUT - I do not wish to disable all Obsolete warnings - some are very important and I do wish VS to keep warning me about them.

So, the proper way to go is to mark specific code bits not to throw any warnings about using obsolete code. Like: telling the VS that within a specific code block I am aware that I am using some obsolete code and I don't want it to show in my build results.

I came accross the simple solution here that saved me a lot of time figuring out the correct pragma statement for this:

Here, Nick Bolton simple says:
What about using #pragma to disable the warning around the specfic code?
#pragma warning disable 0612
// Call obsolete type/enum member here
#pragma warning restore 0612

And guess what? It did the trick for me!

Tuesday, September 1, 2009

KWizCom is going to SharePoint Saturday New York City

This September KWizCom will be at SharePoint Saturday New York and you are invited to come along!

See the details of this exciting event on KWizCom’s SPS NYC event page.