I am trying to persuade the application pages in a WSS site to look similar to the site pages that are customised by a master page - my approach was to create a new theme, and modify the CSS in that theme using the CSS applied to the master page.
It almost worked, but had a nasty side-effect. Some part of the CSS caused the "select theme" list on the Site Theme admin page to be squashed out of screen space by the left-hand cells expanding too far across the page. The image of the still displayed, but there was no way to remove the bad theme.
Oh dear, what to do?
Then some playing in the IE Developer toolbar revealed a solution - the toolbar allows CSS styles to be edited and applied in the live page. I applied a width attribute to several of the cells in the affected table, and managed to reveal the theme list box in the displayed page, thereby allowing me to reapply the default theme before modifying the new theme.
This difficulty in modifying the application pages to match the site pages is an oft-quoted citicism of SharePoint. During a little research for this post, I have noticed that Microsoft has published a KB article on their recommended server-side fix for this.
Showing posts with label tools. Show all posts
Showing posts with label tools. Show all posts
Sunday, April 6, 2008
Thursday, February 28, 2008
Why Reflector is a Developer's Friend
If you have been wondering why some .net developers rave about Reflector as the one tool that rules them all, and have thought that maybe you should give it a try, here's a little tale about how it made my day better... (hope it encourages you)
Whilst attempting to bind an SPGridView to a LinqDataSource, one of the requirements was to use the filtering features of the SharePoint gridview (that's one of it's strengths above the standard GridView control).
I came across a post by Robert Fridén that described how to enable filtering when binding to an ObjectDataSource. An SPGridView property named FilteredDataSourcePropertyName needs to be set, and that must contain the name of the property on the bound datasource which will be called when filtering the data. In other words, it requires a string containing the name of a control property.
For an ObjectDataSource, that property is named "FilterExpression". I decided it was highly unlikely that the LinqDataSource would use the same property name, so I turned to Reflector.
In Reflector, I found and opened the System.Web.Extensions dll, browsed to the LinqDataSource class and then looked through the properties. Didn't need to right-click and disassemble the dll in this case, as one of the properties was named "Where". Sounded a good option for filtering. So I used that as the FilteredDataSourcePropertyName value, played around a little with the FilteredDataSourcePropertyFormat property of SPGridView, and hey presto the filtering worked. Sure, I could have looked through the MSDN documentation, but with Reflector I can browse inside the methods of the data source class if needed.
If you've not yet delved inside the .Net dlls with Reflector, give it a go. You'll be rewarded!
...and by the way, as tempting as it was I just couldn't bring myself to put the word"best" in the title ;-)
Whilst attempting to bind an SPGridView to a LinqDataSource, one of the requirements was to use the filtering features of the SharePoint gridview (that's one of it's strengths above the standard GridView control).
I came across a post by Robert Fridén that described how to enable filtering when binding to an ObjectDataSource. An SPGridView property named FilteredDataSourcePropertyName needs to be set, and that must contain the name of the property on the bound datasource which will be called when filtering the data. In other words, it requires a string containing the name of a control property.
For an ObjectDataSource, that property is named "FilterExpression". I decided it was highly unlikely that the LinqDataSource would use the same property name, so I turned to Reflector.
In Reflector, I found and opened the System.Web.Extensions dll, browsed to the LinqDataSource class and then looked through the properties. Didn't need to right-click and disassemble the dll in this case, as one of the properties was named "Where". Sounded a good option for filtering. So I used that as the FilteredDataSourcePropertyName value, played around a little with the FilteredDataSourcePropertyFormat property of SPGridView, and hey presto the filtering worked. Sure, I could have looked through the MSDN documentation, but with Reflector I can browse inside the methods of the data source class if needed.
If you've not yet delved inside the .Net dlls with Reflector, give it a go. You'll be rewarded!
...and by the way, as tempting as it was I just couldn't bring myself to put the word"best" in the title ;-)
Subscribe to:
Posts (Atom)
