Monday, August 18, 2008

How to get the current SharePoint user full name from InfoPath codebehind

Scenario: SharePoint Forms Library and an InfoPath Form

Question: How to get the FULL NAME of the currently logged in user from code? No hardcoded web service URL.

Solution: SPContext.Current.Web.CurrentUser.Name
All you need is to add the Windows SharePoint Services reference to your project and the following 'using/Imports' directive in the codebehind file:

using Microsoft.SharePoint;
 

Posted by Madalina at 13:32:07 | Permanent Link | Comments (0) |

Wednesday, August 13, 2008

Programatically removing an HttpModule from SharePoint Web.config (2)

In one of my previous posts (that you can find here) I described how I managed to add a HttpModule tag to the web.config. The issue still remaining was the removal of that tag from the web.config, that I needed to do in the uninstallation process (in my case feature deactivating). At that time I used a remove tag. 

Although web.config file sees no problem in duplicate add tags, the same thing does NOT happen with the remove tags. If two or more remove tags of the same module are present in the web.config file, an error is generated - so down the drain goes our solution if two or more install-uninstall sequences occur on the same web application.

What is the solution to this problem? I found it in one of Andrew Connell's books - "Professional SharePoint 2007 Web Content Management Development" (find it in my Books sidebar). It is a fairly simple solution: at Http Module installation in a SharePoint site you add a property to the site to signal that the Http Module should be applied there. In the Http Module code behind you check if that property exists before letting the Http Module do what it is meant to do. At unistallation you remove the property, or make it null. And Voila! - although the tag in the web.config stands, the module will not act on sites unless they have the property it is looking for.

 
Posted by Madalina at 14:12:14 | Permanent Link | Comments (0) |

Tuesday, June 24, 2008

SharePoint customization - applying a theme programmatically

SharePoint sites can be customized through MasterPages and/or Themes. There are 2 main differences between these two methods:
1. masterpages allow you to rebuild the design from scratch - as in move the elements around on the page as you like - but do not affect system pages
2. themes are made up of css files only, allowing you just to skin a SharePoint site, but are also applied on the system pages.

Customizing a site generally means skinning all its pages. So that the user doesn't get confused as of why some pages look different than others, or at least to give the system pages almost the same look and feel as the rest of the pages.
Automating the masterpage install is easy -you create a feature and write code in the FeatureActivated event, code that sets your masterpage as the default and custom master(details on that feature are to come in a future post).
But what about applying a theme? The general procedure would be to have the administrator go on the server and copy some files on the Windows drive and then modify an XML file so that SharePoint can read the theme and display it on the Site Settings > Site Theme page. One of the many posts that explains this method is this one.

But what if you want to do this programmatically? With a feature, like you would do when you deploy a masterpage.

Well, simple enough, this is possible. As long as the theme exists in the THEMES directory, SharePoint can retrieve it. The only reason you modify the spthemes.xml is for SharePoint to display the theme in the Themes list. So if you place the theme in the Themes directory (just by copying it there in a bat file for example) you can use code to apply it:

web.ApplyTheme("MyTHEME");

Since we are here, the way to revert a SharePoint site to the default theme isn't web.ApplyTheme("Default"), but web.ApplyTheme("none").

And there you go - you can programmatically apply a theme to a site. And the way to make the theme "visible" to the user is to have it as a feature instead of having it in the Themes list.

Posted by Madalina at 15:56:17 | Permanent Link | Comments (0) |

Tuesday, June 17, 2008

Programatically add (and remove) an HttpModule to SharePoint Web.config

Sometimes you need to use an HttpHandler or HttpModule in a SharePoint application - I am using one to handle the requests to the system pages and to replace the application.master on them with my own master. To install this module I need to register the dll in the GAC and to add a HttpModule declaration in the web.config.

To modify the web.config programatically in SharePoint you can use the SPWebConfigModification class. There are many examples on the net about using this class, and the one I started with is this one. Unfortunately, this example, along with all the others on the subject are healing with adding HttpHandler elements, while I needed to play with an HttpModule element. The example does apply to me for adding an element, but the issue arises when I need to remove it.

The SPWebConfigModification class has a Name property. This property should be set to the relative XPath to the modification and maps to the Path attribute of an HttpHandler element. The property is used to locate the element when you need to remove it. Unfortunately, the HttpModule element does not have the Path attribute. So no matter how I tried it, I could not remove the element from the web.config.

The solution came while I was reading a different post about web.config inheritance: the tag. If you want to remove the HttpModule element, add a tag to the web.config.

Posted by Madalina at 11:34:33 | Permanent Link | Comments (2) |

Thursday, May 29, 2008

SharePoint on Windows Vista

"Are you a SharePoint developer tired of starting VirtualPC evey morning when you go to work? Are you dissapointed in remote connection speed and how Visual Studio is slow in there? Then this is the post for you!"

This sounds like a soap opera commercial :) I have Windows Vista installed on my laptop and I am kind of fond of it... Not only because it does it's job :) but also because I have spent a while installing applications and configuring it. So when I work on a SharePoint web part or a Sharepoint MasterPage design, I need to use a remote machine.
Not any more though. The Bomboo guys found a solution for that. I tried it and so far I installed WSS 3.0 on my Vista, created the first site, installed SPD and created a new masterpage. It all worked.

"Get it today! Available in stores now!"
Posted by Madalina at 10:17:21 | Permanent Link | Comments (0) |