Implementing Application-Driven Drag-Drop in an Office Systems/2 Environment
Original Publication Date: 1996-Feb-01
Included in the Prior Art Database: 2005-Mar-31
Johnson, D: AUTHOR [+4]
Disclosed is a description of how an application developer on OS/2* can implement a complete application-driven drag-drop capability without requiring the user to be pressing any mouse button at the time the drag is started, along with resolving the various other issues that must be resolved for application-driven drag-drop to be usable on OS/2.
Implementing Application-Driven Drag-Drop in an Office
a description of how an application developer on
OS/2* can implement a complete application-driven drag-drop
capability without requiring the user to be pressing any mouse button
at the time the drag is started, along with resolving the various
other issues that must be resolved for application-driven drag-drop
to be usable on OS/2.
paradigm for a drag-drop operation in an OS/2
Presentation Manager* graphical user interface is that the drag is
initiated by the user pressing and holding the appropriate mouse
button while moving the mouse on the screen. In this paradigm, it is
always the user who initiates the drag, and it is always initiated in
the same press-and-hold-the-mouse-button manner. OS/2 provides APIs
that ease the enablement of this design.
applications in a Windows** environment, such as
Microsoft** Visual Basic**, allow the application itself to initiate
a drag operation. This drag initiation is done irrespective of
whether the user is holding down a mouse button at the time, and may
be triggered by a mouse click, a mouse movement over a given object,
or by any other action or event that the application is interested
in. The drag is ended when the user has pressed and then released a
mouse button, or the application can end thedrag by itself.
applications that want to provide the same type of
support, while still using the OS/2-provided APIs, run into many
problems in the actual implementation of this design in OS/2. As one
example, the OS/2 APIs require that a mouse button be held down
during a drag. While a drag can be initiated by calling the
appropriate OS/2 API, it immediately terminates if the user is not
holding down a mouse button. This renders the application-driven
drag inoperable and unusable.
In order for
an application to implement application-driven
drag-drop, several issues must be addressed. The first of these is
that the OS/2 drag-drop APIs will not function if the mouse is
currently captured. The WinQueryCapture API returns the handle of
the window that currently has the mouse captured, if any window does.
If this call reveals that a window does have the mouse captured, the
mouse must first be released before the drag can be initiated. Since
most application-driven drag-drop operations will be initiated due to
some user interaction with the application, it will usually be the
current application that has the mouse. While the capture can be
released by calling the WinSetCapture API with a NULL window handle,
it is much more application friendly to instead send a button-up
message to the window holding the mouse so that the window can
complete its processing rather than having it cancelled.
mouse is ensured to be free from capture, the
application must decide what mouse button will be use...