- The Tree Control
- Tree Appearance
- The TreeNode Interface
- The MutableTreeNode Interface
- The DefaultMutableTreeNode Class
- The TreePath Class
- What is a Leaf?
- Tree Expansion and Traversal
- Expanding and Collapsing Nodes under Program Control
- Tree Expansion Events
- Making Nodes Visible
- Controlling Node Expansion and Collapse
- Tree Model Events
- Implementation Plan for the File System Control
- File System Tree Control Implementation
- Using the File System Tree Control
- Custom Tree Rendering and Editing
- Customizing the Default Tree Cell Renderer
- ToolTips and Renderers
- Custom Cell Editors
- Controlling Which Nodes Can Be Edited
- Controlling Editability by Subclassing JTree
- Programmatic Control of Editors
- Editing Trees with Custom User Objects
- The valueForPathChanged Method
- The Tree Implementation
- The Cell Editor
- The Cell Renderer
- Summary
Controlling Which Nodes Can Be Edited
This simple example has a major flaw. As noted earlier, there is one editor that is shared among all of the nodes in the tree. This being the case, run the previous example again and open the tree to show the nodes for the crew of, say, Apollo 11. As you do this, be careful to click only on the expansion icons
and not on the nodes themselves or on the text, to avoid initiating the editor. Now click once on the name of any crew member and press F2. In response, you'll get the same combo box offering a choice of spacecraft! This is clearly not appropriate.
The problem here is that we have made the tree editable by calling setE-ditable(true), which allows all of its nodes to be edited. What we need is to be able to specify editability at a lower level of granularity, so that we can stop the editor appearing for specific nodes or types of node. There are two ways to do this, one of which involves subclassing JTree, the other being implemented in the tree cell editor.