After inserting a record into the grid via RowEditing and pressing cancel the RowEditings’ editor window is not shown. You guess it right: only when using Internet Explorer (7, 8, 9). After testing it showed that the css itself is not the reason. So debugging the Extjs-source where the setting scopeResetCSS is evaluated…

The final result is a workaround applied via Ext.override to solve the “problem”.

if(Ext.isIE) {
  Ext.AbstractComponent.override({
    onRender: function(container, position) {
      var me = this,
        el = me.el,
        styles = me.initStyles(),
        renderTpl, renderData, i;
 
      position = me.getInsertPosition(position);
 
      if(!el) {
        if(position) {
          el = Ext.DomHelper.insertBefore(position, me.getElConfig(), true);
        }
        else {
          el = Ext.DomHelper.append(container, me.getElConfig(), true);
        }
      }
      else if(me.allowDomMove !== false) {
        if(position) {
          container.dom.insertBefore(el.dom, position);
        } else {
          container.dom.appendChild(el.dom);
        }
      }
 
      if(Ext.scopeResetCSS && !me.ownerCt) {
 
        if(el.dom == Ext.getBody().dom) {
          el.parent().addCls(Ext.baseCSSPrefix + 'reset');
        }
        else {
          if(me.$className != 'Ext.grid.RowEditor') {
            me.resetEl = el.wrap({
              cls: Ext.baseCSSPrefix + 'reset'
            });
          }
        }
      }
 
      me.setUI(me.ui);
 
      el.addCls(me.initCls());
      el.setStyle(styles);
      me.el = el;
 
      me.initFrame();
 
      renderTpl = me.initRenderTpl();
      if(renderTpl) {
        renderData = me.initRenderData();
        renderTpl.append(me.getTargetEl(), renderData);
      }
 
      me.applyRenderSelectors();
 
      me.rendered = true;
    }
  });
}

The woraround itself is only this:

if(me.$className != 'Ext.grid.RowEditor') {
  me.resetEl = el.wrap({
    cls: Ext.baseCSSPrefix + 'reset'
  });
}

BTW: I “love” IE!

Trying the suggested solution in the blog post drove me to the cause of this problem. When using stsadm I got an “access denied” error.
I did run my script via Powershell ISE within Windows Server 2008.

So the real problem is caused, again, by UAC (User Account Control). When starting the Powershell ISE with “Run as administrator” and executing the script the feature receiver is now called as expected. Even when using Enable-SPFeature!

In case you quickly want to test if your SPSiteDataQuery is correct you can use powershell to “debug” it. Just create an instance of the site-collection and target the root-web with your query-instance.

$site = Get-SPSite -Identity http://my-site-collection
 
$q = New-Object -typeName Microsoft.SharePoint.SPSiteDataQuery
$q.Query = "<Where><And><Eq><FieldRef Name='ContentType'/><Value Type='Text'>MyCT</Value></Eq><BeginsWith><FieldRef Name='Url'/><Value Type='URL'>/path</Value></BeginsWith></And></Where>"
$q.ViewFields = "<FieldRef Name='ID'/><FieldRef Name='ContentType'/>"
$q.Webs = "<Webs Scope='SiteCollection' />"
 
$site.RootWeb.GetSiteData($q)

This is way faster than doing it in VS…

You could of course comment in and out (via ctrl + k, ctrl + c / ctrl + k, ctrl + u) the SPSchedule used by the timer-job during debug-mode. But this is error-prone.

When using a C# preprocessor directive you cannot forget to switch back to the “production schedule” as this is done automatically (and even with syntax-highlighting depending on the active configuration!) when selecting the “release build”.


#if (DEBUG)
var schedule = new SPMinuteSchedule();
schedule.BeginSecond = 1;
schedule.EndSecond = 59;
schedule.Interval = 5;
#else
var schedule = new SPDailySchedule();
schedule.BeginHour = 7;
schedule.EndHour = 7;
schedule.BeginMinute = 1;
schedule.EndMinute = 59;
#endif

This code tells the compiler to use the SPMinuteSchedule when compiling the “debug build” and to use the SPDailySchedule when compiling in “release build”. All automatically!

Object model?!

When looking into the SPFieldLookup-class you find the properties LookupField, LookupList and LookupWebId. LookupWebId and LookupField can easily be set via the object model. The documentation says that LookupList is read and writeable which is not true. Setting LookupList throws an exception stating out “Cannot change the lookup list of the lookup field.”.

SchemaXml and Regex to the rescue

The SchemaXml-property of a SPField can be used to manipulate the LookupList. One stumbling block is that you do not know the Guid of the LookupList currently stored in the schema. Even if you define a Guid inside your xml-field-definition SharePoint puts in an other Guid. Here a simple regular expression comes to help.

The code for connecting a site-column with a list somewhere in some web:

// Declarations (myWeb is the context given by a feature receiver scoped "web")
var rx = new Regex("List=\"([^\"]*)\"", RegexOptions.IgnoreCase | RegexOptions.ECMAScript);
var root = myWeb.Site.RootWeb;
 
// myListInstance is an instance of a SPList existing somewhere
var lookupField = (SPFieldLookup)root.Fields["MyLookupField"];
var xml = lookupField.SchemaXml;
xml = rx.Replace(xml, String.Format("List=\"{0}\"", myListInstance.ID.ToString("B")));
lookupField.SchemaXml = xml;
// Do not call update here!
// Quote from MSDN "Do not call the Update method when using the SchemaXml  property to modify a field."
 
// Fetch the field again and apply the web-id
var lookupFieldReFetch = (SPFieldLookup)root.Fields["MyLookupField"];
lookupFieldReFetch.LookupWebId = myWeb.ID;
lookupFieldReFetch.LookupField = "Title";
lookupFieldReFetch.Update(true);

This problem still persists in the beta of SharePoint 2010. I hope this will get fixed in the RTM. Creating a lookup-field-connection is far more easy by the way …

In a SharePoint project I’m working on it was necessary to get the default page of a publishing web in case where it differs from default.aspx.
 
In the environment the project takes place the “normal SharePoint user” is not allowed to use the SharePoint Designer. The page itself can be fully viewed by these users but the following code throws a SecurityException due to the missing “Remote interface”-permission.

// ... web is instantiated and disposed of course!
var pub = PublishingWeb.GetPublishingWeb(web);
var defaultPage = pub.DefaultPage;
 
// ....

In order to work in my projects environment this peace of code needs to be wrapped inside a resource-expensive SPSecurity.RunWithElevatedPrivileges-delegate. Makes absolutely no sense to me…

SharePoint 2010 has a lot of improvements for the “publishing infrastructure”. Lets hope this is fixed, too.

After I figured out why my first installation try went wrong I hit another strange issue.

When installing MOSS you have to choose which role your server is in. As I want to develop with BDC, Excel Services, Search Service I need to create a small farm (SQL Server running on the same machine in this case). But during the setup the “Complete Server Type” was missing!

Where are you my PDC?

I like development. So this installation took place on my home-machine which is not inside a domain.

A little while ago I installed MOSS successfully on Vista including the “complete role”. So one difference was the absence of a domain-controller …

Conclusion

After my machine became a member of a domain (and a reboot) the “Complete Server Type Role” became available during installation! SharePoint development on Windows 7 x64 is pure fun …

If you only want to display that field-value you can simply use the ControlMode-property and set it to Display. If you want to display only the date-part of that datetime just set the DateOnly-property to true…

Thats the theory. If you do it like that you get a nice Object reference not set to an instance of an object-error. The cause is

DateTimeField.set_DateOnly

Reflectoring the control reveals that when the control is in “DisplayMode” the inner DateTimeControl is not created and that is why DateOnly cannot be set.

Its seems this control was developed by a drunken programmer as my friend stated out a bug in this control a while ago.

The start is essential

I reconfigured everything, I checked the database-security, rebooted the virtual machine, re-created the content-sources. Nothing helped …

After some digging I found out that the start page of that site-collection (default.aspx) throws an exception due to a faulty web part…
This can’t be… Can it?! I removed the faulty web part from the default.aspx and the start page runs normal … and so does the crawler!

Because of an erroneous start page the whole crawling process for that site-collection is not working!

Conclusion

Make sure that the “entrance” to your site-collections is wide open and totally working …

PS: Excluding the default.aspx via “Crawl rules” does not work. The crawler still stops.

We do not support modifying a custom site definition or a custom area definition after you create a new site or a new portal area by using that site definition or area definition. Additionally, we do not support modifying the .xml files or the .aspx files in the custom site definition or in the custom area definition after you deploy the custom site definition or the custom area definition.

So site definitions are a one way ticket. All your requirements (even future ones) must be implemented before you actually create sites based on your site definition! This is far from “real life”.

This “supported and unsupported-link” is not referenced within the SDK (MOSS or WSS). The SDK describes the nice way of creating site definitions, how to deploy them e cetera. Once deployed your site definition has to be immutable! But this fact is not mentioned inside the SDK!
Even more confusion is spread when you want to lock down SharePoint Designer (which is now available for free) following Microsoft’s kb article filed under http://support.microsoft.com/kb/940958/en-us. If you read the article you will see that it suggests to modify the existing onet.xml files so that the changes also affects already provisioned sites.

Microsoft tells us that changing the site definition after sites have been provisioned with it is unsupported but on the other hand writes a kb article where site definitions should be modified to reflect changes to already provisioned sites! Another example of how difficult communication is!

Conclusion

SharePoint is a static environment when you rely on the “xml-ways” of customizing SharePoint. This issue also appears when using Content Types. Once a Content Type is deployed Microsoft “does not support” changes in the Content Type xml-definition.

What gets clear when reading the kb article (http://support.microsoft.com/kb/898631/en-us) is that changing/updating via code is always supported. Perhaps its time to move away from the xml-based declarative approach to the code-based approach.

Lets hope SharePoint 2010 will fix all these issues!