Browse Prior Art Database

Minimization of Organizer Population Time in Officevision/2

IP.com Disclosure Number: IPCOM000120797D
Original Publication Date: 1991-Jun-01
Included in the Prior Art Database: 2005-Apr-02
Document File: 2 page(s) / 119K

Publishing Venue

IBM

Related People

Bell, LK: AUTHOR [+4]

Abstract

This article describes a method for an OfficeVision*/2 (OV/2) Organizer to reduce the overall population time before a user can interact with the system.

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

Minimization of Organizer Population Time in Officevision/2

      This article describes a method for an OfficeVision*/2
(OV/2) Organizer to reduce the overall population time before a user
can interact with the system.

      In OV/2 Office, an Organizer is a container that holds objects,
which are represented by icons.  An icon procedure is defined as code
that handles processing for a particular object (icon) appearing
within an organizer.  When an organizer is opened, it will populate
itself with icons that have been stored in it or with icons that
represent data files found in the organizer's associated
subdirectory. Since OV/2 Office is an object-oriented system, the
organizers know nothing about the objects that reside in them.
Because of this, the icon procedures that handle messages for each
icon in an organizer must do a certain amount of processing before
they can appear in the organizer.  Initial processing requirements
include registering the icon as a PM window class, querying icon
images, and setting text information for the list structure. This
type of processing is relatively fast.  However, some icon procedures
require further processing to occur before they can perform any other
work or handle any other messages.  These icon procedures take more
processing time as a result.

      An organizer's population time increases whenever an icon
procedure performs more than the minimum amount of processing
required for its birth in the organizer.  For example, at the end of
its usual birth processing, a database icon procedure may need to
verify that its required databases exist in the proper subdirectories
before it can proceed with any other work.  This type of processing
can take a considerable amount of time.  A significantly increased
birth time for any icon procedure is undesirable from an end user's
perspective for two reasons.  First, the user must wait for an
organizer to finish filling before being able to use any item in the
organizer.  Second, a long birth is visually noticeable to the user
because the icons do not populate the organizer steadily.  If an icon
procedure spins off a thread to handle additional processing, the
problem remains unresolved since this does not force the icon
procedure to give up control of system resources.  Because icon
procedures are all birthed in the same process, further population of
the organizer is blocked until the "slow" icon procedure is finished
with its processing.

      When an organizer is ready to populate itself, the Common
Organizer will set a RAM semaphore.  The Common Organizer will then
pass the handle of this semaphore to each icon procedure as it is
being birthed in its organizer. Iprocs that require more than the
minimum amount of processing during their birth will then disable
themselves (and appear in the organizer as a half-toned icon), spin
off a thread and wait f...