Name: ssT124754 Date: 04/09/2001


java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)

If you build a custom TreeCellEditor for a JTree, and do NOT want editing to
stop when you select another cell, this is currently unsupported. In fact, if
you open a cell for editing and return false from stopCellEditing in order to
signal invalidate editing data, the editor is STILL closed leaving invalid data
inside it.

invokesStopCellEditing() works as described, however in the cases it is used is
when the return from stopCellEditing is completely ignored. If you grep
through the JDK source, the use of stopCellEditing() that would effect this is
only found in the function javax.swing.plaf.basic.BasicTreeUI.stopEditing().
All of the code dealing with selections and other things just calls
completeEditing() without any regard for the desire to keep the editor open,
thereby ignoring the false return from stopCellEditing().

Keeping the editor open is an absolute must for some applications, and it seems
quite difficult to make this happen without rewriting the entire UI for JTree.
Please help on this, the JTree UI code is so messy it's very difficult to tell
how to create a workaround for this that isn't just a dangerous guess. It seems
as if completeEditing() is called in a large number of places in the basic UI
as a "just in case" cleanup activity.

Here's code to reproduce:
import javax.swing.*;
import java.awt.dnd.*;
import java.awt.datatransfer.*;

public class DnDTest
{
  public static void main(String[] args)
  {
    JFrame f = new JFrame("DnD Test");
    JTree t = new JTree(new String[] { "Foo", "Bar" });
    t.setEditable(true);
    t.setInvokesStopCellEditing(true);
    t.setCellEditor(new javax.swing.tree.DefaultTreeCellEditor(t,
     new javax.swing.tree.DefaultTreeCellRenderer())
    {
     public boolean stopCellEditing()
     {
     if (Math.random() < 0.5)
     {
     System.out.println("REJECTING EDIT!!!");
     return false;
     }
     else
     {
     boolean retVal = super.stopCellEditing();
     System.out.println("System edit stop does:" + retVal);
     return retVal;
     }
     }
    });
    f.getContentPane().add(t);
    DragSource.getDefaultDragSource().createDefaultDragGestureRecognizer(t,
      DnDConstants.ACTION_COPY_OR_MOVE, new DragGestureListener()
      {
        public void dragGestureRecognized(DragGestureEvent evt)
        {
          evt.startDrag(null, new StringSelection("Junk"), new
DragSourceListener()
          {
            public void dragEnter(DragSourceDragEvent evt)
            {
            }
            
            public void dragOver(DragSourceDragEvent evt)
            {
            }
            
            public void dragExit(DragSourceEvent evt)
            {
            }
            
            public void dropActionChanged(DragSourceDragEvent evt)
            {
            }
            
            public void dragDropEnd(DragSourceDropEvent evt)
            {
            }
            
          });
        }
      });
    f.pack();
    f.setVisible(true);
  }
}

Run the app and triple-click (and that shows the JTree drag bug that's already
been submitted, so hit f2 instead to start an edit). Type something in
different, click an another cell. 50% of the time it's setup to reject the edit
and not lose control, yet it always will.

There's your reproducible case, now fix the bug.
(Review ID: 120001)
======================================================================