[Bug: JClient tree binding] Workaround for 'random' collapsing of branches

Question

Hi all.. For those of you who have been bothered by a bug in the JClient tree binding model regarding (seemingly) random collapsing of branches, I have a small workaround which may brighten your day. I know it brightened mine. :)
Anyways, here's my situation:
- A JTree with a master VO ("MasterView", for the top) and a detail VO ("DetailView", for the 'body'), recursively bound.
- A JComboBox bound to a VO ("TopsView" or whatever), which is used to 'select a tree'
- When a the currency of TopsView is changed, the selected row's ID is used to build a new tree. I use my own simple synchronizing mechanism, so I can do some additional checks. I suppose you could make MasterView a detail of TopsView, but that's not really important.
masterView.setWhereClause("ID = " + selID);
masterView.executeQuery();At this point, the tree will automatically be rebuilt.
However, based on my experiences, I figure that this is not really the way the JDev guys pictured how I'd work because there's a pretty huge bug which at some point pretty much makes the tree useless (or 'act weird' to say the least).
Here's a description of how to reproduce the bug and some of my observations. I will refer to the collection of currently displayed nodes/records as 'tree'.
1. When you first expand certain branches in the current tree, all goes well. No problems.
2. Next, you use the JComboBox to select another tree. (The new tree will appear totally collapsed.)
3. At this point, you will also be expanding branches 'in that tree', 'for the first time'.
4. After that, you switch back to the first tree.
5. Now it becomes interesting: when you expand ANY branch that you previously expanded in this tree, the bug will surface (details will follow). When you expand branches that you DID NOT expand during your last visit to this tree, all goes well -- no problems.
Note that re-expanding a branch after manually collapsing it, does not cause the bug. The key is that you expand a branch for the first time during a 'visit' to this tree (ie, so that it has to gather it's child nodes).
Details about the bug:
- The problem surfaces when expanding certain branches. (See above.)
- Effects will vary from collapsing different branches under the same parent node to collapsing the entire tree.
- The selection in the JTree component (or its selection model, if you will) will also be canceled.
Observations:
- It seems that JClient was not designed to handle multiple trees (as described above). It appears that, before the newly selected tree is built, the old tree has not been properly cleaned up. By this I mean the collection of JUTreeNodeBinding objects, which continue to refer to DefaultMutableTreeNodeBinding objects of the destroyed tree. In effect, these orphaned objects continue to work their magic in the background and will influence the JTree and its associated objects in a way so that this problem (and possibly others) surfaces.
The workaround I will present below is designed to suppress this problem. It does not deal with orphaned objects in a proper way, it will merely partially suppress their functionality.
How to suppress the bug:
- In case you haven't done so already, you have to copy the source file of oracle.jbo.uicli.jui.JUTreeNodeBinding into your project directory and then make small modification to it.
- On line 482 (if I'm not mistaken), you will see //if (al.size() > 0) Change it to if (!(mTreeNode.getParent() == null && getParent() != null)) Now the enclosed code will only be executed when the tree is fully synchronized (as in: the 'tree' of JUTreeNodeBinding objects has the same structure as the 'current tree' of DefaultMutableTreeNodeBinding objects).
In a nutshell, it checks whether the parents of this JUTreeNodeBinding object and the associated DefaultMutableTreeNode object are not null. Because in case it concerns an 'orphaned' JUTreeNodeBinding object, the parent of its associated DefaultMutableTreeNode object will be null. However, in case it concerns the tree's root node, both parents will be null, in which case this condition will have to evaluate to true as well.
I hope that this information will be of use to others :) and that possibly someone of the JDev team could comment on this matter. Thanks.

Answer 1

One question though. What exactly do you mean by 'copy
the source file of
oracle.jbo.uicli.jui.JUTreeNodeBinding into your
project directory'.. would I need to change the package
name of this binding, and modify the client code
somewhere to have it use my modified version? Or will
it use this local copy instead of the original one?The simplest way to go is to create a new (empty) class in your project, which is to be located in the package "oracle.jbo.uicli.jui", and name it "JUTreeNodeBinding". Next, open the source of the original JUTreeNodeBinding class and copy-paste it into your newly created class in JDeveloper.
Now, when you run your application, it will use your 'custom' version of JUTreeNodeBinding, while it will function exactly the same. You can make any modifications, like the one I suggested in my original post, in this class.
Good luck.