Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1997-03-11
2001-12-25
Maung, Zarni (Department: 2154)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000
Reexamination Certificate
active
06334157
ABSTRACT:
TECHNICAL FIELD
The present invention relates generally to data processing systems and, more particularly, to a method and system for programmatically providing direct access to user interface elements of an application program.
BACKGROUND OF THE INVENTION
People with disabilities have had difficulty being integrated into the workforce. Such integration into the workforce is hampered by difficulties in working with computers. Consequently, accessibility aids have been developed to facilitate computer operation by disabled users. For example, a “screen reader utility” is a type of accessibility aid that reads information displayed on a video display to a visually impaired user, which enables the user to utilize the computer. These screen reader utilities operate by intercepting and analyzing information sent to the video driver. That is, when an application program wants to display information on the video display, it sends the information to a video driver, which is responsible for displaying the information on the video display. For example, when an application program wants to display a character, such as an ASCII character, the program sends an ASCII character code to the video driver indicating which character of the ASCII character set to display on the video display. The screen reader intercepts this ASCII character code, determines the phonetic sounds associated with the ASCII character, and audibly outputs the phonetic sounds to the visually impaired user, so that the visually impaired user can perceive the character written to the video display.
Although these screen reader utilities work well with text, screen reader utilities do not work well with graphical elements, such as the well-known graphical elements depicted in
FIGS. 1A-1D
. For example,
FIG. 1A
depicts a window with a menu bar, a title bar, a tool bar, a combo box, a header control, a tree view, a status bar, a list view, a size grip, and a scroll bar.
FIG. 1B
depicts a window with a progress bar, a check box-style button and status text.
FIG. 1C
depicts a window with an edit box and a push button-style button, and
FIG. 1D
depicts a window with a tab control, a list box, and a radio button-style button.
When a program wants to display a graphical element, like a button, on the video display, it sends a bitmap to the video driver containing the representation of the button. The screen reader intercepts this bitmap, and the screen reader then attempts to interpret the bitmap. To facilitate this interpretation, the screen reader maintains a database containing both the bitmaps representing the graphical elements utilized by a particular application program and an indication of what each bitmap represents. The screen reader compares the intercepted bitmap with the bitmaps in the database to determine the graphical element represented by the intercepted bitmap, and then the screen reader audibly indicates to the user what the graphical element is. In this manner, the screen reader audibly indicates to the user what information is displayed on the video display, including both text and graphical elements.
This method for analyzing a graphical element has a drawback: the screen reader utility must know in advance the exact bitmaps of the graphical elements utilized by a particular application program. Even the slightest variation between the bitmap sent to the video driver and the corresponding bitmaps in the database will prevent a match from being made, and the screen reader will be unable to identify the graphical element. In this case, the user receives an incomplete understanding of the information on the video display, thus reducing his or her effective use of the computer system. Hence, conventional screen readers typically contain the bitmaps of the graphical elements utilized by a particular application program; conventional screen readers are thus application dependent. In other words, conventional screen readers cannot convey to a user information regarding graphical elements displayed by an application program without having a priori knowledge of the exact form of its graphical elements, and the screen reader will not work on another application program without having similar a priori knowledge. As a result of these limitations, screen readers, and accessibility aids as a whole, are unreliable and do not convey sufficient information to a disabled user so that the user can understand all elements that are displayed on the video display, including both text and graphical elements. It is thus desirable to improve the way in which accessibility aids identify the elements displayed by an application program to help integrate disabled users into the work force.
Because the detailed description assumes knowledge of various well-known object-oriented techniques, an overview of such techniques is provided below. In some cases, this overview is specific to the C++ programming language.
Two common characteristics of object-oriented programming languages are support for data encapsulation and data type inheritance. Data encapsulation refers to associating functions with data, and inheritance refers to declaring a data type in terms of other data types. Thus, inheritance provides for a hierarchy of data types, where the data types defined lower in the hierarchy share the structure or behavior of the data types defined higher in the hierarchy.
In the C++ programming language, data encapsulation and inheritance are supported through the use of classes. A class is a defined type, and a class declaration describes the data members and function members of the class. The data members and function members of a class are bound together such that the function members operate on a particular instance of the data members of the class. An instance of a class is also known as an object of the class. A class thus provides a definition for a group of objects with similar properties and common behavior.
To allocate storage for an object of a particular type (class), an object is instantiated. The term “instantiating” refers to allocating memory for data members and associating the data members with the function members. Once instantiated, the function members of the particular object can be invoked to access and manipulate the data members. In this manner, the function members implement the behavior of the object, and the object provides a structure for encapsulating data and behavior into a single entity.
To support the concept of inheritance, classes may be derived from (based upon the declaration of) other classes. A derived class is a class that inherits the characteristics—data members and function members—of its base classes. A class that inherits the characteristics of another class is a derived class, and conversely, a class that does not inherit the characteristics of another class is a primary (root) class. A class whose characteristics are inherited by another class is a base class. A derived class may inherit the characteristics of several classes and have several base classes, which is known as multiple inheritance.
A class may also specify whether its function members are virtual. Declaring that a function member is virtual allows the function to be overridden by a function of the same name and type in a derived class. If a virtual function is declared without providing an implementation, then it is referred to as a pure virtual function. A pure virtual function is a virtual function declared with the pure specifier (“=0”). If a class specifies a pure virtual function, then any derived class needs to specify an implementation for that function member before an object of that class can be instantiated. A class which contains at least one pure virtual function member is an abstract class.
FIG. 2
is a block diagram illustrating typical data structures used to represent an object. An object comprises instance data (data members) and function members, which implement the behavior of an object. The data structures used to represent an object comprise instance data structure
201
, vi
Atkinson Robert G.
Brown Nathaniel S.
Butler Laura J.
Lowney Gregory C.
Oppermann Charles
Banner & Witcoff , Ltd.
Maung Zarni
Microsoft Corporation
LandOfFree
Programmatically providing direct access to user interface... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Programmatically providing direct access to user interface..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Programmatically providing direct access to user interface... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2585869