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

Relocation of Radiobutton and Checkbox Bitmaps to Enable Control Enhancement

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

Publishing Venue

IBM

Related People

Morgan, SA: AUTHOR

Abstract

The OS/2* Presentation Manager* (PM) radiobutton and checkbox controls always paint their bitmaps on the left-hand side of the control, vertically centered in the available space. This presents a problem for applications that desire to relocate the bitmaps to support enhancements to these controls.

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

Relocation of Radiobutton and Checkbox Bitmaps to Enable Control
Enhancement

      The OS/2* Presentation Manager* (PM) radiobutton and checkbox
controls always paint their bitmaps on the left-hand side of the
control, vertically centered in the available space.  This presents a
problem for applications that desire to relocate the bitmaps to
support enhancements to these controls.

      One enhancement that can be provided is for the application to
support text wrapped into multiple lines.  In this case the bitmap
needs to be relocated to be opposite the first line of text.  A
second enhancement is for the application to support right-to-left
languages, such as Arabic.  In this case the bitmap needs to be
relocated to the right side of the control.

The repainting of these bitmaps is complicated by several factors:

o   The bitmaps each have four states in which they can be presented,
    and all eight bitmaps are included in a single system bitmap.

o   There is no way to tell PM to stop painting the bitmap in its
    default position.

o   The need for the bitmaps to be repainted is sometimes not
    indicated by the receipt of a WM_PAINT message.

      This disclosure describes a technique that allows an
application to relocate these bitmaps, overriding PM's painting of
them, while still presenting the various states correctly whenever
they change.

      Repainting the bitmap is triggered by three different messages
received in the message procedure for the radiobutton or checkbox.
These messages are WM_PAINT, BM_SETCHECK and BM_SETHILITE.  When one
of these messages is received, the application should perform its own
painting as described below.

      These bitmaps have four different states in which they can be
presented.  They can be checked or unchecked, highlighted or
unhighlighted.  Any of the four combinations are possible.  A
BM_SETCHECK message is received when the checked state changes, and a
BM_SETHILITE message is received when the highlight state changes.
The receipt of either of these messages, or of a WM_PAINT message,
indicates that the application must repaint the relocated bitmap to
display the current state.

      Special care is required to ensure that a repaint is
appropriate when a BM_SETCHECK or BM_SETHILITE message is received,
since there is no guarantee that the window is visible at that time,
and to avoid flickering caused by unnecessary updating of the screen.
The WinIsWindowVisible API will reveal whether or not the window is
currently visible.  If not, the message should just be passed to the
default message procedure and no repainting performed until the
window becomes visible.

      If the bitmap does need to be repainted, screen updates for the
control must be halted when the message is sent on to the default PM
message procedure so that PM does not redraw...