Browse Prior Art Database

Direct Manipulation Synchronous Reply Processing

IP.com Disclosure Number: IPCOM000105961D
Original Publication Date: 1993-Sep-01
Included in the Prior Art Database: 2005-Mar-20
Document File: 4 page(s) / 116K

Publishing Venue

IBM

Related People

Hindocha, N: AUTHOR [+3]

Abstract

A feature which is becoming increasingly standard in graphical applications is direct manipulation, or drag-and-drop. This provides the user the ability to click with the mouse button when the pointer is over an object, move the mouse elsewhere and release the button. The object is then moved or copied from one location to another, or an application is invoked with the objects as data, or another effect is defined by the two applications.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 45% of the total text.

Direct Manipulation Synchronous Reply Processing

      A feature which is becoming increasingly standard in graphical
applications is direct manipulation, or drag-and-drop.  This provides
the user the ability to click with the mouse button when the pointer
is over an object, move the mouse elsewhere and release the button.
The object is then moved or copied from one location to another, or
an application is invoked with the objects as data, or another effect
is defined by the two applications.

      For efficiency and maintainability, it is desirable that the
application programmer has access to a programming interface (API)
that is as consistent as possible across all the target platforms.
Thus instead of learning all the details of different systems that
support direct manipulation, the programmer writes to a single API
which is translated by a building tool into the native environment.
Currently, no capability exists to serially order Direct Manipulation
Services inter-process communication in a multi-tasking operating
system.  Such a mechnism is necessary to implement a generalized
mechanism and programming interface for direct manipulation.

      Direct Manipulation Synchronous Reply Processing (DMSRP)
defines an API that a sender can use to query a target application to
see if a drop of a particular object would be acceptable.  This
requires a synchronous reply since otherwise the returned information
would be unusable by the sending application.  On MS-Windows* and
similar systems this presents no problem since the operating system
is able to perform a synchronous context switch from one process to
another if necessary.  However, on multi-tasking, multi-user systems
such as those based on X, a context switch is not generally possible
and so another mechanism is required.

      DMSRP implements two methods for query processing on such
systems.  The application recognizes whether or not it owns the
window, since the windows are marked with hostname and process ID to
ensure uniqueness, and takes action accordingly.

      In the case where one application is querying another, the
first sends a query message to the second and waits for a reply.  The
length of the wait is defined by DMSRP and may vary from one system
to another.  If no message is received within the specified time then
a timeout error is returned; note that this will not normally happen
since applications that do not participate in the drop protocol will
not be recognized as targets and will not therefore have query
messages sent to them.

      In the case where an application is querying itself (whether
the dropin is to the same window or to another in the same process) a
different scheme is adopted.  Sending a message and waiting for a
reply would not work:  the reply could never appear since the same
application cannot simultaneously wait for a reply and send it
(unless it is multi-threaded).  Therefore DMSRP calls the query
proces...