Browse Prior Art Database

Efficient Overriding of Control Repainting while Minimizing Visual Impact

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

Publishing Venue

IBM

Related People

Morgan, SA: AUTHOR [+2]

Abstract

An application that wants to enhance the workings or appearance of a control in an OS/2* Presentation Manager* (PM) environment will often need to prevent the control from repainting while special operations are performed. An example is an application that wants to enable wrapped text for radiobuttons. Since PM draws the focus box assuming a single line of text, the application will have to take over the focus box drawing itself.

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

Efficient Overriding of Control Repainting while Minimizing Visual
Impact

      An application that wants to enhance the workings or appearance
of a control in an OS/2* Presentation Manager* (PM) environment will
often need to prevent the control from repainting while special
operations are performed.  An example is an application that wants to
enable wrapped text for radiobuttons.  Since PM draws the focus box
assuming a single line of text, the application will have to take
over the focus box drawing itself.

      When the WM_SETFOCUS message is processed by the radiobutton,
the application needs to pass it on to the default processing to
receive all of the standard focus processing that PM provides.
However, the application does not want the focus box being displayed
by PM, since the application itself will draw its own version of it,
and if PM's version appears and then disappears it will present a
flashing appearance that will be unsettling to the user.

      This type of processing need can be found in any control that
an application wishes to enhance.  Implementing this presents
multiple problems to the application, however.  This disclosure
presents a technique that solves all of these problems in the safest,
most efficient manner possible.

The problems presented fall into four categories:

1.  The application must ensure that PM does not cause the control to
    refresh while the special processing is being performed.

2.  The application must ensure that its processing does not change
    the control's visibility from what it was.

3.  The application must ensure that any painting that the control
    requires, caused by other interactions while this processing is
    going on, is reflected when the processing is finished.

4.  The application must do the above three things without causing
    any unnecessary painting of the control that would cause a
    flashing effect to be seen by the user.

      The algorithm that will solve these problems involves taking
all of these needs into consideration, as follows:

o   The WinQueryUpdateRect API should first be called for the
    control, and returns whether or not the control currently needs
    to be repainted.  This result should be remembered.

o   The control should have its painting halted while the special
    processing is underway.  This is enabled by calling the
    WinEnableWindowUpdate API with a parameter of FALSE to indicate
    updates should be halted.  This API in essence changes the
    visibility state of the control to be invisible, so any changes
    made to the control will not be reflected on the screen.

o   This API should only be called, however, if the control is
    currently visible.  The WinIsWindowVisible API will tell the
    application the current visibility state.  The control may have
    been made in...