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

Overcoming Presentation Manager Propensity for Spontaneously Dismissing Modal Dialogs

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

Publishing Venue

IBM

Related People

Johnson, KD: AUTHOR [+3]

Abstract

Disclosed is a technique that an application can use to prevent the IBM* OS/2* Presentation Manager* (PM) from gratuitously dismissing any modal dialogs that are currently displayed when the user closes an application window from the Window List.

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

Overcoming Presentation Manager Propensity for Spontaneously Dismissing
Modal Dialogs

      Disclosed is a technique that an application can use to prevent
the IBM* OS/2* Presentation Manager* (PM) from gratuitously
dismissing any modal dialogs that are currently displayed when the
user closes an application window from the Window List.

      One of the irritating and possibly catastrophic design
decisions implemented in PM is to dismiss all modal dialogs of an
application when any window in that application is closed by the user
from the system Window List window.  This design dates from the early
days of PM, when the standard paradigm was for an application to have
a "main" window, and only that window was added to the Window List.
When that window was closed from the Window List, the application
would end, and therefore any modal dialogs must be dismissed to free
them from their PM-internal message loops.

      However, the new paradigm is for an application to no longer
have a main window, and to have all major windows added to the Window
List.  The user can use the convenience of the Window List to close a
window in the application without affecting any of the other windows.

      When the application has any modal dialogs displayed when the
user closes a window from the Window List, PM still persists in its
old design and dismisses these modal dialogs.  For a user in the
process of entering attributes or possibly a large amount of text
data using these modal dialogs, the dismissing by PM of the dialogs
can result in significant data loss, as well as a very irritated
user.

      There are two aspects to preventing PM from dismissing all of
the modal dialogs of the application when the user closes a window
from the Window List:
  o  The application must prevent itself from terminating if the
      window being closed was not the last window being displayed by
      the application.
  o  The application must prevent the modal dialogs from being
      dismissed by PM while still allowing the indicated window to be
      closed.

      When a window is closed from the Window List, PM posts a
WM_QUIT message to the message queue of the window's application.
The WM_QUIT message causes the application to drop out of the message
loop, perform termination processing and exit.  This design again
reflects the outdated belief that only the main window is in the
Window List, and when the user closes it the entire application
should end.

      One of the undocumented aspects of the WM_QUIT message when
posted by the Window List is that the window handle of the window
that the user wants to close is contained in the second parameter
passed with the message.  The application therefore has the
information required to be able to perform checks when the message
loop is exited and prevent the application from ending.

      If there is a window handle in the second message parameter,
the app...