Hi, I'm trying to bind a XamDataTree recursively, and I'm encountering some strange problems. My tree will contain objects of type "MenuAction" and "MenuGroup", which both inherit from abstract base class "MenuItem". The actions represent buttons that can be executed, and the groups are folders that can contain actions and subfolders. I have included a sample to illustrate this. If you start the sample, you will see the groups in blue, and actions in red. The first time you start the sample you will see how it should work and there aren't any problems just yet. Expand the nodes so you see the structure of the groups and actions.
Now, open the MenuItem.cs class. You will see that there are 2 properties, one called Children and one called AllChildren. Children will return direct children, AllChildren will return both direct and recursive children. The treeview should use the property called "Children", the AllChildren property is meant for other code in the real application. If you look at MainWindow.xaml, you will see that I created a global NodeLayout with the "Key" property set to "Children". According to the following article, the Key property should be used to set the property that will retrieve child nodes recursively:
http://ko.infragistics.com/community/forums/t/51896.aspx
And I quote: "MyCollectionProperty - the property that contains the data items for the corresponding level".
Ok, so let's get to the problem. Go back to the MenuItem.cs class. You will see that property AllChildren is defined twice (once it is commented out). Uncomment these lines, and comment out the AllChildren property that is below. Do the same thing for the MenuGroup.cs class, where the AllChildren property is being overridden. So essentially, we're only changing the LOCATION of the AllChildren property within code, we're not changing any logic. Now run the sample again. If you expand all nodes, you will see that the node layout is completely messed up. It seems the XamDataTree is now using the AllChildren property to fill its nodes instead of the Children property, even though I have set the Key property correctly. It seems the XamDataTree simply searches for the first property it can find and blindly uses that one. I don't even know how the XamDataTree knows about the AllChildren property! Does it use reflection or something? What kind of strange behavior is this? This is completely insane if you ask me! Perhaps the "Key" property is NOT the right one to use in contrary to what Stoimen Gerenski said in the forum post? But then I can't seem to find another property that would fit (or I'm just failing to see):
http://help.infragistics.com/Help/Doc/WPF/2014.2/CLR4.0/html/InfragisticsWPF4.Controls.Menus.XamDataTree.v14.2~Infragistics.Controls.Menus.NodeLayout_members.html
One more important side note; this sample is still running on an older version of Infragistics (2014.2), so I'm not sure whether this problem still exists on the latest version.
I also added some screenshots in the sample that show what I see.
Can you provide any help?
Kind regards, Stefan
Hi Stefan,
I'm not sure if this was changed at all since Stoimen made that post in 2011 but looking at the source code right now for 14.2 and up, we use reflection to find the first IEnumerable in the data class and we use that for the node child data. The Key property is not used for that purpose. So that explains the behavior that you are seeing. I recommend submitting a product idea for us to add a property to the NodeLayout called something like ChildrenMemberPath so that users can explicitly declare what property they want to use for child data. You can do this here: http://ideas.infragistics.com
For now it seems you will have to order your collection properties so that your Children property is before AllChildren.
Hi Rob,
Thank you for looking into this. Your explanation clears thing up. I created a product idea like you said and I really hope this is going to be implemented. I just lost half a day trying to find out what was wrong with my application, so the addition of such a property would really help.