Browse Prior Art Database

Communication between Tasks not Programmed as Communicating Tasks

IP.com Disclosure Number: IPCOM000114098D
Original Publication Date: 1994-Nov-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 4 page(s) / 151K

Publishing Venue

IBM

Related People

Simmons, J: AUTHOR [+2]

Abstract

It is often required to transfer information between programs running on a computer. While a number of operating systems, such as Windows, provide for such transfer between tasks that are programmed as communicating tasks, many programs are not designed to communicate and cannot normally take advantage of this facility.

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

Communication between Tasks not Programmed as Communicating Tasks

      It is often required to transfer information between programs
running on a computer.  While a number of operating systems, such as
Windows, provide for such transfer between tasks that are programmed
as communicating tasks, many programs are not designed to communicate
and cannot normally take advantage of this facility.

      A specific example arises in the use of Garden software under
Windows 3.1.  Garden is currently written to be integrated to any
task using DDE/OLE, but cannot be integrated with any task that does
not support these communication methods.  Using the approach
described below, Garden may be integrated with any task whose inputs
and outputs are displayed on the screen using Windows calls.

      The approach is also applicable to Windows NT*, OS/2**,
X-windows and other similar systems.

      The approach involves enhancing the window system task-to-user
communication to permit user defined task-to-task communication.

      In particular, a call is added to Windows that permits Task A
to 'dynamic bind' to an input or output windows field that belongs to
another Task B.  When Task A makes the dynamic bind call, the mouse
enters a "define field" mode, indicated by a special cursor shape.
When the mouse click is made over a field in this mode a handle to
the windows field is returned to Task A, EVEN THOUGH THE FIELD
BELONGS TO TASK B.  The selected field is called a 'foreign field'
for Task A.  Task A can then use this handle in the normal way to
interrogate or set the foreign field or to trigger on changes to it.

      It should be noted that this will only communicate the
character values as given to the window system by the application,
and not necessarily the true internal numeric values.  Thus, there
may be problems in communicating values that are not currently
displayed on the screen, depending on the precise window system
implementation.  Nevertheless, many programs are character based, and
the utility of such programs will be considerably enhanced by the
technique described.

      An example of how a system so enhanced will appear to the user
in typical applications is described below.

General communication between tasks

      In this example the user can connect two tasks 'A' and 'B'
using a generic 'connection box' task.  Task A is a simulation or
spreadsheet that writes its numeric output to fields on the screen,
say fields Aa, Ab etc of window A.  Task B is a visualisation task
that takes numbers defined in input fields Ba, Bb etc of window B and
displays a visualisation (for example a bar graph) in output field Bo
of window B.  A standard connection application (Task C) uses window
C, with two buttons "Define Input" and "Connect to Output".

      Tasks A and B have no built in communication ability other than
with the user via the windows.  Task C is written using a Windows
'bind' call i...