Browse Prior Art Database

Reusable User Interface Message Handler

IP.com Disclosure Number: IPCOM000105767D
Original Publication Date: 1993-Sep-01
Included in the Prior Art Database: 2005-Mar-20
Document File: 4 page(s) / 103K

Publishing Venue

IBM

Related People

Bezviner, DE: AUTHOR

Abstract

Disclosed is a reusable piece of code. The code is part of a message handler, specifically the part that accepts messages and displays or prints information as a result. It is reusable for many different applications and testcases, and is adaptable to several different environments. It is immediately applicable to object-oriented systems, WINDOWS* programs, and Presentation Manager** programs.

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

Reusable User Interface Message Handler

      Disclosed is a reusable piece of code.  The code is part of a
message handler, specifically the part that accepts messages and
displays or prints information as a result.  It is reusable for many
different applications and testcases, and is adaptable to several
different environments.  It is immediately applicable to
object-oriented systems, WINDOWS* programs, and Presentation
Manager** programs.

      The main idea is to define a set of messages so that each
message contains a limited amount of information.  The reusable code
remembers a limited amount of information, and takes action depending
on the message type and remembered data.

      Consider a user interface for displaying information.  Such an
interface would have several different fields, some of them with
constants such as labels, and some of them with updateable
information.  As the application progresses, it sends a message to
the message handler, which in turn displays something in the
appropriate place.

      Each display field has some kind of ID associated with it.  In
WINDOWS, this would be the control ID the programmer assigned it at
compile time.  We will call this the "field ID" from here on.

Define message types as follows:

   - INFO_INTEGER
   - INFO_TEXT

A message of either type would have the following fields:

   - field ID of corresponding display field (note that this is not
     dependent in any way on the contents of the field), and

   - information to display, or for text, a pointer to the
information
     string.

     This basic scheme is very simple, and can be extended to handle
other generic types as well.  As an example, one possible interface
has the following types of information:

   - the progress indicator field, containing either "( )" or "(x)",

   - integer and text information fields associated with fixed
fields,
     i.e., deadlock count, repetition count, and

   - integer and text information fields associated with a particular

     testcase or application, e.g., number of rows counted.

For this interface, the message handler must perform the following
tasks:

   - display text or integer information in a fixed field,
   - initialize text or integer information in an
application-dependent field,
   - update information in an application-dependent field, and
   - update the progress field (move the x).

One approach would be to define a new message type:

   - PROGRESS_BOX

      Associated with this type would be up to two fields: the field
ID already containing an x, and the field ID of the new field to put
the x in.  When this message is received, the message handler has to
remove the x from its old field, and put the x into the new field.
One result of this approach that can be improved is that when an
application progresses, it will frequently have to send two messages,
one PROGRESS_BOX and one INFO_...  Another result that...