Browse Prior Art Database

Maintaining User Icon Placement when Initially Rejecting the Drop

IP.com Disclosure Number: IPCOM000115473D
Original Publication Date: 1995-May-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 2 page(s) / 121K

Publishing Venue

IBM

Related People

Cline, TL: AUTHOR [+3]

Abstract

An OS/2* 2.X Presentation Manager* (PM) application that includes the container control has the ability to determine whether a particular container record can be dropped on another particular container record, as well as whether the container record in question can be dropped on another container within the application. Many times these rules are consistent throughout a particular application and never change. However, an application may wish to allow a drop only under certain circumstances.

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

Maintaining User Icon Placement when Initially Rejecting the Drop

      An OS/2* 2.X Presentation Manager* (PM) application that
includes the container control has the ability to determine whether a
particular container record can be dropped on another particular
container record, as well as whether the container record in question
can be dropped on another container within the application.  Many
times these rules are consistent throughout a particular application
and never change.  However, an application may wish to allow a drop
only under certain circumstances.

      As an example, an application only allows container record one
from container one to be dropped on container two after the user has
entered a predefined password.  The reason for this could be for
security protection.  Perhaps the drop initiates another action, that
is, the copying of confidential files or the addition of a record to
a confidential data base.  In this case, when the user initially
tries to perform the drop by releasing the dragged record, a message
box is displayed by the application asking the user to enter the
required password.  If the password entered by the user is correct,
then and only then are the records added to the new container.
Another example is an installation program that does not allow a drop
from one container to another, because the drop represents an install
and it has been determined that the user does not have enough space
on the hard disk to accommodate the install.  However, after bringing
up a message box and allowing the user to erase some files thus
providing more space, the records are added.

      The problem that this disclosure addresses concerns how the
application in the above scenarios determines how and where the new
container records, whose drop was originally rejected, should be
positioned.  Because of the initial drop rejection, the application
must now add the records dynamically in the new container by
providing
PM placement information for all records that are to be added.

      The Window Management System (WMS) PM extension tool solves the
problem by calculating the position of where the original attempted
drop occurred.  If only one record were involved in the drag and drop
operation, the position for that record is the position where the
drop occurred.  This is calculated by the following algorithm:
  1.  Calculate the dropped position by taking the x and y
coordinates
       provided by PM in the xDrop and yDrop fields of the DRAGINFO
       structure and adding the cxOffset and cyOffset values from the
       DRAGIMAGE structure corresponding to the first container
record.
       These offsets are the x and y offsets from the pointer hot
spot
       to the origin of the image that represents the container
record.
  2.  Map the coordinates calculated in the previous step from
DESKTOP
       coordinates to container window coordinates using the
 ...