Browse Prior Art Database

Consistent Dynamic Dialog Box Fields

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

Publishing Venue

IBM

Related People

Weber, OW: AUTHOR

Abstract

This article describes the ability to provide the user access to all fields on the display, regardless of how they were created. When an OS/2* PM (Presentation Manager*) program dynamically creates windows within dialog boxes loaded from a resource file, and the dynamically created windows are interspersed between the other windows on the dialog box, the user is unable to tab to those new windows. This article describes a newly invented API (Application Programming Interface) which will intervene between the user's request to tab back and forth between the windows that were on the dialog box as it was loaded from the resource file, and those created dynamically.

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

Consistent Dynamic Dialog Box Fields

      This article describes the ability to provide the user
access to all fields on the display, regardless of how they were
created. When an OS/2* PM (Presentation Manager*) program dynamically
creates windows within dialog boxes loaded from a resource file, and
the dynamically created windows are interspersed between the other
windows on the dialog box, the user is unable to tab to those new
windows. This article describes a newly invented API (Application
Programming Interface) which will intervene between the user's
request to tab back and forth between the windows that were on the
dialog box as it was loaded from the resource file, and those created
dynamically.

      Consider a dialog box loaded from a resource file which
contains three entry fields (f1, f2, and f3).  An application is
written which dynamically creates a fourth window, such as an NLSTIME
control, and this fourth window is positioned between fields f2 and
f3. The user would like to be able to tab between the fields in the
order they are presented on the dialog as follows:  f1, f2, f4, and
f3. However, the user finds that PM tabs through the fields in this
order:  f1, f2, f3, and it is not possible to tab to field f4.

      The solution is to provide a mechanism to enable the user to
tab to every field in the order that the user would expect. The new
API makes the desired tabbing order possible by positioning
additional fields within the dialog box and then intercepting the
WM_FOCUSCHANGE message and then posting another message that will
force a focus change to the correct field.  The details follow.

      Continuing with the above example, four WC_BUTTON pushbutton
fields f5, f6, f7, and f8, are added to the initial dialog box in the
resource file.  They are all positioned between fields f2 and f3,
such that, when f4 is dynamically created, the fields are positioned
in this order:  f1, f2, f5, f6, f4, f7, f8, and f3.  The four new
fields are made visible so that they will be included in the PM
tabbing order, but they are assigned widths and heights of zero so
that they will not actually be seen by the user. Now the problem is
that tabbing goes from field f6 to field f7, still skipping f4.  The
new API solves this problem as follows:  The user tabs from f1 to f2,
then from f2 to f...