locked
Instructions for using the TreeView adapter RRS feed

  • Question

  • User-534056067 posted

    The beta 2 release of the CSS Friendly ASP.NET 2.0 Control Adapter kit supports more sophisticated features for the TreeView than previous releases.  There are, however, a few limitations:

    SelectedNodeChanged

    If you wish to handle the TreeView's SelectedNodeChanged event, you must add a new attribute called OnAdaptedSelectedNodeChanged to your <asp:TreeView> tag. Set OnAdaptedSelectedNodeChanged equal to the name of a PUBLIC (!!!) function of your page that acts as the event delegate. Typically, you will end up with like this:

    <script runat="server">
        public void OnClick(Object sender, EventArgs e)
        {
            // do something with foobar.SelectedNode
        }
    </script>
    <asp:TreeView ID="foobar" runat="server" OnSelectedNodeChanged="OnClick" OnAdaptedSelectedNodeChanged="OnClick" />


    TreeNodeCheckChanged

    The TreeNodeCheckChanged event is handled by the adapter in a fashion that parallels the SelectedNodeChanged event. In other words, when using the TreeView adapter, you should add OnAdaptedTreeNodeCheckChanged as a TreeView tag attribute and it should be set to the name of a PUBLIC function in the page that handles the event.

    <script runat="server">
        public void OnCheckChanged(Object sender, TreeNodeEventArgs e)
        {
            // do something with e.Node
        }
    </script>
    <asp:TreeView ID="foobar" runat="server" OnTreeNodeCheckChanged="OnCheckChanged" OnAdaptedTreeNodeCheckChanged="OnCheckChanged" ShowCheckBoxes="Leaf">

    To reiterate, to handle the TreeView's SelectedNodeChanged or TreeNodeCheckChanged events you must use a new attribute called OnAdapted[eventname].  And that attribute must be set to the name of a public (not protected) function that belongs to the page owns the TreeView.

    Interestingly, the adapted Treeview handles the TreeNodePopulate event normally so you do not need to add any special attribute like OnAdaptedTreeNodePopulate to handle it.  You can use the typical OnTreeNodePopulate attribute or set the delegate programmatically.  Further, the delegate function need not belong to the page and can be protected, if you like.

    Friday, September 8, 2006 12:09 PM

All replies

  • User1281392227 posted

    These notes are very helpful, however:

     I am using a TreeView in a CompositeControl implemented in a DLL. Adding the CSS Adapters to the project breaks the TreeNodeCheckChanged event.

    How do I add the adapted tree node event from the code behind?

    Sunday, November 2, 2008 3:27 PM
  • User1265453780 posted

    Hi Russ

    What´s the point of creating alternative event handlers? Why not just use the existing ones? Shouldn't one of the goals of a control adaptor be to not alter either the base control's functional behaviour or it's API? That way it makes it easier to plug the adaptor in to existing projects that use the control without having to rework them.

     

    Tuesday, November 18, 2008 5:12 AM
  • User-534056067 posted

    I agree. The alternative event handlers are an imposition, not an advantage. And they do make it more difficult to plug the adapters into existing projects. Trust me, if I could have figured out a way to avoid this alternative event handlering architecture I would have. There are some limitations around what the ASP.NET adapter framework supports and what it doesn't. Events overrides are not one of the things that are built into the adapter architecture. In fact, it's what I would consider to be the highest priority missing feature but I'm not sure if the team will address it any time soon.

    The adapted events I created were simply my best shot at solving this gnarly problem. They weren't intended to be better than the native event handlers. They were meant to simply provide a scheme that would work.

    If you are curious about why I had to use a different name for the event or other details of the implementation I'm afraid I'll have to think about it a lot more. I solved this problem in this project quite a while ago. I think I chose to name the events uniquely like this because I couldn't count on the event handler being stipulated as an attribute of the adapted controls' tag. And I couldn't get to the delegate point itself from the code level. By making a unique/parallel set of pseudo-events like I did for these adapters you end up forcing the developer to provide the right information (the pointer to the function that handles the event) in all cases. The downside, of course, is that the developer has to tweak code, not just plug in the adapters and go. On the other hand, there is already a lot of work involved in using these sample adapters so adding parallel events didn't seem like too big a stretch! I do regret, though, that I couldn't find a more elegant and seamless solution. Do forgive me!

    Best regards... PS I rarely monitor this forum any more. Apologies but my plate if quite full with unrelated stuff these days: I'm the web dev for http://www.microsoft.com/silverlight. So if you don't hear from me here reliably please don't be disappointed. I can only spare so much bandwidth for so many things! Good luck...

    Tuesday, November 18, 2008 10:38 AM