Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Implementation of Object-Oriented Action Encapsulation for Presentation Manager Controls

IP.com Disclosure Number: IPCOM000114785D
Original Publication Date: 1995-Jan-01
Included in the Prior Art Database: 2005-Mar-29
Document File: 2 page(s) / 91K

Publishing Venue

IBM

Related People

Morgan, SA: AUTHOR [+4]

Abstract

Disclosed is a technique for implementing the encapsulation of the action to be performed when an object is acted upon with the object itself in a Presentation Manager (PM) development environment.

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

Implementation of Object-Oriented Action Encapsulation for Presentation
Manager Controls

      Disclosed is a technique for implementing the encapsulation of
the action to be performed when an object is acted upon with the
object itself in a Presentation Manager (PM) development environment.

      One of the strong points of an object-oriented implementation
of a graphical user interface is encapsulation.  In brief,
encapsulation exists when all required knowledge of an object is
contained within that object.  Programming to the PM of OS/2* does
not automatically provide this encapsulation.  PM programming is
message driven, with much required knowledge of an object contained
within the message procedure for that object.  Ideally it would all
be contained within the object itself.

      One area in which this is particularly important is for objects
which are used to perform an action.  Examples of such objects are
pushbuttons, menu items, list items and container records.  Clicking
the mouse on a pushbutton, selecting a menu item, double clicking on
list items or container records all cause some action to occur.

      The current technique is to intercept the action message, such
as the WM_COMMAND or WM_CONTROL messages, in the message procedure.
Which object the message pertains to is determined from the object ID
included with the message.  A switch statement then falls to the ID
case for that object and performs whatever action is indicated in the
code for that case.  The actions are therefore hard-coded in the
code.  When a new object is added to the interface, a new switch
statement must be added to process that object's action message.

      A much more object-oriented approach to handle this would be to
associate the action with the object itself.  When an action message
is received, the code simply asks the object what action is to be
performed.

      For each action that must occur, there should exist a method or
function to perform that action.  This method's name can be
associated with the object that will perform it by using PM's window
words.  Window words are simply a space in memory that is associated
with a window object, the contents of which can be queried from that
object.  APIs such as WinSetWindowPtr and WinQueryWindowPtr are
designed to set...