In OS/2 Version 1.3, a set of functions and messages were provided for direct manipulation, but each program had to provide its own code to take advantage of these functions, and define its own protocols to be observed during drag/drop operations, so that each program knew what type of information was being transferred.
These protocols are called Rendering Mechanisms. Three standard ones were defined in OS/2 Version 1.3:
Since PM did not provide common objects, such as printers and shredders, to implement these protocols the value of these rendering mechanisms was reduced. The apparent complexity of the direct manipulation functions and protocols also inhibited their use.
More importantly, however, the non-object-oriented structure of most PM applications made designing direct manipulation into existing programs both difficult and largely ineffectual. The benefit of direct manipulation is directly proportional to the granularity of the objects being manipulated; where the finest grained object is a file, the only other objects it can interact with are containers and devices. Such interactions can as easily be implemented by the shell, as is shown by the implementation of the WPS.
OS/2 Version 2.0 provides many common objects which can be used by applications, all of which are drag/drop enabled. When an icon (representing a WPS object or something dragged from a PM program) is dragged over a WPS object, that target object will send a message to the source object to try to complete a direct manipulation operation.
That message says what the target icon does, so a successful drop depends on the source and target object implementing a common rendering mechanism; that is, the source object must be able to:
If the source icon represents something that is unsuitable for dropping on this target object, then a drop will not be allowed and the user will be informed by the pointer changing to a "no-entry" symbol.
Where possible, the WPS includes standard PM rendering mechanisms (for example, DM_DISCARDOBJECT) as well as its own WP messages (for example, (WP_DELETE). It is therefore possible for a PM application to interact with WPS devices by coding appropriate responses into the application using the drag/drop APIs. To do this, the programmer must know and understand the rendering mechanisms used by each WPS object.
This is made more difficult because the WPS, for performance reasons, often implements functions within the core classes rather than leaving it to objects derived from the base classes, such as WPFileSystem, to carry out the action. Thus, when dragging a file to the shredder, the file does not receive the WP_Delete message; instead, the shredder program tells the OS/2 file system to delete the file.