Custom Views and Input Fields

Java > Core SWING advanced programming > 8. DRAG-AND-DROP > Drag-and-Drop Overview

 

Drag-and-Drop Overview

In JDK 1.1, JavaSoft introduced a new Abstract Window Toolkit (AWT) sub-package called java.awt.datatransfer that provided the platform-dependent software and the Java classes necessary to allow Java applications to participate in the exchange of data via an intermediate location referred to as a clipboard. This package also allowed access to the system clipboard provided by the platform's host windowing system, allowing a Java application to exchange data with another Java application running in a separate virtual machine (VM) on the same machine or, perhaps more interestingly, with a native application. This feature made it possible to copy and paste data from something like Microsoft Word directly into a text field of a graphical user interface (GUI) form in a Java program, or vice versa. Support for copy and paste, using the java.awt.datatransfer package, is built into the Swing text components, so that there is no need for the programmer to explicitly enable this mechanism when using Swing.

While this feature was a major step forward when it appeared, it is by no means a complete solution to the problem of making it easy for a user to move data between applications. Because of the implementation, it was only possible to place on the system clipboard data that can be represented in the form of a string. If you only need to move text, of course, this will not cause you a problem. However, if you have to copy graphics onto the system clipboard or you want to allow the user to select and replicate components from your user interface and import them into an application in a different Java VM, you have a problem. The only solution is to somehow encode what you want to transfer as a string when placing it on the clipboard and then reverse the encoding when importing the data from the clipboard to the target. This is a cumbersome process that requires you to write and debug the encoding and decoding software and, what is worse, it means that only applications that are aware of your encoding mechanism can successfully import your data.

Core Note

For an example that uses this technique to transfer images between Java applications via the system clipboard, see Core Java 2, Volume 2: Advanced Features by Cay Horstmann and Gary Cornell (Prentice Hall).



Another shortcoming of copy and paste is that it is a two-step process for the user: Anything that is to be transferred must first be selected, usually by dragging the mouse over it, and then exported to the clipboard in some platform or application-dependent way. The export operation is typically performed using a command from the applications menu bar such as Copy or Cut, or using an associated keyboard shortcut (typically Ctrl-X for Cut or Ctrl-C for Copy on the Windows platform). Once the data has been placed on the clipboard, the user would move to the target application, select the location at which the data should be placed (most likely by clicking with the mouse), and then use a Paste command from the target application's menu or its keyboard equivalent (Ctrl-V on the Windows platform). Once the data has been exported to the clipboard, it will stay there until replaced by something else, so the same data can be pasted more than once to multiple locations.

This sequence of operations can be both time-consuming and inconvenient. Most GUI platforms now support a more direct mechanism for moving data called drag-and-drop, which allows the user to initiate and control the operation entirely using the mouse without going through an intermediate location the data is selected and then "dragged" across the screen, to be "dropped" at its target location. The user is required only to indicate what needs to be done using platform-dependent gestures that indicate the start and end of the operation the applications cooperate with each other and with the windowing software to transfer the data itself. As was the case with copy-and-paste, a fully general implementation of drag-and-drop in Java is not possible, because it is necessary to interface with whatever mechanism is provided by the host platform, which requires the use of native code libraries. Java 2 provides support for this in the java.awt.dnd package. In this chapter, you'll see how to use the facilities provided by this package to add drag-and-drop support to your Swing applications.

Drag-and-drop involves three logically separate pieces the drag source, the drop target, and the data transfer itself. Depending on your application, to provide drag-and-drop functionality you will need to write code that implements at least two of them, one of which will always be the code to handle the data transfer. An application that can be both the source and the target of a drag-and-drop operation will implement both the drag source and drop target functionality, while simpler applications might require only one of these two functions. A brief description of each of these three pieces follows.

The Drag Source

As its name suggests, a drag source is a part of the application's user interface that can provide data to be transferred using the drag-and-drop mechanism. The drag source, which is always a Component, advertises the fact that it can supply data and also specifies the operations that it can perform on that data. The Java implementation of drag-and-drop recognizes three separate operations:

  • Copy

  • Move

  • Link

Copy and move are similar in that they both cause a copy of the data to be transferred from the source to the target. At the end of a move operation, if it is successful, the original data is removed from the drag source, whereas copy leaves the source data intact. A typical use for these operations would be to copy or move files within or between file systems using a graphical file system viewer such as Windows Explorer. When operating as a drag source, this program would offer the ability to copy, move, or link files (or groups of files). The precise operation to be performed may be chosen by the user or may be imposed by the nature of the application receiving the data.

The precise meaning of each operation depends entirely on the source and target applications. While the interpretation of copy and move within a given application context will usually be fairly intuitive for the user, the meaning of the link operation may not be and, in fact, many applications will not support this operation at all. The intent of the link operation is to allow a reference to data in one context to be placed in a different context so that it can be accessed from the receiving context without having been moved or copied there. The precise details of this are very dependent on the applications involved and the nature of the data itself. Perhaps the simplest case that illustrates this operation is, again, a graphical file viewer, where dragging a file from one location to another and specifying link as the operation would make a hard or soft link from the new location to the old one, thus creating another way to get to the same file system object without relocating or copying the original. Not all platforms will necessarily have the concept of a file system link and, on these systems, the drag source corresponding to the file viewer would not offer it as a valid choice.

The Drop Target

A drop target is a region of the application's GUI that can receive data from a drag source. An application may support any number of drop targets. In the Java 2 implementation of drag-and-drop, a drop target always corresponds to a GUI Component. Like drag sources, drop targets can offer to support any of the three available drag-and-drop operations. It is permissible for distinct drop targets within an application to support different operations. When a drag operation is in progress and the user drags the mouse over a drop target, the set of available operations is limited to the intersection of the set offered by the drag source and that supported by the drop target. It is quite common for this intersection to be empty, in which case a drop on the target from the active drag source will not be possible. At any given time, a drop target may or may not be active. For example, you might want to create an editor that can receive text dragged from an external source by registering the editor component as a drop target. However, if the editor supports a read-only mode, it should not be possible for the user to drag text into it when this mode is selected and the drop target should behave as if it were inactive in this case.

Data Transfer

The drag-and-drop mechanism is outwardly concerned mainly with the graphical representation of the user's request to move data from one location to another, but the actual transfer of the data is ultimately the most important aspect. In fact, once the drag source and the drop target are known, the problem of moving the data itself from one to the other is very similar to that solved by the JDK 1.1 data transfer mechanism used to implement copy-and-paste, except that an intermediate clipboard is not used with drag-and-drop. As far as the drag source and drop target are concerned, the movement of the data requires two things:

  • Agreement on the format in which the information will be transmitted.

  • The existence of a channel between the two through which the information can be passed.

To agree on the transmission format of the data, both parties must have a common way of specifying individual data formats. The drag-and-drop mechanism uses the java.awt.datatransfer.DataFlavor class to describe the way in which the information is represented, in exactly the same way as the JDK 1.1 cut-and-paste feature does. There is a predefined set of DataFlavors that are understood to represent specific ways of encoding information, such as DataFlavor.stringFlavor, representing a Unicode string and DataFlavor.plainTextFlavor for plain text encoded in a specific character set. The drag source can offer the data in one or more of the standard flavors or can invent flavors of its own that, if used, might convey more information to the receiver, but may only be understood by a cooperating drop target. Usually, a drag source will offer its content in several flavors and allow the drop target to pick the best form that it understands. We'll say more about DataFlavors later in this chapter.

The communication channel through which the data is actually moved is managed by the drag-and-drop mechanism itself. Neither the drag source nor the drop target need be aware of the precise details of what is going on, which is helpful because the implementation details are very platform-dependent. At the level of the drag source, the data to be transferred must be packaged in the form of an object that implements the java.awt.datatransfer.Transferable interface. Again, this is the same mechanism used for copy and paste. A Transferable needs to be able to return a list of the DataFlavors that it supports and must return the actual data in a form suitable for the DataFlavor selected by the drop target. When the data is dropped, the drop target can get a reference to the Transferable and use it to determine the actual DataFlavor that it wants to use and to get the data itself. You'll see several examples of this in this chapter.

 

 



Core Swing
Core Swing: Advanced Programming
ISBN: 0130832928
EAN: 2147483647
Year: 1999
Pages: 55
Authors: Kim Topley

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net