Package org.jdesktop.swingx

Class JXTreeTable.TreeTableHackerExt4

java.lang.Object
org.jdesktop.swingx.JXTreeTable.TreeTableHacker
org.jdesktop.swingx.JXTreeTable.TreeTableHackerExt
org.jdesktop.swingx.JXTreeTable.TreeTableHackerExt4
Direct Known Subclasses:
JXTreeTable.TreeTableHackerExt5
Enclosing class:
JXTreeTable
public class JXTreeTable.TreeTableHackerExt4 extends JXTreeTable.TreeTableHackerExt
This class extends TreeTableHackerExt instead of TreeTableHackerExt3 so as to serve as a clue that it is a complete overhaul and looking in TreeTableHackerExt2 and TreeTableHackerExt3 for methods to change the behavior will do you no good.

The methods previously used are abandoned as they would be misnomers to the behavior as implemented in this class.

Changes:

  1. According to TreeTableHackerExt3, clickCounts > 1 are not sent to the JTree so that double clicks will start edits (Issue #474). Well, mouse events are only sent to the JTree if they occur within the tree handle space - so that is not the behavior desired. Double clicks on the text/margin opposite the tree handle already started edits without that modification (I checked). The only thing that modification does is introduce bugs when one actually double clicks on a tree handle... so that idea was abandoned.
  2. There is no longer any discrimination between events that cause an expansion/collapse. Since the event location is check to see if it is in the tree handle margin area, this doesn't seem necessary. Plus it is more user friendly: if someone missed the tree handle by 1 pixel, then it caused a selection change instead of a node expansion/ collapse.
  3. The consumption of events are handled within this class itself because the behavior associated with the way that processMouseEvent(MouseEvent) consumed events was incompatible with the way this class does things. As a consequence, hitHandleDetectionFromProcessMouse(MouseEvent) always returns false so that processMoueEvent(MouseEvent) will not doing anything other than call its super method.
  4. All events of type MOUSE_PRESSED, MOUSE_RELEASED, and MOUSE_CLICKED, but excluding when isPopupTrigger() returns true, are sent to the JTree. This has the added benefit of not having to piggy back a mouse released event as we can just use the real mouse released event. This keeps the look and feel consistent for the user of UI's that expand/collapse nodes on the release of the mouse.
  5. The previous implementations have a spiel about avoiding events with modifiers because the UI might try to change the selection. Well that didn't occur in any of the look and feels I tested. Perhaps that was the case if events that landed within the content area of a node were sent to the JTree. If that behavior is actually necessary, then it can be added to the isTreeHandleEventType(MouseEvent) method. This implementation sends all events regardless of the modifiers.
  6. This implementation toggles the processing of mouse motion events. When events are sent to the tree, it is turned off and turned back on when an event is not sent to the tree. This fixes selection changes that occur when one drags the mouse after pressing on a tree handle.
contributed by member aephyr@dev.java.net

  • Constructor Details

    • TreeTableHackerExt4

      public TreeTableHackerExt4()

  • Method Details

    • isTreeHandleEventType

      protected boolean isTreeHandleEventType(MouseEvent e)
      Filter to find mouse events that are candidates for node expansion/ collapse. MOUSE_PRESSED and MOUSE_RELEASED are used by default UIs. MOUSE_CLICKED is included as it may be used by a custom UI.
      Parameters:
      e - the currently dispatching mouse event
      Returns:
      true if the event is a candidate for sending to the JTree

    • getEventForTreeRenderer

      protected MouseEvent getEventForTreeRenderer(MouseEvent e)
      This method checks if the location of the event is in the tree handle margin and translates the coordinates for the JTree.
      Parameters:
      e - the currently dispatching mouse event
      Returns:
      the mouse event to dispatch to the JTree or null if nothing should be dispatched

    • hitHandleDetectionFromProcessMouse

      public boolean hitHandleDetectionFromProcessMouse(MouseEvent e)
      Description copied from class: JXTreeTable.TreeTableHacker
      Entry point for hit handle detection called from processMouse. Does nothing if isHitDetectionFromProcessMouse is false.
      Overrides:
      hitHandleDetectionFromProcessMouse in class JXTreeTable.TreeTableHacker
      Returns:
      this method always returns false, so that processMouseEvent always just simply calls its super method
      See Also:

    • shouldDisableMouseMotionOnTable

      protected boolean shouldDisableMouseMotionOnTable(MouseEvent e)
      Returns a boolean indicating whether mouseMotionEvents to the table should be disabled. This is called from hitHandleDetectionFromMouseEvent if the event was passed to the rendering tree and consumed. Returning true has the side-effect of requesting focus to the table.

      NOTE JW: this was extracted to from the calling method to fix Issue #1527-swingx (no tooltips on JXTreeTable after expand/collapse) and at the same time allow subclasses to further hack around ...

      Parameters:
      e - the mouseEvent that was routed to the renderer.
      Returns:
      true if disabling mouseMotionEvents to table, false if enabling them