Browse Prior Art Database

Enhancing Dialog Visibility during Intensive Application Startup Processing

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

Publishing Venue

IBM

Related People

Morgan, SA: AUTHOR [+2]

Abstract

In an OS/2* Presentation Manager* (PM) application, the WM_PAINT messages that cause most windows to repaint are posted to the message queue by PM. It is not until the WM_PAINT message is read off the queue that the actual repainting of the window occurs. Windows with this type of painting behavior are painted asynchronously to the actual calls that notify PM of the need to repaint.

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

Enhancing Dialog Visibility during Intensive Application Startup
Processing

      In an OS/2* Presentation Manager* (PM) application, the
WM_PAINT messages that cause most windows to repaint are posted to
the message queue by PM.  It is not until the WM_PAINT message is
read off the queue that the actual repainting of the window occurs.
Windows with this type of painting behavior are painted
asynchronously to the actual calls that notify PM of the need to
repaint.

      With this design, the message queue must be accessed before the
repaint occurs.  This causes a problem when a repaint is required
while the application is performing lengthy operations in the
processing of another message.  Until the processing is finished and
the queue is requested to provide another message to process, the
WM_PAINT messages are unable to cause the repaint.

      An example of this sort of situation is when an application is
first started and has to perform a great deal of initialization.  The
standard practice is to display a dialog that tells the user to
"Please Wait" while the initialization proceeds, perform the
initialization, then remove the "Please Wait" dialog and present the
application ready for user input.  If the painting of the dialog is
done asynchronously, depending on the processing of WM_PAINT messages
from the message queue, the "Please Wait" dialog will not be painted
until the initialization processing completes and the message queue
is free to process another message, at which time the dialog is no
longer needed.  The user will therefore not have seen the "Please
Wait" dialog and will be wondering if the application is doing
anything at all while the initialization is being performed.

      Described is a technique that will ensure that the "Please
Wait" dialog will be displayed to the user as soon as it is
requested, even if the application is tying up the PM message queue
with the processing of another message.

      PM applications must always try to be designed such that the PM
message queue is always available to process messages.  This means
that any extensive processing should be done on a thread different
from the main PM thread that the application is started on and on
which the message queue is processed.  However, for some
application's initialization processing, such as that for LAN
NetView* View, it is not realistic to perform the processing on
another thread.  The initialization processing must thus be performed
on the main PM thread, tying up the message queue and giving rise to
the painting problem described above.

      The solution to this paintin...