 |
Infralution Support
Support groups for Infralution products
|
| View previous topic :: View next topic |
| Author |
Message |
jayw
Joined: 11 Apr 2007
Posts: 8
|
 Posted: Wed Apr 11, 2007 5:43 pm Post subject: ChildProperty and generic collections problem |
 |
|
Hello,
I'm running into a problem where I bind the data source for the tree to an object and set its ChildProperty to a generic collection (specifically the Values list from a SortedList<> collection). What ends up happening is the root node displays but none of the children display.
To reproduce you can easily modify the Simple Tree Sample you provide like so...
In Part.cs...
Change the collection type from an Arraylist to a SortedList
| Code: |
using System.Collections.Generic;
...
private Part _parentPart;
private SortedList<string, Part> _childParts = new SortedList<string, Part>();
private string _name;
|
Modify the constructor so the collection gets a key
| Code: |
public Part(Part parent, string name)
{
_parentPart = parent;
_name = name;
if (_parentPart != null)
{
parent._childParts.Add(name, this);
}
}
|
Change ChildParts property to return the Values of the SortedList
| Code: |
public IList<Part> ChildParts
{
get { return _childParts.Values; }
}
|
Compile and run. Any idea why the children are not displaying?
Thanks,
Jay |
|
| Back to top |
|
 |
jayw
Joined: 11 Apr 2007
Posts: 8
|
| Posted: Wed Apr 11, 2007 5:49 pm Post subject: |
|
|
| I think I see the problem now that I dig into the interfaces a little more. IList and IList<> are quite different. If VirtualTree makes use of any routine other than Item, IndexOf, Insert or RemoveAt, the generic interface is insufficient. Is that correct? |
|
| Back to top |
|
|
jayw
Joined: 11 Apr 2007
Posts: 8
|
| Posted: Wed Apr 11, 2007 9:02 pm Post subject: |
|
|
Even though changing the SortedList<> to a SortedList (not generic) worked for the simple tree sample, it doesn't seem to do the trick for the code I'm working on. The main difference is that on my code I'm creating an inherited hierarchy of nodes as each is slightly different. I used the designer to autogenerate the tree from the BaseNode type.
BaseNode (Parent, ChildNodes, and data properties are here)
- FolderNode
--- BankNode
- SampleNode
- PlatformNode
In my form initialization code I do something like this, following the call to InitializeComponent...
| Code: |
PlatformNode root = new PlatformNode(null, "root");
FolderNode sub1 = new FolderNode(root, "sub1", @"C:\");
FolderNode sub2 = new FolderNode(sub1, "sub2", @"C:\sub");
m_tree.DataSource = root;
|
...but when the app runs in this case, only the root node is displayed, and none of the additional colums display the field values.
If I make the root node a BaseNode type instead of a PlatformNode type, then it displays the children, but only the field values for the root node are displayed.
And finally if I make all of the nodes (root and subs) a BaseNode type, then it displays correctly, but I loose the extra features of the inherited nodes.
It seems that there's some issue with inheritance and reflection that's keeping my tree from displaying correctly. Any ideas? |
|
| Back to top |
|
|
jayw
Joined: 11 Apr 2007
Posts: 8
|
| Posted: Wed Apr 11, 2007 9:38 pm Post subject: |
|
|
Sorry, I keep answering my own questions, but I hope this information helps others later.
I found that when using the designer to auto generate my tree, it did not find the BaseNode type that I had created, so I would type it in like so...
namespace1.namespace2.BaseNode
That would create the columns and the object binding that I needed, even the ChildProperty and ParentProperty drop down lists would be populated with poperties from the BaseNode class.
The problem lies in the TypeName property of the object binding. If it does not include a comma followed by the object's immediate parent namespace the tree won't display the tree correctly. In my case I had to change the TypeName value to...
namespace1.namespace2.BaseNode, namespace2
I did try typing it that way when I auto generated the binding but it threw up an error saying that it could not find the type, so it's a step you'll need to do manually AFTER auto generating your binding. Kind of a pain in the butt, is there another way around this problem? |
|
| Back to top |
|
|
Infralution
Joined: 28 Feb 2005
Posts: 5027
|
| Posted: Wed Apr 11, 2007 10:35 pm Post subject: |
|
|
The initial problem with using the SortedList generic class is due to the fact that the SortedList generic class does not implement the IList interface. Other generic list collections do implement this interface. If you use a generic List<Part> then the code will work fine. One way around this problem is to build a simple wrapper class that does implement IList and pass an instance of the wrapper to the tree as the child list.
I would have expected that using the fully resolved type name would have worked the same for both the AutoGeneration and binding - since it uses essentially the same code. One trap is that if the type is built in the same assembly as you are working in then you need to make sure that you have compiled the assembly successfully before using the Auto Generate.
_________________
Infralution Support |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
