possible bug in SPFolder? -getting InvalidOperationException when accessing list

Question

Hi,

Setup:
System.Web.UI.WebControls.WebParts.WebPart
WSS v3

In CreateChildControls i add a
Microsoft.SharePoint.WebControls.NewItemButton with SPControlMode.New

The button is assigned the ID from a list that is situated in the root
of the Site Collection

The web part is always using this root list also if it is called from
other sites.

Everything works fine in the root, including the "new list item"
button.

In sub sites, everything works except when i add the NewItemButton to
the control tree, i get an InvalidOperationException (Operation is not
valid due to the current state of the object).

The stack trace shows that the exception occurs in SPFolders

[7544] Exception StackTrace:    at
Microsoft.SharePoint.SPFolder.get_ContentTypeOrder()
[7544]    at Microsoft.SharePoint.SPContext.get_ContentTypes()
[7544]    at Microsoft.SharePoint.SPContext.get_ContentType()
[7544]    at
Microsoft.SharePoint.WebControls.NewItemButton.OnLoad(EventArgs e)
[7544]    at System.Web.UI.Control.LoadRecursive()
[7544]    at System.Web.UI.Control.LoadRecursive()
[7544]    at System.Web.UI.Control.AddedControl(Control control, Int32
index)
[7544]    at System.Web.UI.ControlCollection.Add(Control child)
**** cut ****

When i look at the code for get_ContentTypeOrder in Reflector it seems
that one or more of the statements doesnt match if a the referenced
list isnt available in the current site (see code below).

I havent checked the code thoroughly and since i dont have symbols for
the Microsoft.SharePoint.dll (boy would i like to get that??? :-s  ) i
cant step through the code, but it looks like a bug to me..

Could someone from the product team or support validate this?

thanx
AndersR
Creuna

public IList<SPContentType> get_ContentTypeOrder()
{
      if (this.ParentListId != Guid.Empty)
      {
            IList<SPContentType> list1 = null;
            if (this.m_htProperties != null)
            {
                  list1 = this.UniqueContentTypeOrder;
            }
            if ((list1 == null) || (list1.Count == 0))
            {
                  string text1 =
this.m_Web.GetContentTypeOrder(this.ServerRelativeUrl);
                  if (text1 == null)
                  {

this.m_Web.Request.GetFolderContentTypeOrder(this.m_Web.Url,
this.ServerRelativeUrl.Substring(1), out text1);
                        if (text1 != null)
                        {
                              list1 = this.GetContentTypes(text1);
                        }
                  }
                  else if (text1.Length != 0)
                  {
                        list1 = this.GetContentTypes(text1);
                  }
                  else
                  {
                        return this.ParentList.DefaultContentTypeOrder;
                  }
            }
            if ((list1 != null) && (list1.Count != 0))
            {
                  return list1;
            }
            return this.ParentList.DefaultContentTypeOrder;
      }
      throw new InvalidOperationException();

Answer 1

*bump*

Could someone confirm this as a bug or tell me what im doing wrong?

I'll be happy to elaborate if anything should be unclear :-)

thx

AndersR

Answer 2

Hi

It seems that the problem on the SPFolder.ContentTypeOrder occurs when you change the url of a Publishing web. I tried to changed my site url it back to the privous url and the problem was solved.

It may have to do with caching but I'm not sure and I havent been able to reproduce the error.

regards

Carsten Keutmann
iMind

 

 

Answer 3

This is not the case for me. The code is running on a WSS v3 site, not MOSS.

 

AndersR

 

ps. hej :-)

Answer 4

I'm experiencing the exact same problem. Is there a solution or is this a confirmed bug?

Answer 5

We also are having a similar problem. We changed the url of a website above the web that is experiencing this problem. ( we had http://mysite/siteA/siteB and siteB is experiencing the problem once we changed SiteA to SiteC).

 

 

Since then, in one (and only one) Document library, we cannot browse into a folder using any view based on the Standard view (but can in Explorer View), and cannot create folders either.  (I COULD create a folder by using Windows Explorer's My Network Places and creating the folder there, but still couldn't browse to the new one on the website through the browser)

 

And also, once we reverted the supersite's name back to what it was, it all worked again.

 

Can't find any other information besides this post so I guess we'll be opening a ticket.

Answer 6

A few days ago I ran into the same problem:

 

[SPException: Cannot complete this action. Please try again.]
   Microsoft.SharePoint.Library.SPRequest.GetFolderContentTypeOrder(String bstrWebUrl, String bstrFolderUrl, String& pbstrContentTypeOrder) +154
   Microsoft.SharePoint.SPFolder.get_ContentTypeOrder() +210
   Microsoft.SharePoint.WebControls.NewMenu.AddMenuItems() +3262
   Microsoft.SharePoint.WebControls.ToolBarMenuButton.CreateChildControls() +1350
   Microsoft.SharePoint.WebControls.NewMenu.CreateChildControls() +197
   System.Web.UI.Control.EnsureChildControls() +87
   Microsoft.SharePoint.WebControls.TemplateBasedControl.OnLoad(EventArgs e) +60
   Microsoft.SharePoint.WebControls.ToolBarMenuButton.OnLoad(EventArgs e) +52
   System.Web.UI.Control.LoadRecursive() +47
   System.Web.UI.Control.LoadRecursive() +131
   System.Web.UI.Control.LoadRecursive() +131
   System.Web.UI.Control.LoadRecursive() +131
   System.Web.UI.Control.LoadRecursive() +131
   System.Web.UI.Control.AddedControl(Control control, Int32 index) +2065605
   System.Web.UI.ControlCollection.Add(Control child) +146
   Microsoft.SharePoint.WebPartPages.ListViewWebPart.CreateChildControls() +2581

 

To recreate the problem:

- create a site

- create a doc lib under the site

- under the doc lib's advanced settings, enable management of content types

- add the doc lib web part (ListViewWebPart) to a page on the site

- edit the web part properties and set the toolbar type to Full

- go to the site settings and change the site's URL

- go back to the page with the web part -- Error!

 

Note: you might need to change the web.config to see the full stack trace. See http://blog.thekid.me.uk/archive/2007/02/15/a-solution-to-quot-an-unexpected-error-has-occurred-quot-in-wss-v3.aspx to learn how to config that.

 

Changing any of the above settings (content type management, toolbar type, site URL) back will get rid of the error. However changing these settings back was not one of my options so I looked for another workaround. I started looking at the content database and comparing the data before and after the URL change. Anyhow I found that changing the CtoOffset in the AllDocs table for the root folder (LeafName = <DocLibName>) and all of the subfolders fixed the problem. For my case the CtoOffset was set to 20, setting it to NULL worked, as well as setting it to a higher number. In my case, any number higher than 65 worked, so I ended up setting it to 1020 (so I can easily roll back if needed).

 

Here's the statement I ran:

 

UPDATE AllDocs

SET [CtoOffset] = [CtoOffset] + 1000

WHERE DirName NOT LIKE '_catalogs%' AND CtoOffset = 20

 

In my case all the folders in the doc lib had the CtoOffset set to 20 and nothing outside of the doc lib had that offset, so the WHERE condition worked for me. You might need to change it for your case (if you are ever in this situation, I hope not) to cover the right folders (leaves). Not sure if the CtoOffset also needs to be changed for files in the folders (probably not). As you can tell my UPDATE statement did that as well and I didn't have time to further experiment.

 

I don't know what CtoOffset is used for, but so far I haven't seen any side effects.

 

Also to note, this might be fixed in the WSS 3.0 SP1. I haven't confirmed this 100%, but ever since I installed it I haven't been able to recreate the problem from scratch. I can still however recreate it with a site and doc lib that were created prior to the SP1 install.

 

If you're "fortunate" enough to run into this problem, I hope the above helps. And I'm assuming Chris B opened a ticket for this bug.

 

Thanks to everyone on the thread.

 

Dennis Shtemberg

Answer 7

Instead of using NewItembutton, I suggest you use, NewMenu.  Using "NewMenu" you wont have to code a lot as NewMenu will implicitly call the NewForm.aspx. All you have to do is pass the context of the list to the NewMenu's RenderContext Property.   Another advantage of using NewMenu is, it will contain all the ContentTypes that belong to the list.

******* CODE BEGIN *******

Dim slProducts As SPList = SPContext.Current.Site.RootWeb.Lists("Products")

Dim mnuNewProduct As NewMenu = New NewMenu  'OR Dim mnuNewProduct as ToolbarMenuButton=new NewMenu

mnuNewProduct.RenderContext = SPContext.GetContext(Me.Context, slProducts.DefaultView.ID, slProducts.ID, SPContext.Current.Site.RootWeb)

Dim tbToolbar As ToolBar = DirectCast(Page.LoadControl("~/_controltemplates/toolbar.ascx"), ToolBar)

tbToolbar.Buttons.Controls.Add(mnuNewProduct)

Me.Controls.Add(tbToolbar)

******** CODE END *******

Answer 8

Hello, Thanks for your solution.  It works great for existing folders but how do you fix it for new folders that are being created in the library?  The CTOOffset goes back to the original number for new folders.
Thanks!
Jennifer