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

Enablement of Presentation Manager Message Box Subclasses

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

Publishing Venue

IBM

Related People

Banda, VP: AUTHOR [+3]

Abstract

Disclosed is a method by which an application can subclass a message box to an application message procedure and provide additional functionality to the message box while maintaining the message box standard appearance and ease of use.

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

Enablement of Presentation Manager Message Box Subclasses

      Disclosed is a method by which an application can subclass a
message box to an application message procedure and provide
additional functionality to the message box while maintaining the
message box standard appearance and ease of use.

      In an OS/2* Presentation Manager* (PM) application, subclassing
of windows is a necessity in order to manage them and to provide
enhanced function above what PM provides.  Subclassing a window
consists of directing all messages for that window to an
application-provided message procedure before they are directed
onward to PM.

There are several ways that this is accomplished:
  o  For standard windows, consisting of a frame and a client area,
      the WinCreateStdWindow API allows the application to pass in
the
      class name of the client window so that all messages go to the
      registered message procedure for that application class.  The
      frame itself can be subclassed after this call, and before the
      window is displayed, using the WinSubclassWindow API.
  o  For dialogs, the WinDlgBox API allows the application to pass in
      the address of the application message procedure that will be
the
      first to process the messages to the dialog.

      There is a third type of window in a PM application, however,
and that is the message box.  Message boxes are displayed with the
WinMessageBox API.  Message boxes are always synchronous, meaning
that the WinMessageBox call displays the message box and does not
return until the message box is dismissed.  Message boxes allow the
application to specify the title text, the message text, the type of
icon displayed with the message, and various presentation styles.
This API allows the application to easily display a standardized
message window with only one call.

      Message boxes have no provision for passing in a message
procedure address.  Because the call does not return until the
message box is dismissed, the message box cannot be subclassed by the
application before it is displayed.

      Applications sometimes want the standardized message box
appearance and the simplicity of message box presentation, but need
to add a small amount of additional functionality.  An example is an
application that may need to display an additional message when a
particular pushbutton is pressed, but leave the first message box on
the screen.  Another example is an application that needs to provide
special help processing when the help pushbutton is pressed, because
helps reside in a file other than the standard HLP file that PM
expects.  This functionality can be provided only through a subclass
of the message box, which PM neither provides nor allows.

      There are two keys to subclassing a PM message box:  the
message box ID and an input hook.  One of the parameters to the
WinMessageBox API is an ID to be assigned...