October 24, 2008
Archive for the tag 'DatePicker'
October 22, 2008
I’m beginning to hate the SharePoint DatePicker control. It displays with different widths:
What defines the width of this control? Damned if I can see – it appears to be the widest element within it. This means either:
- the length of the date link at the bottom of the control
- the length of one of the week rows
This is probably less of an issue for Americans (right) than the British (left) – I presume that other Europeans will have the same issue.
Certainly, this will result in some squashed looking calendars on certain months. Yet try as I might, I couldn’t get the calendar to fill an entire area.
And why does the American format give the day and the normal format not?
October 20, 2008
A while back I posted about the how daft that the datepicker control isn’t styled by themes, and is in the _layouts directory, so you shouldn’t edit them.
Well, a while later Michelle posted with a good idea of how to brand them – use an alternate CSS URL. I must confess, this tip passed me by until my recent branding efforts, and I discovered her tip.
So why does this work? Well, if we crack open the file iframe.aspx (which I still think is a bloody stupid name. I mean, the defining feature is the DatePicker control, not the bloody iframe it uses) we can see the code:
There we go – code to insert the alternate CSS url (but not themes – obviously).
So, I gave this a go:
Tada! Styled date picker, nice one Michelle. However, she notes that it has to be applied to a publishing site, or to a publishing site and all sites below it. Site collections based around a team site would be tricky. Normally, this page is used to set the alternate CSS…
[image of site]
… and, well, Team sites don’t give you that page.
However, we can achieve this in code! All the admin page does is change the SPWeb.AlternateCssUrl property for a site or set of sites. We could have a feature receiver (a bit of code that is run when a feature is activated or deactivated) to do this:
public override void FeatureActivated( SPFeatureReceiverProperties properties ) {
SPWeb site = properties.Feature.Parent as SPWeb;
site.AlternateCssUrl = "[Your URL here]";
site.update();
}
More evidence that brands are best applied by feature receivers. Maybe I should make an example of this…
November 2, 2007
More branding – I’d rebranded the SharePoint calendar. It looks nice, and not ‘SharePoint Blue’. “Great”, I thought, “I give that a quick check and move on to the next task”. So I gave it a check – and found that while the DatePicker that appears in the left navigation of the page was fine, the DatePicker control which appears for Date & Time fields had not picked up the styles I’d defined.
Arse. Mine was supposed to be red, not blue. So I began to wonder where this control was actually coming from. It wasn’t coming from my page – viewing the source, it wasn’t there, and if it had been I’d've expected it to be styled.
I didn’t think it was dynamically produced by JavaScript – I was sure there was an .aspx file behind it. I had a nasty feeling, so I went and checked the _layouts directory, but didn’t see anything that looked related to DatePickers.
Next up I tried the IIS logs – and found it. I was right – the DatePicker was being generated by iframe.aspx – and it was in the _layouts directory. (This makes me wonder – is this the only place where an iframe is used in SharePoint? Would something like datepicker.aspx or even datepickeriframe.aspx not have been a more obvious name?)
Anyway, so it’s in the _layout directory. It’s trivial to change it so that it also uses my stylesheet – but that will change it farm-wide, or configuration changes. I guess I’ll be looking at kb-944105 how to customize application pages in the layouts folder in wss 3 and moss 2007.
Edit: Michelle has an excellent suggestion, and she’s blogged about it here. It’s still a hack, really, but there are worse ones!
