Hi 
Sharepoint:Menu work fine but not TreeView
I navigate to [Site Actions] - [Manage Content and Structure] then i got a error in SiteManager.aspx page.
 
Error message:
Unknown Error

Troubleshoot issues with Windows SharePoint Services.

If I take this off      <adapter controlType="System.Web.UI.WebControls.TreeView"
               adapterType="CSSFriendly.TreeViewAdapter, CssAdapters,version=1.0.0.0,Culture=neutral,PublicKeyToken=9740903fe97f624d"/>
from CssAdapter.browser now i can navigate to [Site Actions] - [Manage Content and Structure]

Can any one help me??

I have noticed the same exact problem in our publishing site. The asp:treeView is working on our actual master.page but the [Site Actions] - [Manage Content and Structure] is broken with no helpful error message.

Anyone got any thoughts?

 -Mossman

I turned on the CallStack and now I can see the full error... someone please tell me there is an answer to this.... I SOOOOOO badly need to use the css adapters but not having this admin menu would kill it.

 The Controls collection cannot be modified because the control contains code blocks (i.e. <% ... %>).   at System.Web.UI.ControlCollection.Add(Control child)
   at CSSFriendly.TreeViewAdapter.SaveAdapterViewState()
   at System.Web.UI.Control.SaveViewStateRecursive()
   at System.Web.UI.Control.SaveViewStateRecursive()
   at System.Web.UI.Control.SaveViewStateRecursive()
   at System.Web.UI.Control.SaveViewStateRecursive()
   at System.Web.UI.Page.SaveAllState()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Troubleshoot issues with Windows SharePoint Services.

Do you have access to the actual TreeView in question? Or, is it encapsulated within some web part or assembly, etc. that you don't really have control (to the individual asp:TreeView level) over?

If you do have access to the actual TreeView then you might first simply try to add AdapterEnabled="false" to it. See http://www.asp.net/cssadapters/whitepaper.aspx#SamplesDisablingAdapters for a full description of this optional (and unsupported, experiemental) expando attribute.

If this doesn't work, can you help me understand if you have explicitly added <% somecode %> blocks within your TreeView, perhaps in some template you've defined for it.

Well, the page that is having the problem is part of the actual Sharepoint product. Honestly, I don't think I have access to that code, but perhaps I do in the 12 hive. I haven't gone that far in the investigation. In short, I haven't added anything that would cause it (other than the adapters). Basically, I turn on the adapter for treeView and the admin page crashes. Let me know if you have any other ideas.

FYI, Andrew Connell pointed me to: "/12/TEMPLATE/LAYOUTS/sitemanager.aspx" which runs that admin menu page. It seems like the offending line is:

 <a onclick='javascript:__doPostBack("<%= SmtPostBackHandler1.UniqueID %>", "Refresh=<%= TreeView1.SelectedNode.Value %>")' style="cursor:pointer"> 

 The CSS Friendly Adapters chokes on both of those <%='s, which seem to be fairly critical to the page. But I'm no expert at poking around in there. With them simply removed the menu is not posting back properly.

Any thoughts?

Ok we tried:

<a onclick='javascript:__doPostBack("<%# SmtPostBackHandler1.UniqueID %>", "Refresh=<%# TreeView1.SelectedNode.Value %>")' style="cursor:pointer"> 

Which doesn't error, but also doesn't fire the postbacks... the resultant html is this:

<a onclick='javascript:__doPostBack("", "Refresh=")' style="cursor:pointer">

 We also tried:

<a onclick='javascript:__doPostBack("<%# SmtPostBackHandler1.UniqueID #%>", "Refresh=<%#= TreeView1.SelectedNode.Value #%>")' style="cursor:pointer"> 

Which blew up with this:

c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS\SiteManager.aspx(141): error CS1040: Preprocessor directives must appear as the first non-whitespace character on a line   at System.Web.Compilation.AssemblyBuilder.Compile()    at System.Web.Compilation.BuildProvidersCompiler.PerformBuild()    at System.Web.Compilation.BuildManager.CompileWebFile(VirtualPath virtualPath)    at System.Web.Compilation.BuildManager.GetVPathBuildResultInternal(VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile)    at System.Web.Compilation.BuildManager.GetVPathBuildResultWithNoAssert(HttpContext context, VirtualPath virtualPath, Boolean noBuild, Boolean allowCrossApp, Boolean allowBuildInPrecompile)    at System.Web.Compilation.BuildManager.GetVirtualPathObjectFactory(VirtualPath virtualPath, HttpContext context, Boolean allowCrossApp, Boolean noAssert)    at System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp, Boolean noAssert)    at System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath)    at System.Web.UI.PageHandlerFactory.System.Web.IHttpHandlerFactory2.GetHandler(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath)    at System.Web.HttpApplication.MapHttpHandler(HttpContext context, String requestType, VirtualPath path, String pathTranslated, Boolean useAppConfig)    at System.Web.HttpApplication.MapHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()    at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

I'd like to go back and look more carefully at what happened when you tried the first variant listed above:

<a onclick='javascript:__doPostBack("<%# SmtPostBackHandler1.UniqueID %>", "Refresh=<%# TreeView1.SelectedNode.Value %>")' style="cursor:pointer">

This seems the most correct to me. You said that it didn't blow up but that it also didn't fire the postback properly. I want to look into that more closely with you.

Would it be possible for you to run the page without the adapters enabled (by removing the .browser file temporarily)? I'd like to know what the final HTML is that the original markup produces. In other words, when this <a> tag is in its original syntactical form, what is the HTML (character-by-character) that is produced for it? What is the resulting <a> tag that is sent to the browser?

Then, with the adapters enabled and with the server-side <a> tag modified to be in the form shown above what is the final HTML that is produced? How do they differ?

This will help us determine where the problem might be. It could, for example, be the case that the modified version of the <a> tag (above) is producing the same HTML that the original version of the <a> tag was producing (when the adapters weren't used) but that the server-side processing of the postback params being sent via __doPostBack is being impacted by the presence of the adapters.

First, though, let's make sure that the rendered HTML is equivalent both with and without the adapters in play by following the diagnostic recipe described in this post.

I have the same problem using CSSFriendly Adapters.
It seems like the problem occurs when TreeViewAdatper is trying to add HiddenField containing ViewState of a TreeView control.
I solved the problem by modifying the way TreeViewAdapter controls ViewState:
 

private string _viewState = string.Empty;

private string ViewStateID
{
    get { return Control.ClientID + "__VIEWSTATE"; }
}

....

protected override Object SaveAdapterViewState()
{
    string retStr = "";
    TreeView treeView = Control as TreeView;
    if ((treeView != null) && (_viewState != null))
    {
        if ((_viewState != null) && (Page != null) && (Page.Form != null))
        {
            Page.ClientScript.RegisterHiddenField(ViewStateID, _viewState);
            string script = "document.getElementById('" + ViewStateID + "').value = GetViewState__AspNetTreeView('" + Extender.MakeChildId("UL") + "');";
            Page.ClientScript.RegisterOnSubmitStatement(typeof(TreeViewAdapter), ViewStateID, script);
        }
        retStr = ViewStateID + "|" + ComposeViewState(treeView.Nodes, "");
    }
    return retStr;
}

Ooooo. I like this solution. Have you tested this, by any chance, with the sample pages in the kit that involve TreeView? It looks like it should be OK and not interfere with other TreeView functionality, like populate-on-demand, but I'm wondering if you've already confirmed that.

Reregistering the hidden field is a better solution than my original code because it allows the adapter to work even if other parts of the framework have already tried to set up the viewstate.

Other readers: has anyone else who has been having this problem tried this solution yet? I'm curious to know if it solves the problem uniformly.

Again, nicely done, Dmitry. You're a clever person.

Thanks! Glad to be helpful. :)
I haven't tested this solution a lot, but I think there shouldn't be any problem.

Ok, we've tried out this fix. It does get you past the most obvious problem, but there are other hidden problems in the "Site Content and Structure" pages:

 - The left nav tree links do not actually work anymore

 - You can still use the main frame to navigate to sub areas of the site (rather than using the left nav), but when you do, and then subsequently hit the "Up" folder button, you get the following error:

Object reference not set to an instance of an object.   at Microsoft.SharePoint.Publishing.Internal.CodeBehind.SmtMainPage.ObjectList_GoTo(Object sender, SMGoToEventArgs gotoEventArgs)
   at Microsoft.SharePoint.Publishing.Internal.WebControls.SMObjectList.raiseGoTo(SMGoToEventArgs e)
   at Microsoft.SharePoint.Publishing.Internal.WebControls.SMObjectList.RaisePostBackEvent(String eventArg)
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument)
   at System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData)
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

 Bottom line is that section of the admin interface uses the asp adapters in intricate ways that the CSS Friendly Adapters don't jive with. I've heard unofficially that Microsoft's stance on this problem with the adapters in SharePoint, is that they are community sourced now, so its up to us to find the solution. That's kinda lame.

 -mossman

Dmitry Karpenkov:

I have the same problem using CSSFriendly Adapters.
It seems like the problem occurs when TreeViewAdatper is trying to add HiddenField containing ViewState of a TreeView control.
I solved the problem by modifying the way TreeViewAdapter controls ViewState:
 

private string _viewState = string.Empty;

private string ViewStateID
{
    get { return Control.ClientID + "__VIEWSTATE"; }
}

....

protected override Object SaveAdapterViewState()
{
    string retStr = "";
    TreeView treeView = Control as TreeView;
    if ((treeView != null) && (_viewState != null))
    {
        if ((_viewState != null) && (Page != null) && (Page.Form != null))
        {
            Page.ClientScript.RegisterHiddenField(ViewStateID, _viewState);
            string script = "document.getElementById('" + ViewStateID + "').value = GetViewState__AspNetTreeView('" + Extender.MakeChildId("UL") + "');";
            Page.ClientScript.RegisterOnSubmitStatement(typeof(TreeViewAdapter), ViewStateID, script);
        }
        retStr = ViewStateID + "|" + ComposeViewState(treeView.Nodes, "");
    }
    return retStr;
}

 Amazing! I had a similar problem, and a quick google found this thread (the only thread) and your solution fixed it for me! thanks! you saved hours of work!

Hi I'm seeing the same problem as people earlier with MOSS2007 and these adapters in that  Site Action - Manage Content & Structure fails with the following error:

The Controls collection cannot be modified because the control contains code blocks (i.e. <% ... %>).   at System.Web.UI.ControlCollection.Add(Control child)
   at CSSFriendly.TreeViewAdapter.SaveAdapterViewState()
   at System.Web.UI.Control.SaveViewStateRecursive()
   at System.Web.UI.Control.SaveViewStateRecursive()
   at System.Web.UI.Control.SaveViewStateRecursive()
   at System.Web.UI.Control.SaveViewStateRecursive()
   at System.Web.UI.Page.SaveAllState()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Did this get resolved at all - I see that one of the solutions in this thread had knock on effects

Any ideas what to to ? 

And more recently after trying the AdapterEnabled="false" setting , I think this will stop us from using the Adapetrs unless I can get this working.

 Request failed.   at Microsoft.SharePoint.Publishing.Internal.WebControls.SMTreeView.OnInit(EventArgs e)
   at System.Web.UI.Adapters.ControlAdapter.OnInit(EventArgs e)
   at CSSFriendly.TreeViewAdapter.OnInit(EventArgs e)
   at System.Web.UI.Control.InitRecursive(Control namingContainer)
   at System.Web.UI.Control.InitRecursive(Control namingContainer)
   at System.Web.UI.Control.InitRecursive(Control namingContainer)
   at System.Web.UI.Control.InitRecursive(Control namingContainer)
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
   at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)
   at System.Web.UI.Page.ProcessRequest()
   at System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context)
   at System.Web.UI.Page.ProcessRequest(HttpContext context)
   at ASP._layouts_sitemanager_aspx.ProcessRequest(HttpContext context)
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)