I'm having an issue with my WinTree. I have an object being used as the data source. This object has a property which is a collection of itself. The object is used to represent a category. Therefore, the child collection would be 2nd level sub categories. In my case, I need this to be 3 levels deep. This means that each child object in the parents' subcategory collection can also have a collection which would represent the 3rd level categories. When I bind my object, which is a collection of parent categories, who may or may not have 2nd level categories as well may or may not have 3rd level categories. When this tree gets rendered, I'm only able to expand to the 2nd level. There are no 3rd level categories rendered. The following are the properties I have changed on the UltraTree:
AllowDrop = True ColumnSettings.BorderStyleCell = Infragistics.Win.UIElementBorderStyle.None ColumnSettings.BorderStyleColumnHeader = Infragistics.Win.UIElementBorderStyle.None ImageTransparentColor = System.Drawing.Color.Transparent Location = New System.Drawing.Point(12, 12) Name = "treeProductCategories" NodeConnectorColor = System.Drawing.SystemColors.ControlDark Override1.BorderStyleNode = Infragistics.Win.UIElementBorderStyle.None Override = Override1 Size = New System.Drawing.Size(377, 391) TabIndex = 9 ViewStyle = Infragistics.Win.UltraWinTree.ViewStyle.OutlookExpress
Additionally I am handling the ColumnSetGenerated event only to set the following:
e.ColumnSet.LabelPosition = Infragistics.Win.UltraWinTree.NodeLayoutLabelPosition.Top
I am using NetAdvantage for Windows Forms 2011.1 CLR2. Given the above, is there any reason why the 3rd level categories would not render? Also, as another problem, if I use the ColumnSetGenerated event to iterate over the columns and remove the ones I don't want displayed, no children are displayed at all. Any help you may provide is greatly appreciated.
Thanks,
Nick
Hi Nick,
I'm not sure what good the XML would do me without the actual code for the objects.
I agree with you that the problem is probably something in the way your data objects are set up. But the fact that the structure is recursive and the problem only occurs on one level of the data is puzzling.
I'm afraid without being able to run a sample and step through the code to see exactly what the tree is asking for and what it is getting from the BindingManager and the data source, it's impossible to guess what might be going wrong there.
Mike,
I did some playing around with different scenarios for the tree. The problem with the depth appears to be something in my object. It's hard for me to really give you a code sample, because the object is rather large. It has a few layers of inheritance. So I built a couple very simple objects to test with. This test worked as desired. I can attach that code if you like, but it proves that the control works as desired, and is probably not of much value. What I think might be better is to post the serialized XML of my object. One of the tests I was doing was trying to use a dataset which was built from the ReadXML method, passing in my XML. This didn't work at all with the tree as the tree was empty. Would you like me to post that XML? Maybe you'll have better luck?
My next guess would normally be that this is a bug in the version of the tree you are using. But since you are using 11.1, that seems very unlikely.
Can you post a small sample project here demonstrating the issue? If so I'd be happy to take a look at it and tell you exactly why the tree is not getting the data. You can attach a file to your post by going to the Options tab.
Thanks for your response. For the answer about the tree depth, I had read that in the Infragistics documentation somewhere, and looked into that. What I found was that while there may not always be a 2nd or 3rd level node, the very first node (aka the first object in the collection) DOES have 3 levels of categories. So, I'm not sure what could be going on. Maybe the tree is grabbing a different object out of the collection first and it does not have the 3rd level. Either way, because of this functionality, it really prevents me from the Ronco method, set and forget, of binding to the tree. I cannot impose a requirement for there to be 3 or even 2 levels on everything. So I guess now, I'm looking for suggestions that would not have me manually building the tree.... :D. Any ideas?
As for the second part of my question, your answer was dead on! I added the check and now my desired columns are the only ones shown and I can expand them. Thanks again for your help on this!
This might be a problem with your data source. The data structure in the tree is determined by the BindingManager in DotNet. If you have an object that returns a property which is of type IList or IBindingList, then the way the BindingManager gets the structure is by looking at the current item in the list. This is usually the first item.
So let's say you bind the tree to a list and that list has a few root-level items in it. From that, the tree can determine the structure of the data at the root level. It then walks down to the second level under the first root item and tries to get the structure of the second level from that. Then it looks for a child of that item to determine the structure of third level.
If is so happens that it hits an item that has no children, it cannot determine the data structure for that level and it assumes that there is no data at that level for ANY nodes. In other words, the entire data structure is based on the first root item, it's first child, the first child of that child, etc.
That's one reason why the behavior you describe might occur, anyway. How many times is the ColumnSetGenerated event firing? Is the tree creating a new ColumnSet for each level, or it is using one ColumnSet for the whole tree?
njtrentacoste said:if I use the ColumnSetGenerated event to iterate over the columns and remove the ones I don't want displayed, no children are displayed at all.
The child band is represented in the ColumnSet by a column. So you are probably removing the child band column without realizing it. Check the IsChaptered property of the column. If IsChaptered is true, then the column represents a child band and you probably don't want to remove it.