locked
Problem with TreeView in Sharepoint 2007 RRS feed

  • Question

  • User-384796688 posted

    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??



    Wednesday, December 6, 2006 5:50 PM

All replies

  • User-875658902 posted

    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

    Wednesday, March 7, 2007 5:20 PM
  • User-875658902 posted

    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.

    Wednesday, March 7, 2007 5:43 PM
  • User-534056067 posted

    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.

    Thursday, March 8, 2007 12:16 PM
  • User-875658902 posted

    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.

    Thursday, March 8, 2007 4:37 PM
  • User-875658902 posted

    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?

    Friday, March 9, 2007 2:03 PM
  • User-534056067 posted
    You might want to try using <%# rather than <%= in that situation. Can you give that a shot?
    Friday, March 9, 2007 2:33 PM
  • User-875658902 posted

    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)

    Friday, March 9, 2007 4:01 PM
  • User-875658902 posted
    Anyone have any idears? Its pretty much stopped us from using the adapters in MOSS.
    Thursday, March 22, 2007 10:55 AM
  • User-534056067 posted

    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.

    Thursday, March 22, 2007 11:35 AM
  • User-875658902 posted
    Thanks for sticking with me Russ! I'll try it out tomorrow and let you know what I find out.
    Tuesday, March 27, 2007 12:02 AM
  • User1407122181 posted
    The issue with the page can be resolved by subclassing the CSS Friendly Controls.  Then changing the reference to those controls in the Admin pages.  We can get the page to load that way.  That solves the issue of the page loading -- but that doesn't resolve the entire issue.  There's more going on than just one page not loading.
    Tuesday, March 27, 2007 9:44 AM
  • User1752904022 posted

    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;
    }
     

     

     

    Wednesday, April 4, 2007 8:36 AM
  • User-534056067 posted

    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.

    Wednesday, April 4, 2007 1:34 PM
  • User1752904022 posted

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

     

    Thursday, April 5, 2007 7:32 AM
  • User-875658902 posted
    I had to focus away from the problem for a while... looks like it may be time to re-investigate it. I'll let you know if we can get it working via this method.
    Monday, April 9, 2007 5:54 PM
  • User-875658902 posted

    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

    Wednesday, April 11, 2007 11:38 AM
  • User55416775 posted

    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!

    Thursday, May 3, 2007 1:15 PM
  • User1336840368 posted

    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 ? 

     

    Tuesday, July 24, 2007 6:33 AM
  • User1336840368 posted

    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)

     

    Tuesday, July 24, 2007 9:00 AM
  • User-1896143732 posted

    I had a similar problem and I was able to fix it with web.config inheritance. This is not a permanent fix, but it does the trick until CSS Friendly Adapter gets improved.

    Check my thread: http://forums.asp.net/p/1142324/1864479.aspx#1864479 

     

    Friday, August 17, 2007 9:12 PM