Resizing issues in JTree

[Pallavi Kudigrama]

Hi,

I'm working on trees at the moment and I'm running into a few resizing problems. Firstly, let me give some background information. The tree has a maximum of 2 levels (root -> child -> grandchild) and as per requirements, root is invisible. The child displays a brief overview that is 6 - 7 words long and the grandchild shows description that can be 2 or more sentences long. For this reason I used simple JLabel for the header (child), and JTextPane for the details (grandchild) as I need to provide functionality for links etc. Another requirement is disabling scroll pane. The JTree is contained in a JPanel with a BorderLayout. The first problem I hit was that the JTextPane did not allocate space according to it's container. i.e the details were displayed in a single line that went beyond the edge of panel instead of multiple lines. As a somewhat quick fix, I modified getPreferredSize() method of the text pane so that it calculates according to the container size and displays in more than one line. Here is the snippet of code :

      
      public Dimension getPreferredSize()
      {
        Dimension d = super.getPreferredSize();
        float nodeMaxWidth = _Tree.getWidth() - 40;
        if(d.width > nodeMaxWidth)
        {
          d.height = d.height * (int)Math.ceil(d.width/nodeMaxWidth);            
        }
        d.width = (int)nodeMaxWidth;
        return d;
      }

However the problem I'm hitting now is that when the panel is resized, the tree (or the JTextPane) doesn't get resized and remains at the previous value.

From my perspective there is either an issue because of the way I've forced computation of getPreferredSize(), or there is caching going on in either TreeModel or BasicTreeUI. Does anyone know if this is a known bug? If not, any ideas on the possible solutions?

[Maneesh Godbole]

Another requirement is disabling scroll pane

Why is this? What is the expected behavior when the correctly computed tree panel size is bigger than the available screen size?

[Pallavi Kudigrama]

The expected behavior for the JLabel is to truncate if it is longer than the tree width. The JTextPane should compute its width according to tree width and if it's longer, then to print it in more than one line. I know that dynamic calculation of size after resizing works when for an independant JTextPane, which is why I chose it (apart from it's link handling capability) but I'm at a loss as to why it doesn't work when placed as a node in a JTree. For that matter, even the JLabel doesn't recalculate after resizing. This is actually part of a larger project, so I'm afraid I have no say in the requirements. I'm hoping that there is a fix for the current problem.

[Pallavi Kudigrama]

What is the expected behavior when the correctly computed tree panel size is bigger than the available screen size?

There are constraints which ensure that the container (JPanel) never exceeds a specified size (I hope this answers your question)

[Maneesh Godbole]

Pallavi Kudigrama wrote:

What is the expected behavior when the correctly computed tree panel size is bigger than the available screen size?

There are constraints which ensure that the container (JPanel) never exceeds a specified size (I hope this answers your question)

Not really.
What I was getting at is what if the size required to display the tree data is greater than the available size.
Scrollpanes exist to help in such scenarios. I am trying to understand why the restriction of not using them

[Pallavi Kudigrama]

I do understand your question, but like I said this is part of a larger project. This particular panel containing the tree is only one of 6 panels that will be shown at a time (like an installation wizard), so I suppose having scroll bars on all of them is not desirable. Believe me, a scroll bar would have made my life much simpler! But I have to work within these constraints, unfortunately. And the very worst scenario would probably be writing my own TreeUI class, but I'm hoping it doesn't come to that!

[Maneesh Godbole]

When the contents of the UI are dynamically changed (one panel replaced by other), the way to force the UI to relayout and repaint is to call the revalidate() and repaint() on the parent container.
In your case, can you try after the dimension is computed?

[Pallavi Kudigrama]

You know what? I ran my code through the debugger with breakpoints in the appropriate places, and resizing makes no calls to getPreferredSize() at all. It seems to be called just once when the node is added and viewed for the first time. There are no subsequent calls to it, no matter how many times you resize, expand, or collapse. Neither does it trigger any calls to getMinimumSize() or getMaximumSize(). So I guess in answer to your question, it wouldn't help to call either repaint() or revalidate() after computing the size, since the first time works fine. From what I've seen of BasicTreeUI code, I think it implicitly assumes that a scroll bar is available, so I guess it caches the tree dimensions. I hope I'm mistaken...

[Maneesh Godbole]

Remove existing tree panel
Reload tree data; re/compute size
Add to parent
revalidate()
repaint()

[Pallavi Kudigrama]

That's a nice, simple solution except that it would be rather inefficient if the tree has a lot of data, don't you think? Plus, the current UI implementation doesn't seem to even catch resizing events! So, I've tried using a ComponentListener, and through it's inherited method componentResized(ComponentEvent e), I'm refreshing all the nodes in the tree, and this seems to be working thankfully! Thanks a lot for your help!