A TreeView combined with ListViews? No way! Well, here it is. Drawn 100% using Graphics. You can even draw this transparently on top of other controls!
There are still some bugs to iron out, such as:
- I have not actually added the "expand"/"retract" arrows yet.
- There are no scroll bars.
- You can only add nodes at runtime.
And probably more. I'm working on it
I'm building this for a better version of Windows Explorer I call QExplorer.
Last edited by minitech; Jun 10th, 2010 at 09:09 PM.
The awkward node constructor is not required. The TreeListNodeCollection already has a reference to the parent TreeList, so can't you just set the parent of each node when it is added, in the Add method?
Also, you can add the same node to the TreeList multiple times. I don't know if that is desirable (it could be I suppose), but right now all instances of the same node will be expanded/collapsed and selected at the same time. That is a bit strange I think. Not sure how you could handle that though, except not allowing the same item to be added twice.
No, I know, and that's on purpose. Don't you think it's useful? It's also why I implemented ICloneable. I considered it a feature, not a bug!
A big problem, though, is making a node its own parent, or making its parent its child. I'm having trouble figuring that one out, but I think I'll just let it slide for now. It's not a priority.
Yeah, modifying the TreeListNode collection is the next thing I'll do. I'm going to change it to be event-based, too, to give it less awkwardness, to give it more versatility, and to make it designable.
Finally, I'm going to add scroll bars (easy), arrows (easy), and I'm going to merge the Designer file with the code file because the designer file is useless. Coming soon!
I see. I can't think of any use for having the same node twice and having it mirror whatever you do to the other node, but someone else might so I suppose it's not a problem.
For the collection, why not inherit System.Collections.ObjectModel.Collection(Of TreeListNode) instead? For default implementation, you won't even need to implement or override anything, and it will behave like a strongly typed collection automatically. If you want, you can override four methods (SetItem, RemoveItem, ClearItems and InsertItem I believe) to do some extra stuff, like raising a 'collection changed' event.
Unfortunately, making things this way made it much too complicated to get everything working properly and I am reverting back to a mix of versions 1 and 3.