After rolling out some very complex custom site definitions, users noticed that the 'Edit in Datasheet' link was no longer available on any list toolbars. It wasn't the standard Office 2003 Pro/ActiveX Control issue - the link had simply disappeared. After beating my head against the wall in frustration for more than a week, I finally discovered the cause of this mysterious behavior.
In the original site definition, there are two settings which control the placement of web parts on a page. The first is the target web part zone, whose ID attribute is set within the target .aspx files in each list folder (such as allitems.aspx or editform.aspx). For example, the default web part zone tag looks like the following:
<WebPartPages:WebPartZone runat="server" FrameType="None" ID="Main" Title="loc:Main" />
Since the standard zones aren't very descriptive (Main, Bottom, Middle), when I create custom site definitions page layouts, I prefer to assign more descriptive names to each zone so it is apparent where they belong on the page: spsWPZ (as in Sharepoint Portal Server Web Part Zone) Left1, Top2, etc. The modified tags resemble the following:
<WebPartPages:WebPartZone runat="server" FrameType="None" ID="spsWPZ_Top2" Title="Top Zone 2" />
The second setting which controls web part placement is the WebPartZoneID tag in the SCHEMA.XML file for each list type. This tag is applied to the individual list views, telling the system where to place each one on the page. The setting matches the target zone ID, so the original would have been WebPartZoneID="Main" while the modified setting is WebPartZoneID="spsWPZ_Top2". Example:
<Form Type="DisplayForm" Url="Forms/DispForm.aspx" WebPartZoneID="spsWPZ_Top2">
When these two settings do not match, the user sees the "One or more web parts on this page references a zone that doesn't exist. It has been moved to the Web Part Page Gallery" message. I discovered that when you drag and drop a part from the gallery to the page, it no longer retains the "Edit in Datasheet" function, even if the base site definition has not been modified (i.e. the zone still has ID="Main"). What Sharepoint does when you're not looking is change the ID of the Web Part Zone to "__WebPartPageLibraryZone__" but it only does so if either a) the original zone id is not equal to "Main" or b) the part was not created programmatically when the list was instantiated. After further investigation, I learned that the only case in which SPS retains the original zone id is if the id is equal to "Main" in both the .aspx file and SCHEMA.XML.
So what's the moral of this story?
Edit in Datasheet with only work if your target web part zone ID="Main". Somebody decided in a stroke of pure genius to hardcode the zone id into the DLL. Not the best way to enable customization, if you ask me. If you've already deployed a custom definition with modified zone id's, you're stuck - changing the id's after the fact will banish all your list views and other web parts into the web part page gallery. Of course, you can always create a datasheet view manually for each list - a pain, but it does work. Until Microsoft fixes this glitch, the best bet would be to set the id for the primary web part zone in your custom layout to "Main" before deploying the definition.
Further evidence that Microsoft isn't joking when they warn us never to modify existing definitions...
Update: Turns out that Datasheet views and the 'Main' web part zone have a strange relationship. A datasheet view in that zone by default does not have a title bar and turning it on won't have any effect...but, when it's moved to any other zone - voila! - the title bar appears. Strange, no? I suppose this has something to do with the fact that 'Main' is typically reserved for list pages (allitems, editform, dispform, etc.) so it was hard-coded not to display web part titles (the same thing happens with any web part placed in the 'Main' web part zone).
