Browse Prior Art Database

Implementing Application-Driven Drag-Drop in an Office Systems/2 Environment

IP.com Disclosure Number: IPCOM000117435D
Original Publication Date: 1996-Feb-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 4 page(s) / 158K

Publishing Venue

IBM

Related People

Johnson, D: AUTHOR [+4]

Abstract

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.

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

Implementing Application-Driven Drag-Drop in an Office Systems/2
Environment

      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.

      The normal 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.

      However, some 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.

      OS/2 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.

      Once the mouse is ensured to be free from capture, the
application must decide what mouse button will be use...