Browse Prior Art Database

User Interface for Interactive Error Handling for Matrix Type Data Entry

IP.com Disclosure Number: IPCOM000103592D
Original Publication Date: 1993-Jan-01
Included in the Prior Art Database: 2005-Mar-18
Document File: 3 page(s) / 140K

Publishing Venue

IBM

Related People

Li, SG: AUTHOR [+2]

Abstract

Disclosed is a design that uses a separate window, the Error List Window, to give the user a list of the errors in the current matrix-type data entry application. The user can interactively switch between the Error List Window and the application window to view all the errors and select an error to have the fields that caused the error highlighted in the application window. This error list can be refreshed after corrections are made and closed when no longer needed.

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

User Interface for Interactive Error Handling for Matrix Type Data Entry

       Disclosed is a design that uses a separate window, the
Error List Window, to give the user a list of the errors in the
current matrix-type data entry application.  The user can
interactively switch between the Error List Window and the
application window to view all the errors and select an error to have
the fields that caused the error highlighted in the application
window.  This error list can be refreshed after corrections are made
and closed when no longer needed.

      One typical reason for using a matrix (also called a
two-dimensional multi-cell) for data entry is to provide the user
with more freedom in entering data.  It is assumed that the user
would like to use the same input device when moving the entry cursor
and entering numbers or characters into cells.  During the data entry
session, the user should be allowed to freely move the entry cursor
to any cell for further actions.  The user should not be stopped or
interrupted for skipping data entry or entering unmatched or
incorrect data in a cell.  For some specific applications of this
type, there are certain rules for the data in each category and
certain relationships among data values belonging to different
categories.  One example is using a matrix for database table
definition.  There are rules that should be applied on the column
name, column type, column length, and whether the column is data
required or not.  Some error checking on a particular data cell
cannot be done before the availability of data in another cell.  For
example, a column defined as part of the primary key must not allow
null value.  But, before the primary key is defined, there is no
basis to pinpoint a column that is not data required in the primary
key as being an error.

      When the user initiates the action for error checking, the
error checking program will scan through the input fields and
generate a list of errors that will be displayed in a separate window
(the Error List Window).  The user can vertically and horizontally
scroll through the Error List Window to view or highlight errors.
When the user selects an error in the Error List Window, this error
will be displayed and highlighted, and all the cells in the
application program that generated this particular error will be
highlighted as well.  The highlighted cells will remain highlighted
until an action is taken to end the debugging session for this
particular error.  Those actions include: selecting another error in
the Error List Window, refreshing the Error List Window, and choosing
an action in the application window.

      For each error, the error checking program keeps an ordered
list of the fields that caused the error according to some rules
specific to the application.  When the user flips from the Error List
Window to the application window after an error in the list is
selected, the program will put the keyboard...