Browse Prior Art Database

Architecture for Managing Over-Laid Controls in OS/2 Presentation Manager Dialogs

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

Publishing Venue

IBM

Related People

Morgan, SA: AUTHOR [+4]

Abstract

Occasionally, OS/2 Presentation Manager (PM)* dialogs require an area on the dialog where depending on user interaction the area changes from one group of PM controls (radiobuttons, checkboxes, etc.) to another group. OS/2 PM does not provide an architecture to implement this capability easily by the programmer. Therefore, each time the capability is needed, programmers are required to design and implement their own way of handling the specific case.

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

Architecture for Managing Over-Laid Controls in OS/2 Presentation
Manager Dialogs

      Occasionally, OS/2 Presentation Manager (PM)* dialogs require
an area on the dialog where depending on user interaction the area
changes from one group of PM controls (radiobuttons, checkboxes,
etc.) to another group.  OS/2 PM does not provide an architecture to
implement this capability easily by the programmer.  Therefore, each
time the capability is needed, programmers are required to design and
implement their own way of handling the specific case.

There are three steps that should be employed to manage an overlay
area on a dialog.

1.  Define in the OS/2 PM Dialog template all the controls that exist
    in each of the overlay areas.

2.  Define only the controls found in the overlay that is to be
    initially shown as enabled and visible.  All other controls in
    the other overlays should be disabled and invisible.

3.  Have the dialog procedure support additional messages that are
    used to identify the overlay groupings as well as to change the
    overlay that is being shown.

      When defining the overlay groupings in the dialog template, the
developer should treat each group as if there were no other groups.
This means the WS_GROUP and WS_TABSTOP settings and the order of the
controls in the template should correspond to the behavior needed
during user interaction.  Therefore, this would be the same behavior
the users are accustomed to since i...