Your main tree control has been a great success for displaying hierarchical relationships. It is relatively easy to recognize for beginners and is now the de facto standard for hierarchies. It is very suitable for editing relationships, especially with drag and drop. This is perhaps the only viable choice when the hierarchical depth varies arbitrarily over the object (i.e. for any object on the tree there can be children, grandchildren, great-grandchildren, etc. Up to an indefinite number of "generations".).
The primary alternative to wood is a window with master part panels. In this design, one panel contains parent objects and the other contains child objects. When a parent object is selected, the child panel fills in the child elements. If necessary, you can have panels with a large child and panels of a great child, but master parts usually work best when there is a small fixed number of layers in the hierarchy. Users edit the parent-child relationship by dragging and dropping / cutting / copying and pasting child objects both inside and between windows, similar to using a tree control.
Wizard details are usually better than trees for the following cases:
You need to show several properties or attributes with each object. For example, for this Project object, you want to specify not only the employee number for each member of the group, but also their corresponding names, roles, titles, departments and photos. Using the master part, each panel can be laid out in the form of a table or form, which will allow you to show a lot about each object. Tree controls often resort to inefficient and confusing property dialogs to accomplish this.
You need to separate the children. For example, for a given project object, you want its Team members to be separated from its project stages. Using the master part, you can have two or more child panels for one parent panel, with one panel that lists Team members, and one Stages list. It’s embarrassing to keep separate child objects separate from the tree.
You have a many-to-many relationship where each child can have multiple parents, as well as each parent with multiple children. For example, each project has several employees (as team members), but each employee can work with several projects. You can have a window with projects in the parent panel and team members in the child panel or employees in the parent panel and the project assignment in the child panel, or you can have both windows. Tree controls can confuse users when there is a many-to-many relationship, because users do not expect the same child to be under more than one parent.