SharePoint

When you want to implement a custom stsadm for SharePoint, all you realy have to do is implement the Microsoft.SharePoint.StsAdmin.ISPStsadmCommand interface. Because I develop on a machine with no SharePoint installed, I (only) copy the assemblies I need to develop locally. For the stsadm command I was working on recently (more on this in a future post) I only needed the Microsoft.SharePoint and Microsoft.Office.Server assemblies. Or at least I thought so…

While writing a custom stsadm command for SharePoint (more on that in a future post) and having to do something based on the command the user typed in, I used ToLower(CultureInfo.InvariantCulture) on the command string to be able to check without the hassle of differences in casing. When I ran code analysis on my project, I got this somewhat cryptic message:

After developing a custom Web Service to be hosted in SharePoint (based on this HowTo article on MSDN) and deploying it on a testing environment, I got some entries in the EventLog over there, stating:

It’s here: the Microsoft SharePoint Administration Toolkit. This first release contains two tools, both supported on WSS 3.0 and SharePoint Server 2007.

Batch Site Manager
From the “Move, Lock, and Delete Site Collections” page on Applications Management you can schedule bulk operations against site collections in the farm—including moving site collections between content databases (!!).

A week ago I had a nice page that was hosted in SharePoint and, among others, contained an updatepanel with a dropdownlist in it. Everything worked, and all was well. Because our testers had found some issues we had delivered two newer versions to our development environment. In the last version they found an issue that wasn’t there before: selecting a different value in the dropdown did not only update the updatepanel, but resulted in a complete postback. My first idea was: that’s an easy one, I’ll check the triggers. Boy, was I wrong…

As I said earlier, we didn’t test our solution to using the ModalPopupExtender in SharePoint in all situations. Today we made a start to do so. To indicate our successrate: we now use window.showModalDialog with some extra pages…

Getting the ModalPopupExtender from the Ajax Control Toolkit to work (decently) in SharePoint was not exactly a walk in the park. With a default SharePoint installation, the modal popup is partly positioned ‘outside’ of the page (you only see the bottom right part of the popup in the top left corner of the browser). Postbacks are not executed or executed poorly and the page gets garbled up. A possible solution for the positioning of the popup is to set the X and Y property of the ModalPopupExtender. Downside is you never know (for sure) if the popup is positioned inside the visible part of the browser because of things like non-maximized browser, different resolutions and so on.
Today we seem to have solved our issues with the ModalPopupExtender in SharePoint. We haven’t tested it in all scenario’s yet, but we’ll get to that. At this point everything looks the way it is supposed to. And it seems to work, too… ;).