Prevent adding of nodes to a TreeNode?
-
I have been researching a solution to this and have not found an answer so I thought I would ask it here. I have an application that derives from System.Windows.Forms.TreeNode for a few of the classes. I want to create a "lockable" tree node for the base nodes of my tree which ensures that programmers don't accidentally (or purposefully) modify the nodes once they are "locked" because the base nodes are "immutable" while the rest of the tree is not. However, since I cannot derive from TreeNodeCollection and there is no c# equivalent of the C++ const method contract (that I have been able to find for properties), I am having trouble coming up with a way to prevent the following from happening:
someInstanceOfMyLockableTreeNodeClass.Nodes.Add("newNode")
The only thing I can think of is possibly hiding the original Nodes Property (using the new keyword) with a less accessible one (if that would even work). The problem is that I would no longer be able to access the node indexer either... so I would have to create a less intuitive wrapper for that as well. Is there a different approach that I could use?
-
I have been researching a solution to this and have not found an answer so I thought I would ask it here. I have an application that derives from System.Windows.Forms.TreeNode for a few of the classes. I want to create a "lockable" tree node for the base nodes of my tree which ensures that programmers don't accidentally (or purposefully) modify the nodes once they are "locked" because the base nodes are "immutable" while the rest of the tree is not. However, since I cannot derive from TreeNodeCollection and there is no c# equivalent of the C++ const method contract (that I have been able to find for properties), I am having trouble coming up with a way to prevent the following from happening:
someInstanceOfMyLockableTreeNodeClass.Nodes.Add("newNode")
The only thing I can think of is possibly hiding the original Nodes Property (using the new keyword) with a less accessible one (if that would even work). The problem is that I would no longer be able to access the node indexer either... so I would have to create a less intuitive wrapper for that as well. Is there a different approach that I could use?
-
I have been researching a solution to this and have not found an answer so I thought I would ask it here. I have an application that derives from System.Windows.Forms.TreeNode for a few of the classes. I want to create a "lockable" tree node for the base nodes of my tree which ensures that programmers don't accidentally (or purposefully) modify the nodes once they are "locked" because the base nodes are "immutable" while the rest of the tree is not. However, since I cannot derive from TreeNodeCollection and there is no c# equivalent of the C++ const method contract (that I have been able to find for properties), I am having trouble coming up with a way to prevent the following from happening:
someInstanceOfMyLockableTreeNodeClass.Nodes.Add("newNode")
The only thing I can think of is possibly hiding the original Nodes Property (using the new keyword) with a less accessible one (if that would even work). The problem is that I would no longer be able to access the node indexer either... so I would have to create a less intuitive wrapper for that as well. Is there a different approach that I could use?
Before I switched to using the Integral UI TreeView (Lidor Systems) [^], I used the following strategy to wrap the native WinForm TreeView in a way that let me do multiple selection: 1. a UserControl 'TreeXHost in which a WinForm TreeView 'WFTree is docked 'Full: 'WFTree is set to DrawMode 'OwnerDrawText. WFTree is declared 'private. 1.a when 'TreeXHost loads: the instance of the WinForm TreeView, is passed into a class 'TreeX, a pretty standard tree implementation. 2. in 'TreeX : event handlers are wired up for all the TreeView events 2.a a variety of Dictionaries and Lists were used to keep track of state and enable custom node (not inheriting from WF TreeNode) <=>to WF Node lookup:
public Dictionary AllNodes { set; get; }
public Dictionary AllTreeNodes { set; get; }public Dictionary TNodeToNode { set; get; }
public Dictionary NodeToTNode { set; get; }public List DisabledNodes { set; get; }
public List SelectedNodes { set; get; }So the basic idea was to isolate the WinForm TreeView completely, and present an API to use that behind the scenes inter-oped with the WinForm TreeView. There were several reasons I chose not to sub-class the WF TreeView or TreeNode: of course, the issue/danger of exposing the "can't inherit from" TreeNodeCollection; the need to add some complex annotations to each node; ease of writing a serialize/deserialize facility, etc. Yes, indeed. it got tricky: I ended up canceling every WF TV Event I could in the 'Before... Event Handlers; in the DrawNode Event you need to color the Node, or otherwise alter the TreeNode appearance based on its state. A design issue was whether disabling/enabling a Node with a non-empty TreeNodeCollection should recursively disable/enab;e every Node "under" it: I decided that was necessary. Not to mention issues of drag-drop :) It got so tricky I went looking for a 3rd. party Treeview that I could afford ... and, I found the IntegralUI TreeView that was (and, still is) quite remarkable Hope this is helpful.
«... thank the gods that they have made you superior to those events which they have not placed within your own control, rendered you accountable for that only which is within you own control For what, then, have they made you responsible? For t
-
Before I switched to using the Integral UI TreeView (Lidor Systems) [^], I used the following strategy to wrap the native WinForm TreeView in a way that let me do multiple selection: 1. a UserControl 'TreeXHost in which a WinForm TreeView 'WFTree is docked 'Full: 'WFTree is set to DrawMode 'OwnerDrawText. WFTree is declared 'private. 1.a when 'TreeXHost loads: the instance of the WinForm TreeView, is passed into a class 'TreeX, a pretty standard tree implementation. 2. in 'TreeX : event handlers are wired up for all the TreeView events 2.a a variety of Dictionaries and Lists were used to keep track of state and enable custom node (not inheriting from WF TreeNode) <=>to WF Node lookup:
public Dictionary AllNodes { set; get; }
public Dictionary AllTreeNodes { set; get; }public Dictionary TNodeToNode { set; get; }
public Dictionary NodeToTNode { set; get; }public List DisabledNodes { set; get; }
public List SelectedNodes { set; get; }So the basic idea was to isolate the WinForm TreeView completely, and present an API to use that behind the scenes inter-oped with the WinForm TreeView. There were several reasons I chose not to sub-class the WF TreeView or TreeNode: of course, the issue/danger of exposing the "can't inherit from" TreeNodeCollection; the need to add some complex annotations to each node; ease of writing a serialize/deserialize facility, etc. Yes, indeed. it got tricky: I ended up canceling every WF TV Event I could in the 'Before... Event Handlers; in the DrawNode Event you need to color the Node, or otherwise alter the TreeNode appearance based on its state. A design issue was whether disabling/enabling a Node with a non-empty TreeNodeCollection should recursively disable/enab;e every Node "under" it: I decided that was necessary. Not to mention issues of drag-drop :) It got so tricky I went looking for a 3rd. party Treeview that I could afford ... and, I found the IntegralUI TreeView that was (and, still is) quite remarkable Hope this is helpful.
«... thank the gods that they have made you superior to those events which they have not placed within your own control, rendered you accountable for that only which is within you own control For what, then, have they made you responsible? For t
Thanks for the info! It was helpful for future reference. For my current solution, I decided to use the hiding technique after evaluating my code and realizing I was over-complicating what I needed to do (due to having a separate artificial "node" class where I didn't need one). But yeah... the capabilities of your link look promising if I need a more robust tree in the future. I am curious about the filtering though. Do you know if the filtering capabilities allow for you to hide or show nodes of a certain type?
-
Thanks for the info! It was helpful for future reference. For my current solution, I decided to use the hiding technique after evaluating my code and realizing I was over-complicating what I needed to do (due to having a separate artificial "node" class where I didn't need one). But yeah... the capabilities of your link look promising if I need a more robust tree in the future. I am curious about the filtering though. Do you know if the filtering capabilities allow for you to hide or show nodes of a certain type?
@primem0ver One further comment: If you implement, as I described, a kind of parallel tree class which manages an internal WF TreeView, then hiding Nodes is relatively simple, but: The trade-off is that you'll have to re-render the WF TreeView every time you hide nodes, or show hidden nodes: imho, depending on frequency of hide/show calls, and your hardware, that might result in lower performance.
«... thank the gods that they have made you superior to those events which they have not placed within your own control, rendered you accountable for that only which is within you own control For what, then, have they made you responsible? For that which is alone in your own power—a right use of things as they appear.» Discourses of Epictetus Book I:12
-
@primem0ver One further comment: If you implement, as I described, a kind of parallel tree class which manages an internal WF TreeView, then hiding Nodes is relatively simple, but: The trade-off is that you'll have to re-render the WF TreeView every time you hide nodes, or show hidden nodes: imho, depending on frequency of hide/show calls, and your hardware, that might result in lower performance.
«... thank the gods that they have made you superior to those events which they have not placed within your own control, rendered you accountable for that only which is within you own control For what, then, have they made you responsible? For that which is alone in your own power—a right use of things as they appear.» Discourses of Epictetus Book I:12
Ok. That actually sounds fine. It won't be a big deal because the hiding of nodes is not depending on searching which can change as you type. It is dependent on what kind of nodes the user is trying to view... (almost like a file type filter) so changing that is not something that happens every second.
-
Ok. That actually sounds fine. It won't be a big deal because the hiding of nodes is not depending on searching which can change as you type. It is dependent on what kind of nodes the user is trying to view... (almost like a file type filter) so changing that is not something that happens every second.
I'm working on an article for CP about a set of useful generic hierarchy extensions ... stay tuned. As part of the article, I will show an example of hiding Nodes, and re-showing them, on demand. cheers, Bill
«... thank the gods that they have made you superior to those events which they have not placed within your own control, rendered you accountable for that only which is within you own control For what, then, have they made you responsible? For that which is alone in your own power—a right use of things as they appear.» Discourses of Epictetus Book I:12