Browse Prior Art Database

Implementation of Runtime Object Expansion in an OS/2 Presentation Manager Interface

IP.com Disclosure Number: IPCOM000111664D
Original Publication Date: 1994-Mar-01
Included in the Prior Art Database: 2005-Mar-26
Document File: 2 page(s) / 113K

Publishing Venue

IBM

Related People

Morgan, SA: AUTHOR [+4]

Abstract

When OS/2* with Presentation Manager* (PM) first appeared, dialog boxes containing controls such as entry fields, list boxes, and static text were all non-sizeable. The controls were a set size, the dialog was a set size, and neither was changed at runtime.

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

Implementation of Runtime Object Expansion in an OS/2 Presentation
Manager Interface

      When OS/2* with Presentation Manager* (PM) first appeared,
dialog boxes containing controls such as entry fields, list boxes,
and static text were all non-sizeable.  The controls were a set size,
the dialog was a set size, and neither was changed at runtime.

      The current usability standards now recommend that all dialogs
should be sizeable.  However, dialog controls were not designed by PM
to re-size at runtime.  Their default action is to stay at their
predetermined size even when the dialog is sized larger and there is
space that is not used.

      Ideally, controls designed for user input or data output would
expand at runtime to use all the space made available when a dialog
was sized larger.  This would make input easier and allow more output
to be seen.  This disclosure describes a technique to implement
runtime control expansion in sizeable PM dialogs.

      In an object-oriented environment, the object, in this case the
control, should know enough about itself to tell if it supports
runtime expansion.  The object determines this at panel layout time
based on its capabilities and its position within the dialog.  If
there are no controls to the right of it, the object can expand
horizontally.  If there are no controls below it, it can expand
vertically.  If both conditions are true, it can expand in both
directions.  The positive exception to these rules is that an
object's associated prompt, prefix and suffix text can be
repositioned by the object itself, so they can be to the right or
below and the object can still support expansion.

      Runtime control expansion is particularly suited to controls
such as listboxes, single and multi-line entry fields, and scrollable
output fields.  The listbox can expand vertically to show more list
items, and horizontally to show more of each list item's text.  Both
types of entry fields can expand horizontally to allow the user more
room in which to type, and multi-line entry fields can expand
vertically to show more lines of input.  Scrollable output fields can
expand horizontally to not require as much scrolling from the user to
see all of the output text.

      When a dialog is laid out, it is set to its optimal size.  If
the user sizes it smaller than its optimal size, rather than have the
controls shrink to a possibly unusable size, the controls should keep
the same size and the dialog should become scrollable.  If the dialog
is sized larger than its optimal size, controls that support
expansion should expand along with it.  The dialog supplies the
information that allows this to work.

      The dialog, as a self-contained object, knows what its optimal
size is, and thus knows when it is sized larger or smaller than that.
Whenever the dialog is sized, it receives a WM_SIZE message from PM.
However, the controls themselves do not receive this messag...