Drag and drop items

One way to describe this concept is to say that the data item has different representations suited for different kinds of operations on it. At the start of a drag and drop interaction, you do not know what representation is correct for the completed interaction because you do not know what the destination is.

The architecture provides for the necessary flexibility as follows. First, the class that abstractly encapsulates one or a related family of representations of a logically dragged item is called TScrapItem; TScrapItem abstractly holds no data and has no protocol for accessing data. TScrapItem is derived to define item classes that represent specific data types.

TScrapItem derived classes then override the virtual CopyAvailableTypes method to report what types they represent. You define these types with TTypeDescription.

In the conceptual language developed so far then, a drop acceptor is usually interested in one specific TScrapItem derived class in order to fulfill a specific operation, while the architecture must allow a drag source to publish (in general) more than one TScrapItem instance simultaneously to account for all potential destination needs. An abstract class called TDragAndDropItem, which can represent a collection of TScrapItem instances, provides the publishing feature.

TDragAndDropItem also has a virtual CopyAvailableTypes method your derived class can override to return the sum type list for a collection of scrap item instances, and you can use FindItemMatchingDescription to map a chosen type to the matching TScrapItem derived class instance.

Figure 56 depicts the example opening this section.

The PinkWrite document publishes four types when being dragged. The spelling checker appliance accepts only raw text.

Figure 57 shows how this type negotiation occurs.

In nontrivial cases where a drag and drop item has a multi-representation capability, it is clearly not economical for the scrap item instances to physically carry data in each representation because the acceptor uses only one representation. Therefore, the suggested way of implementing TScrapItem derived classes is to have them provide data access methods which can lazy-evaluate to actually come up with the data in the provided representation only when the accessor method is called. Even in the case of a simple drag and drop item with only one representation, it may not be efficient for the item instance to physically carry data because the user can end a drag and drop interaction without a drop. For example, the user can let go of the item in an area of the display that does not accept drops.