Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6476219

Limited access to drag source/drop target events

    XMLWordPrintable

Details

    • Enhancement
    • Resolution: Unresolved
    • P4
    • None
    • 1.4.2, 5.0
    • client-libs
    • x86
    • windows_xp

    Description

      A DESCRIPTION OF THE REQUEST :
      Only the originator of a drag or receiver of a drop has full access to drag source/drop target events.

      I have encountered this limitation in several scenarios.
      1) automatically add a drag image for the dragged component

      While the DragSource API was extended to allow global listeners, it can only be used to track part of the drag operation, and then only for drags originating in the current VM. There is no specific event for the start of the drag or other indication of the original drag coordinate, so the drag image offset is never quite correct. It's not possible to listen for drags originating outside the current VM.

      2) record user drag operations (for testing or playback)

      Since drag/drop events don't go through the AWT event queue, they don't get passed to any AWTEventListeners. The SunDropTargetEvents that *are* passed to the component do not get forwarded to AWT event listeners. The Costello UI test script editor records these actions by swapping out the event queue to catch these events before they're dispatched, but this is an ugly hack.

      3) decorate drop targets without deriving new classes

      While the swing drop target handler allows more than one listener, so a listener *could* be added which responds to drop target events, there's no way to detect when new drop targets come into play, which is where a new drag listener would sensibly be added.

      Fundamentally, what amounts to adding decoration or simply observing events requires subclassing of components. And since the built-in swing drag support can not be subclassed, there's not even a workaround.

      JUSTIFICATION :
      AWTEventListener is advertised as a way to record user events. Currently drag and drop is unrecordable without hacks. Why can't it receive equivalent MouseEvents corresponding to dragsource/droptarget events?



      EXPECTED VERSUS ACTUAL BEHAVIOR :
      EXPECTED -
      AWTEventListener should be notified of ALL UI events.
      ACTUAL -
      Depending on timing or the behavior of DRagGestureRecognizer, an AWTEventListener might receive a MOUSE_PRESS and one or more MOUSE_DRAGGED up until the native drag starts, but no corresponding MOUSE_RELEASE.

      CUSTOMER SUBMITTED WORKAROUND :
      a) Add a global DragSourceListener
      This gets all events a drag source listener would normally get, but the initial drag event must be guessed at.

      b) Replace the system EventQueue and look for SunDropTargetEvent. This gets the same events passed to the component for handling. When a new target is encountered, a drop target listener may be added if the component has a SwingDropTarget. It is not possible to add a drop target listener on the typical AWT D&D implementation, since it supports only one drop target listener.

      Attachments

        Issue Links

          Activity

            People

              denis Denis Fokin (Inactive)
              ndcosta Nelson Dcosta (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated:
                Imported:
                Indexed: