WO1997007454A9

WO1997007454A9 - Processing apparatus and method and computer software therefor

Info

Publication number: WO1997007454A9
Application number: PCT/GB1996/002018
Authority: WO
Filing date: 1996-08-16
Publication date: 1997-04-03

Abstract

The application discloses computer software which is capable of generating the following objects: a toolbar program object; a calculator/spreadsheet program object; a note program object; a multicolumn list/database object, and a tabbed notebook-like workspace program object. Each program object uses little memory resources, and can act as both an 0.LE 2.0 container and server (i.e. can be both embedded and linked, supports drag-and-drop, and also support in-place activation).

Description

PROCESSING APPARATUS AND METHOD AND COMPUTER SOFTWARE THEREFOR

The present invention relates generally to a processing apparatus and method. It has particular application to object orientated business applications, such as might be executed on a personal computer using Microsoft Windows 95 (trade mark) computer software. The invention also relates to computer software for the processing apparatus and methods disclosed herein.

As used herein, the term "object" includes any computer software program which is encapsulated both in code and also in data in such a way that it can be moved and executed freely and can be used both as a container of other objects and as a server in its own right. An object may also be defined as any document which has been embedded in or linked to another document.

General

This invention relates generally to data processing apparatus methods and is concerned in the most important example with improving the usefulness of personal computers. Considerable advances have been made in recent years in improving the user interface of personal computer software, in increasing the processing power available and in optimising the use of that processing capability to offer relevant and powerful functions to the user. In terms of user interfaces, attention has focused on graphical user interfaces (GUI's) with most commercial software being provided in a form suitable for the Microsoft WINDOWS (trade mark) interface and the DOS operating system. Applications in the primary areas of word processing, spread sheets and databases have increased in power but have also increased considerably in program size. This has the consequence that the time taken to load an application increases, as does also the demand for RAM. It is of course the case that the processing speed and available RAM for each generation of personal computers is increased substantially over the previous generation. However, in a typical configuration, this increased speed and RAM capability is primarily absorbed by the ever-growing size of the main application packages. The typical user wishing to have word processing, spreadsheet and database functions available simultaneously will, despite improvements in hardware, still be frustrated at the time taken to perform practical operations involving a blend of word processing, spread sheet and database functions.

GUI's offer considerable benefits to users not familiar with the detail of an operating system but generally speaking leave open a number of key areas in which the user is provided with no "graphical" assistance and is required to work close to the operating system level. A principal example is in the storage and retrieval of files.

There is now commercially available from Microsoft Corporation a product styled WINDOWS 95 (trade mark) which builds upon the WINDOWS interface and provides an operating system environment which is a substitute for DOS.

Whilst it is expected that this product will improve still further the user interface, the problems outlined above will generally speaking remain.

In an allied development, Microsoft Coφoration are offering applications which embody the principles of object-orientated programming. Whilst these principles have been established in theoretical terms for many years, there has hitherto been no sensible use made of the principles in personal computer software. In the context of the applications now made available by Microsoft Coφoration, advantage is taken of principles of object-orientated programming to improve the interchange of data between applications. It becomes possible for an object "owned" by a spreadsheet program to be embedded, for example, in a document created by a word processing package. Whilst these are important advances, they do not take full advantage of the power of the object- orientated approach as identified in the present invention and, again, do not in any real sense address the problems outlined above of the ever-growing size of basic applications. In ways which will be detailed and exemplified below, the present invention aims to provide the personal computer user with access to the most often used word processing, spread sheet and database functions in a way which makes minimal demands on memory resources and in a way which radically improves the ability of the user to organise, in a data processing sense, his working environment. In one form, the present invention stems from a recognition, unique to the present inventors, that a large proportion of the word processing, spread sheet and database requirements of a typical personal computer user can be provided through a number of relatively small modules or building blocks, provided that the content of each such building block is very carefully controlled. The loading time and memory requirements can in this way be reduced to such an extent that the user may have several instances of each application open at a time without suffering any material hardware based limitation. Moreover, by diligently controlling the form of each building block so that it complies rigorously with the principles of object- orientated programming, there can be achieved previously unseen advantages in the interchange of data between applications and between users.

In one aspect, the present invention relates to computer software having :- a) a specific business related application; b) less than 500 kbytes of executable code; c) the ability to generate an object which can be embedded and linked, which has drag-and-drop capability, and which can be edited in-place; d) the ability to act both as a container and a server.

These features (and others) can yield software which can provide the relevant application with the technical effect of small size, fast operation (implicit in the small size), and full interoperability with other such applications.

Specific business related applications envisaged by the invention include a calculator application, a note application (on which notes can be made), a list application (with which a list can be made), and a work application (for organising work which has been carried out). Preferably, the software has less than 400, more preferably less than 300, kbytes of executable code. In fact, the calculator software disclosed herein has roughly 270 kbytes of executable code, whilst the note software has roughly 160 kbytes, the list software roughly 340 kbytes, and the work software roughly 188 kbytes. By comparison, Microsoft Excel (trade mark) has over 4 million bytes of executable code, whilst Microsoft Word (trade mark) has over 3 million bytes.

Preferably, the software has the ability to generate an object, and individual data items contained within that object can be dragged and dropped. This can afford considerably more flexibility than is conventionally afforded.

Preferably, the software has the ability to generate an object in template form.

Preferably, the software has the ability to generate an object which, as a default, takes up less than the full amount of available space on the display of a display means.

The present invention extends to a suite of computer software as aforesaid. The present invention also extends to a computer when programmed with the computer software or software suite as aforesaid.

The present invention also extends to the use of a computer when programmed as aforesaid.

Toolbar

In one aspect, the present invention relates to a processing apparatus and method, and more particularly to the generation of a toolbar for launching various applications within an object oriented environment.

It is known to employ a toolbar for launching applications within an object oriented environment, but such toolbars lack versatility.

According to the present invention, there is provided processing apparatus, comprising: input means for receiving command signals; processing means for generating a toolbar signal for displaying a representation of a toolbar on a display means and an object signal for a representation of a computer object on the toolbar, the toolbar and object signals being generated in such a way that, in response to a given drag and drop command signal from the input means, the object representation would appear on the display means to be dragged from the toolbar and dropped at a specified location; and output means for outputting the toolbar and object signals to the display means.

By providing the ability to drag and drop the representation of the object from the toolbar, the present invention can afford the important technical effect of considerably more operational versatility than has hitherto been achievable. The processing apparatus would usually be used with a means for displaying the output signals from the processing means.

Preferably, the processing means is adapted to create the object in response to the object representation being dragged and dropped from the toolbar representation. This has been found to be a particularly convenient way of putting the invention into practice.

Preferably, the object representation when on the toolbar representation is iconic, and remains iconic when the representation has been dragged from the toolbar representation. Alternatively, the object representation when on the toolbar may be iconic, but may change to the appearance of the in-place object when it has been dragged and dropped off the toolbar representation. Hence the user may be presented with the choice between dragging as an icon or dragging as an object. Preferably, the processing means is adapted to generate the toolbar signal such that the toolbar representation would appear on the display means to be on top of any other active window, so that the toolbar can be clearly seen.

Preferably, the processing means is adapted, in response to a command signal from the input means which would have the appearance on the display means of dragging and dropping a representation of a computer application onto the toolbar representation, to load the computer application onto the toolbar. The ability to "drag and drop" a given application onto the toolbar to load it provides the user with useful functionality.

Preferably, the processing means is adapted, in response to a command signal from the input means, to create a selected object with a given template. This can considerably facilitate the execution of objects.

In a related "toolbar" aspect, there is provided a processing method, comprising: receiving command signals; generating a toolbar signal for displaying a representation of a toolbar on a display means and an object signal for displaying a representation of a computer object on the toolbar, the toolbar and object signals being generated in such a way that, in response to a given drag and drop command signal, the object representation would appear on the display means to be dragged from the toolbar and dropped at a specified location; and outputting the toolbar and object signals to the display means.

Preferably, the object is created in response to the object representation being dragged and dropped from the toolbar representation.

Preferably, the object representation when on the toolbar representation is iconic, and remains iconic when the representation has been dragged from the toolbar representation.

Preferably, the object representation when on the toolbar is iconic, but changes to the appearance of the in-place object when it has been dragged and dropped off the toolbar representation.

Preferably, the toolbar signal is such that the toolbar representation would appear on the display means to be on top of any other active window.

Preferably, in response to a command signal which would have the appearance on the display means of dragging and dropping a representation of a computer application onto the toolbar representation, the computer application is loaded onto the toolbar.

Preferably, in response to a command signal, a selected object is created with a given template.

Calculator

In another aspect, the present invention relates to a processing apparatus and method, and is particularly concerned with the use of personal computers to carry out simple or complex mathematical calculations.

The idea of a screen representation of a keypad operable either through key strokes or a mouse is now in wide use and has proved extremely useful. It has an important limitation, however; it essentially works well only for single computations and is of no benefit in performing "what if projections. A further limitation is that the calculated result exists only as a screen representation and must be recorded either manually or using some other software application.

Some of the limitations of the calculator are addressed in spreadsheet applications which now offer extremely powerful computation facilities, ideal for repeated use with changing variables and well-suited to "what if projections. Spreadsheets have the disadvantage, however, that they are not intuitive to the inexperienced user and require a substantial effort to be made in setting up the spreadsheet before a practical use can be made. An equally important disadvantage is that the very power of a spreadsheet application places very heavy demands on the storage and processing capabilities of a computer.

It is an aim of this aspect of the present invention to provide an improved processing apparatus and method affording the strengths of both the calculator and spreadsheet approaches with the drawbacks of neither.

According to the present invention, there is provided a processing apparatus comprising: means for generating on a display means a representation of a keypad; input means for entering by reference to said keypad representation operands and operators in discrete data entry elements; computational means for deriving results from the data entry elements; storage means for storing a list of previously entered elements with corresponding results; and means for generating on said display a representation of said list. By providing a visual representation of a keypad, together with a visual representation of a list (also termed herein "tallyroll") showing data entry elements and results, the user can be presented with apparatus which may afford the technical advantages of both the calculator and spreadsheet approaches. The technical effects of reduced storage requirements and reduced execution time can also be afforded.

The processing apparatus would usually be used with a means for displaying the output signals from the processing means.

Preferably, the input means further comprises means for editing the elements with reference to said representation of said list, with said computational means serving to update said results in response to said editing. By providing an editable list, the user may be afforded further useful functionality.

Preferably, each data entry element includes a label for referencing said element. Preferably, the apparatus further comprises processing means for assigning to each label a value representative of the data entry element, and a selected label can be entered by the input means as an operand. By these features, the user can enter formulae into a calculation which may be based on previous labelled elements in the list, hence enabling "what if projections to be performed.

Preferably, the list is in row and column format, and has as a default, before any data entry elements have been entered, less than twenty, more preferably less than ten, even more preferably less than seven, rows and columns. This feature can enhance the ease of use of the object.

Preferably, the list representation generating means is adapted to increase the size of the list in accordance with the number of data entry elements. In this way, no more rows and columns are generated than are necessary for the puφoses of the list.

Preferably, the apparatus further comprises means for locking a selected data entry element or a selected portion thereof, so that the element or portion thereof cannot be modified (unless unlocked).

Preferably, in response to user input entered via the input means, the keypad representation generating means is adapted to generate on said display means a representation of at least one alternative keypad. Hence a keypad may chosen specific to a particular need.

Preferably, the computational means comprises means for backsolving an expression. This feature can provide the user with useful functionality, in that the facility to solve complicated equations is provided. The computational means may further comprise means for deriving from the expression an expression tree, the backsolving means being adapted to backsolve using the expression tree derived by the deriving means. This has been found to be a particularly effective technique for backsolving. The features concerning backsolving may be provided independently.

In a related aspect, there is provided a processing method comprising: generating on a display means a representation of a keypad; entering by reference to said keypad representation operands and operators in discrete data entry elements; deriving results from the data entry elements; storing a list of previously entered elements with corresponding results; and generating on said display a representation of said list.

Preferably, the elements are edited with reference to said representation of said list, said results being updated in response to said editing.

Preferably, each data entry element includes a label for referencing said element.

Preferably, a value is assigned to each label representative of the data entry element, and a selected label can be entered as an operand. Preferably, the list is in row and column format, and has as a default, before any data entry elements have been entered, less than twenty, more preferably less than ten, even more preferably less than seven, rows and columns.

Preferably, the size of the list is increased in accordance with the number of data entry elements. Preferably, a selected data entry element or a selected portion thereof is locked.

Preferably, in response to user input, a representation of at least one alternative keypad is generated on said display means.

Preferably, the results deriving step comprises the step of backsolving an expression. The results deriving step may further comprise the step of deriving from the expression an expression tree, the backsolving using such expression tree.

List

In a further aspect, the present invention relates to a processing apparatus and method, particularly of the type which can generate a list of data in row and column format.

Computer spreadsheet programs (such as Microsoft Excel (trade mark)) are known which can arrange data into row and column format. However, these suffer from a number of disadvantages. Firstly, sorting, filtering and other actions to be performed on the data are time consuming and to an extent counter- intuitive.

Secondly, they can lack versatility and be rather cumbersome (a typical spreadsheet takes up over two megabytes of memory).

The present invention seeks to solve these problems, and particularly to provide a technique for producing a list which is easy and quick to use. According to the present invention, there is provided processing apparatus, comprising: input means for receiving data in the form of input signals; processing means for arranging the data into row and column format and generating output signals based on the arranged data, and for generating a respective action symbol signal, for each row or column of data, which can cause a respective action symbol to be displayed on a display means in conjunction with each row or column, the processing means being such that the symbol for a particular row or column can be selected via the input means and such that selection of that symbol causes a specified action to be performed on the particular row or column; and output means for outputting the output signals and action symbol signals to the display means.

By providing a respective action symbol in conjunction with each column or row which can be selected to cause a specified action to be performed on the column or row, actions specific to that column or row can be performed quickly with a minimum of input on the part of the user.

The processing apparatus would usually be used with a means for displaying the output signals from the processing means. Preferably, the processing means is adapted to generate an action bar signal so that the action symbols can be displayed on the display means in an action bar. This can permit "one-touch" actions to be performed in an intuitive way, using the action bar. Preferably, the specified action is a sorting action, for sorting the order of the cells in the particular row or column. The sorting action can be extended to multiple rows or columns.

Preferably, the specified action is a filtering action, for selectively filtering the cells in the particular row or column. Preferably, the specified action is a searching action, specific to data in a particular row or column.

Preferably, the apparatus further includes storage means for storing a representation of the arranged data on which the specified action has been performed. In this way, as many different "views" of the data as are required can be stored and accessed when desired.

Preferably, the data for the particular row or column comprises a visual, non-textual data type. This can afford an easy to understand, intuitive way of creating a list, especially if, as is preferred, the visual data type is one of three possible colours - green, yellow or amber, and red (that is, traffic light colours). Preferably, the processing means as a default is adapted to arrange the data into no more than ten rows and ten columns.

This important feature may be provided independently. Hence, in a related aspect concerning the list object, the present invention provides processing apparatus, comprising: input means for receiving data in the form of input signals; processing means for arranging the data into row and column format and generating from the arranged data output signals, the processing means as a default arranging the data into no more than ten rows and ten columns; and output means for outputting the output signals to a display means to generate a visual display of the data in row and column format.

By deliberately restricting the default number of row and columns to no more than 10 (preferably more than 7 or even 5), the apparatus can allow the user to arrange data into a list in a quicker and simpler fashion than has hitherto been possible. Preferably, the processing means is adapted, on receipt of a given command input via the input means, to increase the number of rows or columns. The given command may be a drag and drop command.

Preferably, the apparatus further comprises storage means in which is stored at least one template into which the data can be arranged. This feature can permit the user to select one or more pre-designed outlines for a particular puφose. For example, templates can be provided for any kind of list which might be required, from diaries to inventories, from project plans to flight itineraries.

Preferably, the processing means is adapted to permit embedding of a computer object only within an individual cell defined by the row and column format. Hence the usual OLE functionality is overridden to present the user with a relatively intuitive way of inputting objects into the list.

The invention provides, in a related aspect, a processing method, comprising: receiving data in the form of input signals; arranging the data into row and column format and generating output signals based on the arranged data, and generating a respective action symbol signal, for each row or column of data, which can cause a respective action symbol to be displayed on a display means in conjunction with each row or column, such that the symbol for a particular row or column can be selected and such that selection of that symbol causes a specified action to be performed on the particular row or column; and outputting the output signals and action symbol signals to the display means.

Preferably, an action bar signal is generated so that the action symbols can be displayed on the display means in an action bar.

Preferably, the specified action is a sorting action, for sorting the order of the cells in the particular row or column.

Preferably, the specified action is a filtering action, for selectively filtering the cells in the particular row or column. Preferably, the specified action is a searching action.

Preferably, a representation is stored of the arranged data on which the specified action has been performed.

Preferably, the data for the particular row or column comprises a visual, non-textual data type. Preferably, as a default the data is adapted into no more than ten rows and ten columns.

In a further related aspect, the present invention provides a processing method, comprising: receiving data in the form of input signals; arranging the data into row and column format and generating from the arranged data output signals, as a default the data being arranged into no more than ten rows and ten columns; and outputting the output signals to a display means to generate a visual display of the data in row and column format.

Preferably, on receipt of a given command, the number of rows or columns is increased.

Preferably, the given command is a drag and drop command.

Preferably, at least one template is stored into which the data can be arranged.

Preferably, embedding of a computer object is permitted only within an individual cell defined by the row and column format.

Note

In a further aspect, the present invention relates to a processing apparatus and method, particularly of the type which can generate a visual metaphor of a note on a display means.

Applications are known which can generate a visual metaphor of a note. The user can input textual data into such a note, with the note and the textual data on it being displayed on the display means. The note can be saved for future reference.

A fundamental design requirement of such applications is that the user can use the application and save the results of using it quickly and with ease; otherwise the whole point of making a "note" becomes lost.

However, in known applications this design requirement is compromised by the lack of speed and ease with which a document generated using the application can be saved.

The present invention seeks to overcome this problem.

According to the present invention, there is provided processing apparatus. comprising: input means for receiving textual data in the form of input signals; processing means for generating output signals representative of a visual metaphor of a note, with the textual data appearing as at least one line of text on the note, and for generating a default file name in dependence on the text in the note; and output means for outputting the output signals to a display means.

By generating a default filename in dependence on the text in the note, as a default the user need not provide any filename when saving a note document. This can afford the technical effect of quicker and easier drafting of notes.

Preferably, the processing means is adapted to generate the default file name in dependence on a predetermined portion of the text, beginning with the first character of text.

Preferably, the processing means is adapted to generate a title for the note in dependence on the text in the note.

In a related aspect, there is provided processing apparatus comprising a display; means for generating a user editable text area on said display; means for generating a storable file representative of user edited text and means for generating automatically a default file name for said file from user entered text. Preferably, said means for generating automatically a default file name operates to select an initial character string from said user edited text.

In a further related aspect, there is provided processing apparatus comprising a display; and means for generating a user editable text area on said display; wherein said text area is represented by a data processing element which is both a server and a container of objects.

In a further related aspect, there is provided a processing method, comprising: receiving textual data in the form of input signals; generating output signals representative of a visual metaphor of a note, with the textual data appearing as at least one line of text on the note, and generating a default file name in dependence on the text in the note; and outputting the output signals to a display means.

In this, as in every other aspect of the invention, method features analogous to the apparatus features described above can be provided. Work

In a further aspect, the present invention relates to processing apparatus and a processing method, particularly of the type which can organize the storage and retrieval of work files. Considerable efforts have been made to improve the user interface of personal computers. Graphical user interfaces (GUI's) have been developed which facilitate the selection by the user of an application and assist in broad interaction with the application. Generally speaking, however, the retrieval and storage of data is handled through conventional file storage arrangements. Directory structures and strict path and file naming conventions persist, with "tree" drawing procedures and "browse" features offering minimal improvements.

Efficient retrieval of data demands that the user creates in advance directory structures and file naming principles which are optimised for the type of data it is intended to create. In perhaps the majority of cases, it is not possible to predict the data structure that will evolve, with the result that directory structures are most times well below optimal. Changing directory structures and file names is theoretically possible but usually so time consuming as to be impractical.

The integration of applications through the adoption of an object based approach holds the promise of increasing significantly the power, flexibility and accessibility of personal computing. However, the described difficulties of file handling remain and - in a number of ways - the difficulties are compounded by the very power of the object based approach.

It is an aim of this aspect of the present invention to provide an improved processing apparatus and method which is capable of addressing these concerns. According to this aspect of the invention, there is provided processing apparatus, comprising: file storage means arranged into directories which may be local or remote: and processor means and a plurality of objects held in the file storage means. each object being accessible through user actuation of a representation thereof in a display means; wherein said objects can be arranged by the user into main classes and within each main class into sub-classes, each sub-class of one or more objects having associated therewith a compound document with its file stored in a directory of the file storage means, said compound document having the or each object of the corresponding sub-class embedded therein or linked therewith, and all the compound document files corresponding respectively with sub-classes of a main class being stored within a common directory in the file storage means unique to that main class.

Advantageously, there is provided means for generating on the display means a hierarchical tab representation of main classes and sub-classes with each class being selectable through user actuation of a corresponding tab representation in the display means, main and sub-class tabs being hierarchical.

Preferably, the processing apparatus is adapted, on user selection of a particular sub-class tab, to provide a display representation of the compound document corresponding thereto.

As will be appreciated, this invention can allow the user to create a graphical, hierarchical tab structure which is especially adapted to his own requirements. The creation of new main or sub-classes is extremely simple as is the addition of objects to a class or transfer of objects between classes. The association of each main class with a directory and each sub-class with a compound document, proves extremely powerful.

This concept can enable full advantage to be taken of existing file handling structures despite the fact that the user operates in a wholly fresh graphical environment. Because of the one-to-one relationship between main classes and directories, the main classes of the tab structure according to the invention can be shared between users and need not be restricted to any local file environment. Using the existing features of a local or wide area network, including optional password security, the invention can enable the user to have access to a main class which is physically remote, which may have been created by a third party, and which is capable of being shared by a group of users. All this is achievable through simple actuation by the user of a graphical tab representation.

Within a directory, which may then be local or remote and which may be personal or shared, each sub-class corresponds to a compound document stored as a conventional file. Selection of a sub-class, through actuation of a graphical sub- class tab, causes a display of the compound document to be produced, with the calling by name of the document being transparent to the user. In system terms, the compound document file is treated in the same manner as a conventional compound document. In a related aspect, there is provided a processing method, comprising: providing file storage means arranged into directories which may be local or remote; and providing processor means and a plurality of objects held in the file storage means, each object being accessible through user actuation of a representation thereof in a display means; wherein said objects are arranged by the user into main classes and within each main class into sub-classes, each sub-class of one or more objects having associated therewith a compound document with its file stored in a directory of the file storage means, said compound document having the or each object of the corresponding sub-class embedded therein or linked therewith, and all the compound document files corresponding respectively with sub-classes of a main class being stored within a common directory in the file storage means unique to that main class.

Preferably, a hierarchical tab representation of main classes and sub-classes is generated on the display means with each class being selectable through user actuation of a corresponding tab representation in the display means, main and sub¬ class tabs being hierarchical.

Preferably, on user selection of a particular sub-class tab. a display representation of the compound document corresponding thereto is provided. Features of the various applications described above may be combined with the features of any other application or applications.

The calculator, list and note applications may be embedded as objects in other such calculator, list and note objects.

Preferred features of the present invention are now described, by way of example, with reference to the accompanying drawings, in which:

Figure 1 is an overall block diagram of computer apparatus according to the present invention;

Figures 2 and 3 are diagrams showing Microsoft (trade mark) Foundation Classes;

Figure 4 is a diagram of a visual display illustrating a toolbar object according to the present invention;

Figure 5 is a diagram of a visual display illustrating a toolbar shortcut menu;

Figure 6 is a diagram of a visual display illustrating a preferences dialog box;

Figure 7 is a diagram of a visual display illustrating a calculator object as an in-place object in a Microsoft Word (trade mark) application; Figure 8 is a diagram of a visual display illustrating different formats for the toolbar;

Figure 9 is a diagram of a visual display illustrating an edit toolbar dialog box;

Figure 10 is a diagram of a visual display illustrating a details dialog box; Figure 1 1 is a flow diagram summarising the functionality of the toolbar object;

Figure 12 is a diagram of a visual display illustrating the operation of a calculator object according to the present invention;

Figure 13 is a diagram of a visual display illustrating a tallyroll forming part of the calculator object;

Figure 14 is a diagram illustrating how data is stored using the calculator object;

Figure 15 is a diagram of a visual display illustrating a Break Even keypad;

Figure 16 is a flow diagram summarising the functionality of the calculator object;

Figure 17 is an object model diagram illustrating the overall system structure of a calculator engine for use with the calculator object;

Figure 18 is a diagram similar to that shown in Figure 17, but illustrating an expression stack for the calculator engine; Figure 19 is a diagram similar to that shown in Figure 17, but illustrating an operator stack for the calculator engine;

Figure 20 is a diagram similar to that shown in Figure 17. but illustrating an operator table for the calculator engine;

Figure 21 is a diagram similar to that shown in Figure 17, but illustrating a known function table for the calculator engine;

Figure 22 is a diagram similar to that shown in Figure 17, but illustrating a symbol table for the calculator engine;

Figure 23 is a diagram of a visual display illustrating the operation of a list object according to the present invention;

Figure 24 is a diagram of a visual display showing a template for the list object;

Figure 25 is a diagram of a visual display illustrating a sort dialog box;

Figure 26 is a diagram of a visual display illustrating a dropdown selection box;

Figure 27 is a diagram of a visual display illustrating an unfiltered list;

Figure 28 is a diagram of a visual display illustrating a filtered version of the list of Figure 27;

Figure 29 is a flow diagram summarising the functionality of the list object; Figure 30 is a diagram illustrating the manner in which cell data is accessed in the list object;

Figure 31 is a diagram of a visual display illustrating the operation of a note object according to the present invention;

Figure 32 is a diagram of a visual display illustrating the operation of a toolbar of the note object;

Figure 33 is a flow diagram summarising the functionality of the note object;

Figure 34 is a diagram of a visual display illustrating the operation of a work object according to the present invention; and Figure 35 is a flow diagram summarising the functionality of the work object.

General

Referring first to Figure 1, computer apparatus according to the present invention may be, for example, a mainframe, mini or personal computer. It may be networked. It comprises generally a Central Processing Unit 10, an alphanumeric computer keyboard 12, a VDU monitor 14 which is used to present a graphical user interface (GUI), a hard disc drive 16, and a mouse 18. The disc drive stores data in one or more directories, and these can be accessed by the CPU once switched on. The CPU processes data input from the keyboard or mouse via one or more input ports 20, and outputs the processed data in the form of electrical output signals in digital form via one or more output ports 22 to the VDU monitor 14, which generates its visual display from the output signals. Electrical command signals input from the keyboard 12 or mouse 18 control the form of the visual display via the CPU 10. In particular, the CPU 10 generates a cursor signal on the monitor; the position of this cursor signal is moveable either by the cursor keys on the keyboard 12 or by the mouse 18.

The CPU includes a Random Access Memory (RAM) 24, in which is stored, amongst other items, a file management system, designated at 26, and an operating system, designated at 28. Also stored on the RAM 24 are Microsoft Windows (trade mark) and Object Linking and Embedding (OLE) software, with which the present invention is designed to be compatible, and which are described in more detail later. The Central Processing Unit (CPU) 10 accesses the programs stored on the RAM 24 in response to the appropriate electrical command signals input from the keyboard 12 or the mouse 18.

The CPU 10 provides a graphical user interface (GUI) to allow a user to access the computer apparatus. It is used, where appropriate, to represent items, such as applications and data files, as graphical objects such as icons or windows. These may be selected by the user. The GUI can present the results of such selection on the monitor 14.

References herein to "clicking" on a particular symbol or within a particular region of the visual display connote preferably the process of moving the cursor to the relevant location and clicking the appropriate button (usually the left button) on the mouse 18 whilst at the relevant location. References to "right clicking" preferably connote the same process, but as applied to the right mouse button. Right clicking is typically reserved for accessing menus. References to "dragging and dropping" connote preferably the process of "left" clicking on a particular symbol, then moving the mouse with the appropriate button still depressed, and finally releasing the button at a fresh location where it is desired that the symbol be deposited.

Although terms in the description such as "click" and "mouse button" have been employed, the present invention is not limited to any specific interface tool, and includes variants such as tracker balls, pointers and the like. In the examples which follow, the invention makes use of and builds upon a suite of existing procedures, specifically the programming environment available under the Microsoft Windows 95 or Windows NT 3.51 or later (trade marks) operating systems which provide for improved integration between applications. The approach is object based and utilises the concept of compound documents into which objects can be embedded. The alternative is provided of creating a link between an object and a compound document rather than embedding the object in the document. This object based approach is founded on the OLE software, again from Microsoft Coφoration, mentioned previously. Description of various features of the OLE software is now provided. For more detail, reference is directed to published descriptions of the OLE (trade mark) system from Microsoft Coφoration and specifically to published information on the Microsoft Foundation Class (MFC). This information is summarised in the Microsoft Foundation Class Library Hierarchy Chart shown in Figures 2 and 3. OLE associates two major types of data with an object and these may be distinguished as presentation data and native data. The presentation data of an object is the information necessary to render the object in a display; the native data is the information necessary for editing the object and includes identification of the application owning the object and the appropriate data for that application to operate upon.

Linking may be regarded as a process in which an object's presentation data - but not its native data - is placed in a document. In this terminology, a document with which an object can be linked is referred to as a compound document; the term compound document also covers a document into which an object can be embedded. With a linked object, an appropriate pointer is created to the object's native data which is resident outside the compound document, in an appropriate file.

In the case of embedding, both the presentation data and the native data of an object are placed in the compound document. Thus the compound document itself becomes larger, with everything necessary to edit the object being contained within the document and being transferable with the object.

Linked objects cannot travel with the document outside the file system of the computer but they are more efficient in terms of file storage in that a single instance of the object's data can serve many compound documents. It is sometimes also a useful feature of linked objects that updating of an object can be effected without further editing in a number of compound documents with which the object is linked.

The present invention provides the capability of dragging and drag linking objects from toolbars controlling the use of those objects via the metaphors of drag and drag-link buttons displayed on the monitor 14. This can be achieved via the following Visual C++ code fragment:

void CMyToolBar::OnLButtonDown(UINT nFlags, CPoint point)

{ CToolBar::OnLButtonDown( nFlags, point);

int iButtonCapture; if ((iButtonCapture = HitTest(point)) < 0) return; // nothing hit

UINT nID, nStyle; int ilmage;

GetButtonInfo(iButtonCapture, nID, nStyle, ilmage); if (((nStyle & TBBS_DISABLED) = 0) && (nID = ID_DRAG_OBJECT j| nID = ID_DRAG_LINK_OBJECT)) {

CBwonotesDoc* pDoc = (CBwonotesDoc*)(((CFrameWnd*)AfxGetMainWnd())

->GetActiveDocument()) ; CBwonotesSrvrltem *pltem = pDoc->GetEmbeddedItem(); // get embedded item associated with this document

if (nID = ID_DRAG_LINK_OBJECT)

{

LPOLEOBJECT lpOleObject = phem->GetOleObject(); ASSERT(lpOleObject != NULL); // get moniker from ole object only if not embedded LPMONIKER lpMoniker; SCODE sc = lpOleObject->GetMoniker(OLEGETMONIKER_TEMPFORUSER, OLEWHICHMK_OBJFULL, &lpMoniker); if (sc = NOERROR)

{ lpMoniker->Release() ;

} else

{

CString strMsg; strMsg.LoadString(MSG_CANT_DRAG_LINK); MessageBox(strMsg); }

}

CRect TempRect(CPoint(0,0),pDoc->GetDocSize()); pDoc->m_bInDragButtonDown = TRUE; pItem->DoDragDrop(&TempRect, CPoint(0,0), TRUE, nID = ID_DRAG_LINK_OBJECT ? DROPEFFECT_LINK :

DROPEFFECT_COPY); pDoc->m_bInDragButtonDown = FALSE; pDoc->CommitItems(FALSE); // called to fix ASSERT in //foundation class when dragging from toolbar

CToolBar::OnLButtonUp(nFlags, point);

}

The class that implements the drag and drag-link buttons is contained in a CMyToolBar class: class CMyToolBar : public CToolBar; The main functions that handle the initiation of drag and drag-link operations are in the CMyToolBar::OnLButtonDown() function.

Toolbar

Description is now provided of the main object toolbar 30 which can display, once the CPU 10 has been switched on, options as to which of various objects or other applications it is desired to execute.

The toolbar aspect of the present invention provides an extremely simple method not only for launching frequently used applications but also for creating objects. Hitherto, as will be appreciated, the creation of an object has required a relatively complex series of key strokes or mouse clicks, typically with reference to pull-down menus. Further, as will be explained, the present invention also enables an object to be created with a selected template in place. This ease of creation and straightforward choice of templates will - it is expected - give to objects a practical and technical substance which has hitherto been lacking. A typical toolbar is shown in Figure 4. A number of application icons 100 are displayed on the toolbar, each having the appearance of a button. In particular, a control icon 101 (whose puφose will be described later), a note icon 102, a list icon 104, a calculator icon 106 and a work (file management) icon 107 are displayed, denoting some of the various objects which it may be possible to employ with the present invention. As will be described later, the toolbar software allows the addition (and deletion) of objects, as desired, so that the toolbar can be customised.

The toolbar software is arranged such that, if the left button of the mouse 18 is depressed whilst the cursor is over a given object icon, and then the cursor is moved "dragged" to a specified location (being the location of a compound document or other container) using the mouse whilst keeping the button depressed, and finally the button is released (the object is "dropped"), the object, as represented by its icon, can be moved to the specified location and embedded into the relevant application. The object can then be activated by double clicking on it. The relevant application can also be stand alone launched merely by clicking and releasing over the given icon on the left button of the mouse.

Other operations can also be performed on the toolbar. Context specific shortcut menus can be generated by right clicking the mouse 18 over a particular location on the toolbar. The appropriate shortcut menu then drops down from the position which has been clicked. Two such menus are in fact available. A toolbar shortcut menu, shown in Figure 5, designated at 108, is displayed by right clicking on the toolbar caption 1 10. An optional object icon shortcut menu may be displayed by right clicking on any application object icon 100. This may have details of preferences which could be set by the user, as well as a help option.

These menus are now described in more detail. As shown in Figure 5, the toolbar shortcut menu provides a number of menu options. The first option is "Preferences", clicking on which using the mouse 18 generates a dialog box with the following preferences shown in Figure 6. Alternatively, the preferences dialog box may be accessed by clicking on the control icon designated at 101 on the toolbar.

Firstly, the "Always on top" preference 1 14, if chosen, ensures that the toolbar always remains in front of the active window, or, if not chosen, ensures that the toolbar moves beneath the next displayed window that is selected that uses the same area of screen.

Secondly, the "Tool Tips" preference 116, if chosen, causes a brief description of each object icon to be displayed when the cursor is moved over it. The displayed description may be edited by right clicking on the control icon 101. The edit function is described in more detail later.

Thirdly, the "Auto Avoid" preference 1 18, if chosen, causes the toolbar 30 always to move away from the active window. If the available space is insufficient then the icon size is reduced to Caption (explained later) and the toolbar is positioned along the top left hand side of the screen. Fourthly, the "Drag as Icon" preference 120, if chosen, displays an object dragged from the toolbar 30 as an icon. The icon is embedded in the document into which it has been dropped as an icon with the name of the object. The object can then be launched by double clicking on it using the mouse 18. If the "Drag as Icon" preference 120 is not chosen, when dragged and dropped into a document the object is embedded in the document as an in-place object. At this point it has been loaded but not activated. Figure 7 illustrates the calculator object described previously dragged and dropped as an in-place object in the Microsoft Word (trade mark) application. Altematively, the same effect can be achieved by keyboard shortcuts. Pressing the CTRL key whilst dragging the object will create an in-place object, whilst pressing the SHIFT key will create an iconised object.

Fifthly, the "Toolbar Layout" preference 122 provides the option of having the toolbar horizontal or vertical (as shown in Figure 6). It also provides the option of specifying the "number of buttons" (icons) in the top row of the toolbar 30. If the actual number of icons is greater than the specified number of icons, then the toolbar is displayed in multi-row format, as shown in Figure 8. which shows toolbars of 2, 3 and 4 icons in width. Altematively, positioning the mouse 18 at the comer or on an edge of the toolbar allows resizing of the toolbar. The cursor changes to a resize pointer. Dragging the mouse allows the toolbar to be resized to any required size.

Sixthly, the "Icon Size" preference 124 provides the option of either a floating toolbar 30 (in three different sizes), a Caption size toolbar or a User defined size of toolbar. The three different sizes available for the floating toolbar are Large (32 by 32 pixels in the icon), Regular (24 by 24 pixels) or Small (16 by 16 pixels). With the Caption size option, the toolbar 30 has only the various icons (displayed at a Small size); the toolbar usually positions itself along the top of the screen immediately to the right of the control menu button of the maximized active window. With the user defined option, the size of the icons can be controlled by the user entering an appropriate numerical value in a text box 126. A further option available on the toolbar shortcut menu, as shown in Figure

5, is the "Edit..." option. Selecting this option causes an edit toolbar dialog box to appear, as shown in Figure 9. This itself provides three main options, the "Add" option in box 128, the "Edit" option in box 130 and the "Remove" option in box 132. The edit toolbar dialog box displays a description of the applications currently available.

Firstly, selecting the Add option opens a details dialog box, as shown in Figure 10. In response, the user can specify a number of items of information. In a description box 134, the user can input the text which will be displayed as a Tool Tip. The default is the object's executable file name. In a command line box 136, the object's executable file name is input. In a directory box 138 the working directory of the relevant application can be input. In an object box 142 a list of the names of the OLE servers which support more than one kind of object (such as Microsoft Word (trade mark), which supports both document and picture objects) can be input. If more than one type of object is required, then each such object is set up on the toolbar as a separate icon. In an icon box 144 is contained a list of the icons which can be displayed. The user can select the icon which best represents the relevant application. An OLE server box 146 is checked if the relevant application is an OLE server; otherwise it is not checked. Also available on the details dialog box shown in Figure 10 is a browse box

148, which enables a search to be conducted of all available drives and directories for applications or programs. Such a search might be beneficial if, for example, it were desired to add such applications or programs to the toolbar 30.

Secondly, selecting the Edit option opens a pre-existent details dialog box and allows the user to edit using this.

Thirdly, selecting the Remove option in the edit toolbar dialog box, if a particular application has been highlighted, allows the user to remove that application.

Up/down buttons 150 and 152 on the edit toolbar dialog box (see Figure 9) enable the user to reorder the position of the applications in the list, the order of which in turn determines the order in which the application icons 100 are displayed on the toolbar 30. If the application which it is desired to move is highlighted, clicking on the up or down button as appropriate moves the application up or down the list. A further option available on the toolbar shortcut menu, as shown in Figure

5, is the Run option. This can be used to start an application which has not been added to the toolbar 30 (as an icon), for instance because the application is only run occasionally. The Run option requires the user to input in a command line the path and name of the relevant program file, including its extension. The user is also presented with a browse option (similar to the one described above in relation to the Add option), and a run minimised option, by which the application can be reduced to an icon as soon as it starts.

Further options available on the toolbar shortcut menu, as shown in Figure 5, are a Help option, an About option, for details of the particular version of the software being run, and a Close option, for closing the toolbar 30. The toolbar may also be closed by clicking using the mouse 18 on a close button 154 at the top right hand comer of the toolbar 30 (see Figure 4).

As mentioned above, the toolbar shortcut menu can be accessed by right clicking on the toolbar caption 110. If the toolbar is set to Caption (see above), then this shortcut menu can be accessed by moving the cursor to the top of the toolbar 30 and right clicking. The same menu can be accessed (though not via a context specific shortcut route) by right clicking on the control icon 101.

The present invention can provide the user with a straightforward method of adding to the toolbar an icon corresponding to a selected application. An application can be added to the toolbar by locating the appropriate executable file using the file management system 26 onto the toolbar, and dragging the filename onto the toolbar. This generates a new icon for the application on the toolbar. Thereafter, the application can be launched by simply clicking on the icon. A particularly useful feature contemplated by the present invention is to provide the option for the objects to be created with one of a number of possible templates. These may be chosen from a predefined set or defined in advance by the user. In the present "toolbar" application, right clicking on a particular application icon on the toolbar brings up a list of available templates, one template being selected by double-clicking. Creating an object as described above then automatically creates an object pre-loaded with the selected template.

Altematively or additionally, the toolbar may be provided with a specific template icon. Clicking on this can bring up the list of available templates. A template icon is shown at 156 in Figure 4. Templates may be saved for future use.

A feature optionally provided by the toolbar is the ability to open one of the last, say, four objects which had been worked upon. This ability is accessed by right clicking on the relevant application icon and choosing the relevant specific object from the list which is displayed. A summary of the above described functionality is provided in the flow diagram of Figure 1 1.

The above described functionality is achieved according to the present invention by making ingenious use of the facilities available with the Microsoft Foundation Classes, and by adding a new technical effect. The principal classes utilised in this aspect of the invention are listed in

Table 1 below. This table shows for each defined class the super class within the Microsoft Foundation Class whose properties are inherited together with, where appropriate, details of a defined relationship with another class. TABLE 1

Class Super Class Has a: Reference to: Named

CAboutDialog CDialog

CToolApp CWinApp

CDetails CDialog

CEditToolbar CDialog CMainFrame m_pMainWnd

CFormat CDialog

C.VlainFrame CFrameWnd CBubble m_Bubble

CToolDoc m_pDoc

CRunDialog CDialog

CTemplateDialog CDialog

CTooibarButton CObject

CToolConta eritem COleClientltem

CToolDoc COIeDocument

The class CToolApp is a derived class of the MFC class CWinApp (which is overridden in all MFC applications) and handles the initialisation and termination cleanup of the software. The class CMainFrame (derived from the MFC CFrameWnd) is responsible for the rendering of the frame around the toolbar

5 window. Were they not overridden, the CFrameWnd member functions would always display a title bar, menu bar, the maximise and minimise buttons and a system menu. The software, however, requires that these window elements are displayed selectively (or not at all in the case of the menu bar). Consequently, the CMainFrame class assumes control of the rendering of the frame, the title bar and

10 the tool buttons themselves. Under normal circumstances a MFC application will derive a class from CView which manages the client area (i.e. the area within the confines of the main program window and the title bar/menu bar). However, in this software no derivation is made from CView since there is no client area to manage (the Tool application consists entirely of elements which are managed by

15 CMainFrame).

Although the display of the buttons is the responsibility of the CMainFrame class, the infoπnation required therefor is contained within the CToolBarButton class, of which a single instance exists for each button on the toolbar. The CToolBarButton class contains all of the details for a given button (e.g. the command line/title). The contents of the class is set up automatically during a drag and drop onto the toolbar, or manually using the Details dialog box (rendered by the CDetails class).

The preferences for the toolbar software (e.g. button size/template directory) are editable via several dialog boxes. These are implemented by the CEditToolbar class which renders the 'Edit Toolbar' dialog box (Figure 10) and the CFormat class, which renders the 'Preferences' dialog box (Figure 7). Two such preferences are the ability to ensure that ( 1 ) the tool bar remains on top of, and (2) does not cover, all other active windows. For the latter, the Tool application, at an interval of one second, examines its position relative to all of the active windows.

Although there is only one active application, the active application may have child windows which also have to be avoided. Therefore the Tool software examines each application in turn and locates available space. If no such space is available the toolbar reverts to caption size. The CToolDoc class is a derived class of the MFC COleDocument, and is responsible for storing the general program data and for the reading/writing of this data to disc files. Since CToolDoc was derived from COleDocument and not CDocument, the toolbar becomes able to act as an OLE container.

The toolbar application's behaviour as an OLE container is utilised when an OLE object is dropped onto it. In the event that the user drags a filename (e.g. from Windows Explorer) onto the Tool software, a suitable icon is added to the toolbar automatically, with no extra input required from the user. The relevant file is located, and a new instance of CToolBarButton is created and filled with the details about the dropped file. The CMainFrame class then redraws the toolbar automatically to include the new icon. If the user does not wish to add an icon for an application, it is possible to run the application from the 'Run' dialog box, which is implemented by the CRunDialog class.

The toolbar software launches the application on the toolbar via the conventional Windows command line. This concept is similar to that used in DOS, wherein the user types the name of a program to be run followed by its parameters. If the user clicks an application icon without dragging it, the relevant application is launched with no parameters, thus causing a fresh instance of the program. Ingeniously, the present invention arranges that if the user drags an application icon from the toolbar and places said icon into an OLE container, a new object is created which is embedded in the container. This is achieved by looking up the object for the relevant application in the registration database to obtain its class identification, an then creating an object of the CToolContainerltem type using the do drag drop MFC call. Thus, the toolbar software under no circumstances behaves as an OLE server, and this is confirmed by the absence of a derivative of the COleServerltem class.

In the event that the user holds CTRL while dragging the application icon from the toolbar, the new object is embedded as an icon. In this case, the application is not launched until the icon is double clicked. Therefore, the Tool software creates an object, for which the server details are recorded as those of the application to which it belongs (i.e. the application whose icon was dragged).

Thus, when the embedded icon is double clicked, its parent application is launched and not the toolbar software.

The provision for templates is partly the responsibility of the CTemplateDialog class, which renders the dialog box containing the various template icons. Each of the icons has associated with it the name of a template file on disc. Should the icon be selected, the software cross-references the extension of the filename with those present in the registry (a list of all installed programs with their associated file types). The software can then obtain the executable file which is responsible for the template, and consequently launches the application with the parameter being the name of the template file (e.g. 'winword c:\work\letter.dot'). Since these steps are valid for all installed applications, a template for any application (e.g. Microsoft Word) can be added to the collection of template icons.

Calculator

By using the main toolbar 30 displayed on the monitor, as described above (or altematively by other means such as from a program menu), once the CPU 10 has been switched on, the user can be presented on the monitor 14 with options as to which of the various objects it is desired to run. These can be selected from the toolbar. A first example of such an object which can be selected is a calculator object. The principle features of this object are first described with reference to Figures 12 and 13.

As shown in Figure 12, the user is presented with a visual display 1000 on the monitor 14 which is generated by electrical signals output by the CPU 10. The display shows a calculator keypad 1001, a display bar 1002 for the calculator, a tallyroll (list) 1004 and an object specific toolbar 1006. Operands (numbers) or operators may be selected either by typing the appropriate keys on the computer keyboard 12 or by selecting the appropriate keys from the calculator keypad 1001 using the mouse 18. If it is desired to enter data into a particular cell of the tallyroll 1004, this cell can be selected using the mouse 18. Suppose that the user wished to perform a calculation of the quantity momentum as a function of mass and velocity. The user would initially select a label column 1010 and enter in that the word "mass" followed by, in a number column 1012, say, the quantity "100". These quantities appear on the tallyroll as shown in the first row (data entry element) of the tallyroll in Figure 12. Next, the user would enter as a new row (data entry element) in the label column the word "velocity", followed by the operator "X" (times) in an operator column 1014, and the quantity "5" in the number column. These items would appear in the second row of the tallyroll. Finally, the user would enter the word "momentum" in the label column, followed by the operator "=" in the operator column. The calculator object then displays the result of "500" in the number column, as shown in the third row of the tallyroll. The same result is also displayed in the calculator display bar 1002.

An important feature of the labels is that these can form part of the calculation. In other words, a label used earlier in a calculation can be referred to later in the calculation. This feature is illustrated with reference to Figure 13. The calculator object allows formulae to be entered into cells. Suppose, in the example given in Figure 13, given a unit price ("Price") and number of units ("Units"), it were desired to calculate the total cost of the number of units to be purchased. This could be achieved in the "Cost" row by clicking on the labels of the relevant rows, by clicking on the "Price" label, entering the multiplication operator from the keypad 1001, and then clicking on the "Units" label. The total cost can then be computed by the CPU 10 and output in the number column 1012. If, say, the "Price" were changed from one value to another, then the "Cost" would reflect this automatically. Altematively, the calculator object is such that the calculator can be operated without any labels being used. Hence the user can input merely operands and operators, as with a conventional pocket calculator; these are input completely automatically onto the tallyroll, with the label column 1010 being left blank. For example, if the user wished to compute 100 times 5, he would merely click on the keypad 1001 using the mouse 18 on the digits "100", then click on the operator "X", then click on the digit "5" and then finally click on the "=" key to obtain the result. Altematively, the appropriate characters could be typed on the computer keyboard 12.

Double clicking on the operator column 1014 generates a drop down list of operators from which to choose.

Explanation is now provided, with reference to Figure 14, as to the manner in which the computer, when programmed, achieves the above technical result, at the level of the storage and manipulation of variables. For each row on the tallyroll, as shown in Figure 14, storage locations are provided within the RAM 24 of the CPU 10 for five basic items, namely the label referred to above, a first operand (operand 1 ), an operator, a second operand (operand 2), and a result. Operand 2 is displayed on the tallyroll in the number column 1012. The result storage location stores the interim or final result for the operation carried out in each row (the running total). Hence in the given example, the result column in the second row stores the result of 100 times 5 as 500, whilst the result column in the first row merely stores as an interim result operand 2 (100). The data stored in the operand 1 storage location is, by default, the result stored for the previous row (termed "prev"), although it could be set by the user to some other value.

Data stored in the operand 1 and result columns are not usually displayed, although they could be if desired. This is achieved by clicking on appropriate operand 1 arrow symbol 1020 or result arrow symbol 1022 at the head of the relevant column. This reveals the relevant column.

The storage locations within the CPU 10 are arranged such that each row in the tallyroll is defined with reference to a specific address so that that row can be correctly accessed even if the position of the row within the tallyroll is changed.

The storage locations are also arranged, by appropriate addressing, such that each row in the tallyroll, and each individual cell within each row, can be individually edited. In this respect the tallyroll may be thought of as behaving like a one-dimensional spreadsheet. One particular respect in which the tallyroll differs from a conventional spreadsheet, however, is in the fact that, above a default minimum, the tallyroll takes up only as many storage locations as are required for the particular calculation being performed. The tallyroll initially has a default number of rows set by the user (typically five); the CPU 10 is programmed to create further rows automatically if the calculation so requires; input of sufficient data or commands automatically forces the generation of further rows.

Further details of the calculator object are now described. with reference in the first instance to Figure 12.

The display 1000 includes, at the top, a title bar 1030, which displays the file and application name.

The display 1000 also includes, beneath the title bar 1030, a menu bar 1040, which displays the following pull down command menu options: "File". "Edit", Format (entitled "Blox" (trade mark)) and "Help", which generate pulldown menus when clicked upon using the mouse 18. These are explained in more detail later. Also as described in more detail later, some commands on the pulldown menus perform an action immediately, whilst others produce a dialog box, with further options. If an option is shown dimmed on the display, it is not currently available until a selection has been made. An ellipsis on the relevant menu command (...) is used to indicate that a dialog box will be displayed. A check mark is used to indicate that the relevant option is already "on".

The display 1000 further includes, beneath the menu bar 1040, the calculator toolbar 1006 which displays a series of tool symbols 1052 to 1066 having the appearance of depressible buttons. These provide speedy access to the most commonly used commands from the set of command menu options. They will be described in detail later. They can be accessed by clicking on the appropriate tool symbol using the mouse 18, or else by use of appropriate keys on the keyboard 12.

Again, the display 1000 includes, beneath the calculator keypad 1001, a status bar 1070. This bar provides information about the current task being performed, including the current memory contents. Information about a command can be obtained by pointing to on the command using the mouse 18, and reading the text in the status bar.

The commonly used commands accessible via the toolbar 1006 are next described. A New tool symbol 1052, also available under the "File" pulldown menu, generates on the monitor 14 a new blank calculator and tallyroll for filling in by the user.

An Open tool symbol 1054. also available under the "File" pulldown menu, enables the opening of an existing calculation by clicking on the appropriate symbol in the toolbar 1006. A register of calculation titles is then displayed on the monitor 14 for the user to select the required calculation. Because the calculator object stores a complete record of all the steps in a given calculation, the calculation can be edited as desired. For example, one or more of the steps could be edited, labels could be entered, eπors could be coπected, or the calculation could be continued.

The Save tool symbol 1056, also available under the "File" pulldown menu, can be used to save a given calculation. Altematively, if the calculator object has been used within a container document, it can be saved automatically as part of that document. Clicking on the Template tool symbol 1058 enables the creation of a new list from a selection of pre-stored templates or master calculations. The templates are empty calculations, with certain pre-set column and row details. They are particularly useful for calculations that are performed frequently. The structure and format of the calculation can be retained (such as the formulae, row labels and fonts); only the data need be changed with each new calculation.

Clicking on the Always On Top tool symbol 1060 provides the user with the choice between the calculator toolbar 1006 always remaining in front of the active window, or the toolbar moving beneath the next displayed window that is selected that uses the same area of screen. Using OLE technology, the calculator object can either be embedded in or linked to a document. The simplest method of embedding - by dragging and dropping the object from the main toolbar 30 - has already been described. This would be appropriate if it were desired to embed a new object. For instance, the calculator object could be embedded into a Microsoft Word (trade mark) document. If, altematively, it were desired to embed a previously created calculator object, then this can be achieved by first opening the previously created object, then using the Drag Calculator tool symbol 1062 to drag the object into position in the relevant document. Once the object is in position, it can be activated by being double clicked upon. In order to drag link the calculator object, it is first opened, and then dragged into position in the target document using the Drag Link tool symbol 1064. Source data must be saved to a file before being linked.

Once the calculator object has been embedded or linked, it can appear in the target document in a number of forms, namely as an icon, as a calculation result, or as a tallyroll. The choice can be made via the options dialog box under the "Format" pulldown menu, more details of which are provided later.

Because of the fashion in which the calculator object has been implemented, the calculator object can be both a source of and a container for linked data. For example, a link can be made in either direction between a cell in the calculator object and a cell in a suitable spreadsheet. Also, data can be linked between one calculator object and another. Data can be linked by highlighting the text or cell which it is desired to link, depressing the CTRL and SHIFT keys, and dragging it into position in the container. Any change in data in one object can then be reflected in the other object. A final command accessible from the calculator toolbar 1006 is a Set

Keypad tool symbol 1066, which is also via the "File" pulldown menu. Clicking on this symbol generates a Set Keypad dialog box providing options of various different calculator keypad styles which may be employed for the calculator keypad 1001. For example, there is a standard keypad, as illustrated in Figure 12. Also available may be a scientific keypad (with additional scientific function keys), a computer keypad (with various logic keys and the ability to work in different number bases), and then also more specialist keypads such as a break even analysis, a compound interest, a depreciation, a time value of money and a motion keypad (which can evaluate speed as a function of time and distance, and so on). A Break Even keypad is illustrated in Figure 15. This is capable of backsolving. It possesses "Units sold", "Unit price", "Variable", "Fixed" and "Profit" keys, respectively designated at 1080 to 1088. A value for the units sold can be entered on the keypad 1001, followed by clicking on the Units sold symbol 1080, and then similarly values can be entered for unit price, variable costs and fixed costs. Clicking on the Profit key 1088 then yields a value for Profit.

Furthermore, as an example, if a value of Profit of, say, zero is then input, and, say, the units sold key 1080 is clicked on, the value of the units sold will change to show how many units would have to be sold to break even. This functionality is provided by backsolving. Given the basic break even equation:

Profit = ((price-variable costs) *number sold) - fixed costs

the related break even equations are derived, and programmed into the CPU 10 so that the user can vary different variables in the break even analysis.

Other features which mav be available on the menu bar 1040. are as follows. Available under the "File" pulldown menu may also be a "save as" option providing the opportunity to save a new or existing calculation with a new title name. Various options concerned with templates are also available aside from the template option also available under the Template tool symbol 1058. "Save template" enables the saving of calculator templates (so that the labels attached to rows can be saved and used again with new calculator values), whilst an optional "Amend template" feature could enable the amendment of a selected template (although possibly redundant). "Print" is also available (as provided on Microsoft Windows), as are "print preview", for displaying a screen preview of a list as it would appear in print (including zoom in and zoom out features), "print setup" for changing the Windows printer settings, and "exit" for closing the database object. Finally, a "previous calculations" option is available, which provides a list of the last four calculations performed, and enables the required one to be selected quickly. Available under the "Edit" pulldown menu may also be editing options generally available with Microsoft Windows (trade mark). Such options may be an "undo" option to reverse the previous editing or formatting operation, "cut" to remove the currently selected data from the calculation and copy it to a graphical clipboard, from where it can be pasted into a new location, "copy" for copying the currently selected data to the clipboard, from where it can be pasted into a new location, "paste" for pasting data from the clipboard to the current cursor position of the active document, "paste link" for pasting data from the clipboard to the current cursor position of the active document, with the data in the new location being changed to match the original if the original is updated, "links..." to edit a linked object, the options including opening the source file within the source application, changing the source and breaking the link, and "document object", available when linked data exists between the calculator object and another application, options being provided to open, edit or convert the linked object. Also available under the Edit pulldown menu is "insert new object", which enables a new embedded object to be embedded. Finally, available under the "Edit" pulldown menu is an "insert rows" option, selection of which generates a dialog box which allow a specified number of rows to be selected for entry into the tallyroll 1004, as well as the number of the starting row where the insertion is to begin, a "delete rows" option by which the highlighted selection of rows can be deleted, and a "clear" option by which all cells cuπently selected (highlighted) in the tallyroll can be cleared.

The Format pulldown menu can provide various features which can allow the personalisation of the application. Firstly, formatting can be selected for columns, keypads, numbers and OLE displayed objects. Secondly, the use of fonts can be controlled. Thirdly, choice can be made as to whether to display the title bar 1030, the menu bar 1040, the tool bar 1006, the status bar 1070 and any caption bar. Fourthly, cells can be locked, unlocked, hidden, shown and password protected.

Hence, available under the "Format" pulldown menu may be "options..." to open a tabbed options dialog box to provide the following options. In a "general" tab may be set firstly the number of decimal places used in the application; this can be a fixed or a variable number. Secondly an embedded object can be displayed either as a full tallyroll, or as a result only or as a result plus the calculator object icon. Thirdly, the tallyroll printout may be chosen to fill a given paper size. Fourthly, the calculator object may be chosen to be always on top of other applications which may have been opened, or not as the case may be. Fifthly, the calculator object window may be autosized to the width of the selected keypad 1001. Sixthly, the option is provided to input the desired basic rate of taxation. This is stored for use when the "Tax" button is depressed on the standard keypad 1001, as shown in Figure 12. Like options may also be provided.

In a "Columns" tab, default column settings and widths can be set. The default number of columns is three, but a maximum of five can be enabled. These are initially given the headings of Label, The Formula (noting that the "Operand 1 " column could contain a formula rather than a number or a reference to a previous interim result), Op (Operator), Number and Interim (result).

In a "tallyroll" tab, the number of rows that appear at startup can be specified, the default being five. Formulae can be entered into cells, and the choice can be made in the tallyroll tab as to whether these are shown as values or formulae. Also, column and row headings can be tumed on and off, and background colour and heading fonts can be selected.

In a "keypad" tab, the font and colour to be used in the keypad can be set. together with the directory where the keypads are to be located.

Also available under the Format pulldown menu may be "fonts" for accessing the fonts dialog box to enable the font to be changed, and "view" for enabling the title bar 1030, the menu bar 1040, the tool bar 1006, the status bar 1070 and any caption bar to be displayed or hidden. The view options may also be available under a shortcut menu by right clicking on the mouse 18 while the cursor is over the tallyroll. Further available under the Format pulldown menu may be the facility to lock, unlock, hide, show (the reverse of hide) cells in the tallyroll 1001. The locking and hiding may be password protected. These security features can prevent unauthorised access. In the case of locked cells, data cannot be entered into or altered in such cells. A key icon 1090 (see Figure 12) is provided in the top left hand comer of a cell to indicate that it has been locked. The locked cells feature may be useful if users are required to update certain cells but not others. Templates can also be set up to include the lock cells feature. In the case of hidden cells, data entered within such cells will not be visible. This feature may be used to keep data confidential. Finally, password protection of the calculator document requires the inputting of a confidential password, so that locked cells cannot be unlocked and hidden cells cannot be shown. Available under the "Help" pulldown menu may be a number of "help" features such as a help index, an introduction to the help facility, and detailed help information.

The calculator object has full OLE functionality. This means that it can be used as a source object or a destination object for linking and embedding information. As regards the embedding of information, the calculator object can contain other objects within its own cells. Also, the calculator object can be dragged into the cell of another such object. Sections of other objects can also be dragged and dropped into the calculator object. Further, entries created in the calculator object (such as individual cells, including the result only) can be placed into tables created in other applications. For example, cells of a calculation can be selected and dragged into a table in Microsoft Word 6 (trade mark). Also, more than one instance of the calculator object may be open on the display at the same time. Information from one can then be transfeπed or copied to the other using copy and paste or drag and drop. As regards the linking of information, the user can choose to link the entire tallyroll data, a range of cells, or just one cell (including the result only) to a container document. Cells can be linked between various different calculations using the calculator object, so as, in effect, to create a free-form type of spreadsheet. An object linked thus maintains a link between the source and destination (container) application. If, for example, it is a calculation linked to a Microsoft Excel (trade mark) spreadsheet, then the data will update to reflect any changes made to the source file.

Further, the present calculator object can be activated in-place, so that it can be used whilst using other OLE compliant applications. A summary of the above described functionality is provided in the flow diagram of Figure 16.

The calculator object described above may be implemented computationally in many different ways. As just one example, it may be implemented using the Microsoft (trade mark) Foundation Classes. Such an implementation is now described with reference to Table 2.

TABLE 2

Class Super Class Has a. Reference to Named

CAboutDialog CDialog

CArchivePropExchange CPropExchange

CCalcApp CWinApp CObjectType m_ObjectType

CCalcChildFrame CMDIChildWnd CStandardDialog m_wndStandard

CCalcContainerltcm COIeChentltem

CCalcDoc COIeServerDoc CCalcList m_CalcLιst

CObList m_ColorFontLιst lOLEExpression m_Expressιon

CColorFont m_HeadιngFont

CMultiType m_mtMemory

CMultiType m mtRunningTotal

CMultiType m_mtTax

CMultiType m_mtTotal

CObList m_UndoFileLιst

CCalcList m VaπableList CColorFont m_pDefaultFont

CCalcServerltem COIeServerltem CObList m_ServerEntπes

CCalcView CView CCalcEdit m_EditOperand CCalcCombo m_EditOperator CCalcEdit m_EditSource CCalcEdit m_EditText

CCalcEntry m_pEditEntry CCalcContainerltem m_pSelectιon

CCalcButton CWnd function m_Functιon

CCalcCombo CComboBox

CCalcEdit CEdit

CCalcEntry CObject CMultiType m_data CMultiType m_mtSubTotal

CColorFont m_pColorFont CCalcContainerltcm m_pltem

CCalcList CObList

CColorFont CObject

CColu nHeadings CPropertyPage

CControlFrameWnd CWnd

CDIB CObject

CDIBPal CPalette

ClnPlaceFrame COIelPFrameWnd CStandardDialog m_ ndStandard CMvToolBar m wndToolBar

ClnsertDialog CDialog CCalcDoc m_pDoc CKeypadOptions CPropertyPage CTotalEdit m_TotalEdιt

CMainFrame CFrameWnd CStandardDialog m_ ndStandard CMyToolBar m wndToolBar

CMyToolBar CToolBar

CNumberOptions CPropertyPage CEdit m_DecιmalComrol

COIeDispatchExceptionEx COleDispatchException

CProtection CDialog

CRemoveProtection CDialog

CServerEntryltem CObject CCalcEntry m_pEntry

CSetKeyboard CDialog CCalcDoc m_pDoc

CStandardWnd CStandardDialog

CSumlnfo CDialog

CTallyRollOptions CPropertyPage

CTemplateDialog CDialog CObList m IconList

CToolDialog CDialog

CTotalEdit CEdit

ICalcFunc COIeDispatchDπver lOLEExpression COIeDispatchDriver

The CCalcApp class (derived from the MFC class CWinApp) is responsible for the general program administration, such as the initialisation and exit cleanup (closing all files etc). The CWinApp class provides Windows with information about the executing program.

The tallyroll 1001 is implemented using classes derived from the Microsoft Foundation Classes. For each row on the tallyroll there is one instance of the CCalcEntry class (derived from CObject). This class is responsible for the storage of each field in the row (specifically the label, first and second operands, the operator and the result) in addition to the display and manipulation of said fields.

10 The CCalcList class is a modified CObList class wherein pointers to each instance of CCalcEntry are stored. Thus the tallyroll data is accessed by reading the relevant pointer from the CCalcList class to locate the instance of CCalcEntry for the desired row. The CCalcList class is identical to the CObList class except that it returns a pointer to a CCalcEntry rather than a CObject (as with the unmodified CObList class). Access to the data by the rest of the program takes place via the CCalcDoc class, which contains the instance of CCalcList, and is also responsible for the read and write of information from and to the storage medium. The CCalcEntry class contains both instances of and references to other classes. There are two instances of the CMultiType class within CCalcEntry (named m_Data and m_mtSubTotal) which are responsible for the storage of the field values. The CMultiType class contains a union of the majority of the data types present in the C++ programming language. A union in C++ is where multiple variables are defined, all of which share the same memory location. It is then possible for the same area of memory to represent (and be addressed as) different data types. This removes the need for the CCalcEntry class to have different data members for each of the different types of data that can be stored, and results in more efficient usage of the system's resources. The CMultiType class is not of a fixed size, and consequently the size of the CCalcEntry class is also variable. Also contained within the CCalcEntry class are pointers to instances of the CColorFont and CCalcContainerltcm classes. The CColorFont class holds both the colour of and the font for the text in the cell. This derived class is used in preference to the MFC classes which can hold either font information or colour information but not a combination thereof. The CCalcContainerltem allows a cell in the tallyroll to act as an OLE container by supporting the dropping of OLE objects.

The tallyroll is displayed by the CCalcView class which is derived from CView. During the display process, a member function of CCalcView calculates the column width for the tallyroll such that the entire width of the client area is utilised. The CCalcView class contains three instances of the CCalcEdit class (the edit control for a cell in the tallyroll) and one instance of the CCalcCombo class (which is responsible for drawing the pull down combo box from which the user can select the operator when the cell is double clicked). The different instances of the CCalcEdit class are required for the different cell types in the tallyroll (e.g. label/operand). The CCalcView class also contains pointers to the instance of CCalcEntry for the current tallyroll cell, and to the instance of CCalcContainerltem of any current selected embedded OLE object.

The tallyroll is editable through several dialog boxes. The CColumnHeadings class allows the user to change the headings of the columns. CInsertDialog, which is a derived class of the MFC class CDialog has a reference to the class CCalcDoc enabling it to coordinate the dialog box input from the user with the insertion of extra rows. The various number options are set in the dialog box produced in the class CNumberOptions. which is a derived class of the MFC class CPropertyPage. The CNumberOptions class contains an instance of a CEdit class (named m_DecimalControl) which allows the user to enter the format of decimal numbers.

Entry of data via the calculator keypad is partly the responsibility of the CCalcButton class of which an instance is present for each button on the keypad. This class is derived from the CWnd class of which several member functions are oveπidden - specifically the ability of a button to be double clicked is removed, and the keypad button press is registered immediately rather than on release of the mouse button. Entry of data into the total line of the calculator is directed by the CTotalEdit class (a class derived from CEdit), which validates the input as well as displaying it in the format determined by the various user options. This class also passes the edited information to the active cell's instance of CCalcEntry via the CCalcList pointer list.

Entry of data directly (via the keyboard rather than presses on the calculator keypad) into the tallyroll is the responsibility of the CCalcEdit class (derived from the MFC class CEdit). Various member functions of the CEdit class are oveπidden, such that the data input from the keyboard is validated on entry. If the information entered into a cell (be it by use of the keyboard or graphical keypad) constitutes a formula (e.g. contains references to cell labels), the calculator software causes the formula to be evaluated whereupon the numeric result of said formula is stored in the active cell's instance of CCalcEntry in addition to the formula itself. The storage of both the formula and the numeric result removes the need for the re-calculation of the tallyroll when it is displayed which increases the performance of the software. Said performance increase is at the expense of a small increase in required memory due to the element of redundancy.

The evaluation of the formulae and values is not undertaken by the calculator software itself. Instead a calculator engine (described later), including an expression parser, is contained externally of the software in a dynamic link library (DLL) and is launched in automation mode. This mode allows each application to use the facilities offered by another. This functionality is provided by the lOLEExpression class, which is derived from the COleDispatchDriver MFC class. The lOLEExpression class is a member of the CCalcDoc class. The lOLEExpression class allows the calculator software to control the calculator engine. The lOLEExpression class is used during the evaluation of formulae. The ICalcFunc class allows the calculator software to be controlled by another application (i.e. receives instructions). A third class is involved, namely COleDispatchException, which is responsible for the handling of communication eπors between the two applications should they occur.

Evaluation is achieved by translating (parsing) the string to be parsed, storing it as an expression tree (a hierarchical data structure), and then traversing the tree by a process commonly refeπed to as depth first traversal.

As described in more detail later, in the event that the variable for which to solve is either (a) not on the left of the equals sign or (b) not the sole variable on the left of the equals sign, then the expression tree is reaπanged accordingly. This allows the expression parser to solve for any variable in an equation and is termed 'backsolving'.

The role of the calculator software itself in expression evaluation is limited to fulfilling the requests for information made by the expression parser. The calculator software passes the formula to be evaluated as a conventional string, and this initiates the evaluation process. As necessary, the parsing software will prompt the calculator software for a value of a label. This value is determined by searching all instances of the CCalcEntry class (pointers to which are held in CCalcList) for the label, and then returning the associated value via the automation interface. Once all of the required labels have been supplied to the expression parser, the result of the calculation is retumed to the calculator software for storage and display.

The calculator keypad is drawn by the CStandardDialog class. For each of the calculator displays, a script file is present on disc which contains an entry for each button. This file is read into memory, and is used to create the instances of the CCalcButton class. The graphical background of the keypad is drawn by the CDIB and CDIBPal classes. The CDIB class holds the data for the Device Independent Bitmap, and the CDIBPal class holds the palette. Each key on the keypad can represent either a single digit, or a formula, or an operator. The user can select the active calculator keypad from those stored on disc via the CSetKeyboard class which displays a dialog box containing all of the available keypads. The CKeypadOptions class inherits the properties of the MFC class CPropertyPage. It is responsible for drawing the dialog box which contains the user options relating to the keypad such as the colour of the total bar. This information is contained within the CTotalEdit class, and thus the CKeypadOptions class contains an instance thereof to enable it to alter the options.

The remainder of the screen display is rendered by the CMainFrame class. This draws the window frame, the title bar, the menu bar, the tool bar and the maximise/minimise buttons. It is a derived class of the CFrameWnd class (a class of MFC) and contains instances of CStandardDialog and CMyToolBar. The CStandardDialog class is responsible for the drawing of the calculator keypad, and the CMyToolBar class (which is derived from CToolBar) draws the tool bar. The tool bar can be configured by the user, and this is achieved through the CToolDialog class which draws the options dialog box.

The calculator software is configured to act as both an OLE container and server. This functionality is provided by the CCalcDoc, CCalcServerltem,

CCalcContainerltem and CInPlaceFrame classes. The CCalcDoc class is derived from COleServerDoc rather than CDoc, resulting in the application's document being a compound document, thus supporting the software acting as a server. For each item that has been embedded in the calculator software an instance of CCalcContainerltem is created which holds the presentation and native data for the object. When the calculator application acts an OLE container, it acts as a normal container, with no special functionality.

Whenever the user causes a calculator object to be embedded elsewhere, an instance of the CCalcServerltem class is created which is used to hold information on the object when it is being embedded in the client application. Such information will contain the object's presentation data (data and functions which draw the object on the display) and the native data (which contains a reference to the server application so that it can be launched if necessary).

Double clicking on a calculator object in an extemal OLE container will activate in-place editing, wherein the user can edit the object without switching the active application. When double clicked, the object's native code launches the application in IP mode. In this mode the CInPlaceFrame class assumes the duties of the CMainFrame class, and constructs the in-place frame and toolbar. The toolbar remains the same whether the application is running in-place or otherwise. This is evident since both the CMainFrame and CInPlaceFrame classes have an instance of the same CMyToolBar class. The CStandardDialog member in the CInPlaceFrame class is responsible for rendering the calculator keypad when the application is running in place.

In addition to the ability of dragging and dropping cells, the user can also drag and drop the information contained within the cells. The exact functionality depends on the OLE capabilities of the container. If the data contained within a cell is of a standard type (that is, only text is supported) then it can be dragged and dropped without being treated as an object in its own right. Thus if text is dragged from within a cell and dropped elsewhere, the text is inserted into the destination application but no link is present back to the source application. The text is not an object and will not respond to double clicking. It is, however, possible for it to be edited by the destination application, which cannot distinguish between it and text input directly by the user.

The user can opt only to include the metafile or picture data in an object. This creates a link to a file on disc in which the presentation data for the object is stored. This results in more efficient storage of the object data in the event that the same object is present in several independent containers. The saving of the link information is the responsibility of the CServerEntryltem class.

Present within the calculator software are security features to prevent unauthorised viewing or changing of cell contents. Locking a cell prevents its contents from being amended (although it can still be viewed) whereas hiding a cell prevents the cell from being seen at all. Once all necessary cells have been locked/hidden the user can 'protect' the tallyroll by entering a password. This prevents the user from unlocking/re-showing the cells until the 'protection' is tumed off. The security features are implemented by flags within CCalcEntry which denote if the row is hidden, or a cell is locked. The dialog boxes into which the user enters the password are rendered by the CProtection and CRemoveProtection classes.

For calculations repeated frequently the user can either load an existing or create a new template. Loading an existing template results in an instance of the CTemplateDialog class being created. The user selects the desired template, which is retrieved from disc via the CCalcDoc class. The template files are not compound files, and thus do not support OLE actions.

The software aids the user in keeping track of the calculator tallyroll files by providing summary information. This contains infoπnation on the nature of the file (e.g. title, subject) and a dialog box is presented when the user opts to save. This box is rendered by the CSumlnfo class. The calculator software automatically fills the author field with the name of the person who purchased the software, and this information is extracted from the registration database.

Calculator Engine

A calculator engine for the calculator is now described. This is employed to evaluate the results of all calculations. It uses expression parsing, and, where appropriate, the results of the expression parsing to solve equations.

The expression/equation parser allows the manipulation of mathematical formulae in order to express an equation in a manner which allows the solution for any one of the variables in the equation. The parser is present in the form of a DLL, the functions of which are callable from the calculator software.

In order to solve an equation, the parser creates an expression tree from an expression string. The string is broken down into its constituent parts which are recognised and placed into a syntax tree (i.e. parsed). The syntax tree may be reaπanged (i.e. solved) for any variable contained within it. The tree is searched for said variable and is then mathematically solved (not evaluated) so that the variable being the sole variable on the left side of the equation. No reaπangement is performed if the unknown is already the sole variable on the left. The calculator application passes a string expression to the parsing software whereupon the parser performs syntax checking, but only to a sufficient degree to determine whether the expression is valid. Should this not be the case, an eπor code is retumed and the calculator software will inform the user that the cell formula is invalid. The calculator software is responsible for ensuring that the syntax of the expression is valid, ensuring that functions used in the expression are registered with the parser, and converting to and from user units (required for evaluation not rearranging).

The input string must be in one of two formats:

Y=<expression> or

<expression> where expression is a string of the following format:

expression = term | term + expression term = factor | factor * term factor = (expression) j label | function "(" expression ")" label = [A-Z, a-z] ] label[A-Z, a-z, 0-9] | &*& (where * is any sequence of characters excluding "*")

and function is one of the following:

+,-,/,*, sqrt,(,),% sin, sinh, cos, cosh, tan. tanh. asin. asinh, atanh, acos ln,e\y^x,log, 10\ x²

The parser scans the expression for an equals sign (=). If one is not found, it assigns a variable named "LEFTSIDE" to the value of the equation. This is necessary since the rearrangement of the expression depends upon there being a variable or value on the left side of the equation. In the event that an equals sign is found, the variable to the left is extracted and stored, and all characters up to and including the equals sign are discarded.

For example, given an input string:

HOUSEVAL=MORTGAGE*INFLAT+RESIDUAL

the parser locates the equals sign, before reading and storing HOUSEVAL as the value of the equation. It then shortens it to:

MORTGAGE*INFLAT+RESIDUAL.

If, however, the input string was

MORTGAGE*INFLAT+RESIDUAL

the parser would use the variable LEFTSIDE to represent the value of the input equation.

Nodes in the tree are units of data, i.e. operators, primitive functions, entire "unknown" functions and their arguments, data variables or values. Each node may have a value and pointers to two other nodes, leftChild and rightChild. A token is a known unit of information that the parser understands, i.e. the data held in the node. Tokens are delimited in the input string by other tokens and white space is ignored.

Expressions are parsed in a single left-to-right scan with the use of two stacks. An operator stack holds the arithmetic and grouping operators; an operand stack holds identifier tokens and intermediate subtrees (when evaluating, this holds intermediate results). During the scan, each time an identifier is encountered, its token is pushed onto the operand stack. Each time a left parenthesis is encountered, it is pushed onto the operator stack. Before the operator is pushed, however, the top-most token on the operator stack is examined. If that token is an operator then its subtree (i.e. the one of which it is the parent) is parsed before the stacking occurs. This parsing is performed using the topmost two nodes on the operand stack. They are popped and replaced by the node representing the top of the top of the subtree. The operator token which indicated the parsing is then popped before the incoming operator token is stacked. A pseudo-code algorithm for the parsing of the string follows. Note that this is pseudo-code and not syntactically coπect or exhaustive.

Function Parse {String, Node): Empty(OpStack); Empty '(TreeStack) ; New (Node);

Token = GetNextToken(String) ; REPEAT

New(Next); // Next is the next node

Next. Data := Token;

CASE Token OF:

// Check whether data is one of the functions in our table KnownFunction:

// This will build a parse tree for that function and // position the Next pointer at the // top of the tree

Top := GetFunctionTreefToken) ; // Get function subtree

//from table and match // arguments Next := Top; // Point Next at top of tree

PushOp(Next) ; // Push onto Operator Stack Token . = GelNextToken(Stήng) ;

Variable, Value or Unknown Function: Push Tree (Next) ; Token := GetNextToken(String);

PushOp(Next);

Token :- GetNextToken(String) ;

Operator: more := TRUE; WHILE more DO if PRECEDENCE(OpStack) < PRECEDENCE (Token) then

PushOp(Next); more . = FALSE; Token := GetNextToken(String); else BuildTree(Next);

") ": more := TRUE; WHILE more DO if OpStack = "(" then PopOp(Next); more . = FALSE; Token := GetNextToken(String); else BuildTree(Next);

UNTIL end of input string while OpStack not empty do

BuildTree(Next); Node := TreeStackftopJ; return(Node) ;

= F-auι-ιn---c--t--i--o---naB B--αui-l--de--T---r-=e»ee(--Ni---e-ax^t)s;:

Next. Data := PopOpQ;

If BinaryOperator (Next. Data) then

Next. Right := PopTreeQ; Next.Lefi := PopTreeQ; else

Next.Lefi . = NULL;

Next. Right := PopTreeQ; PushTree(Next);

To solve (reaπange) the tree to solve for a variable on the right hand side given a value or variable for the left hand side, the following algorithm is applied. As parameters, the function takes a pointer to the root node of the tree, and a string containing the name of the variable for which is the solution is required.

Function RearrameTreefTreeToy, String) returns ExyressinsStrins ι,==

// Create a node which represents the left ofthe tree by searching for (or adding) the equal // sign and removing this part from the tree.

New(LeftTree);

LeftTree :~ FindEquals(TreeTop, LeftTree); Token . = NULL;

// Tokenise string SearchToken := FindToken(String); New (OpNode); New (LeftNode);

OpNode := TreeTop;

WHILE (Token <> SearchToken) DO Token . = OpNode.Data; IF IsInLeft(SearchToken) THEN LeftNode := LeftTree;

LeftTree := Copy(OpNode) ; LeftTree. Left . = LeftNode; LeftTree. Data := Inverse(OpNode.Data) ; LeftTree. Right := OpNode. Right; PopRightTreeQ; // moves OpNode to next operator down the left of

// the tree

ELSE

LeftNode := LeftTree; LeftTree := Copy (OpNode);

IF NonAssociative (OpNode.Data) THEN LeftTree.Lefi := OpNode.Left;

LeftTree. Data . = OpNode. Data; //Don 't invert operator LeftTree. Right := LeftNode; ELSE

LeftTree.Lefi :=LeftNode; LeftTree. Data := Inverse (OpNode. Data) ; LeftTree. Right :- OpNode.Left; END IF PopLeftTreeQ; // moves OpNode to next operator down the right of

// the tree END IF ENDWHILE

NewExpression . = BuildString(LeftTree, Token); RETURN (NewExpression);

In order for the above algorithm to function coπectly, the expression passed from the calculator software must comply with several conditions:

1. The expression must conform to the syntax defined previously. Specifically, if an equals sign is present in the string, then the expression must appear on the right hand side of said sign.

2. The variable to be solved for may only appear once in the expression - the algorithm is not responsible for the optimisation of expressions.

3. There must only be a single solution to the equation. For example, the parser does not solve for roots of quadratics or higher order polynomial equations.

4. Operators may take one or two arguments (this is not limiting since all principal arithmetic and logical operators require two or less arguments).

For each operator used, the parser must be aware of the operator's inverse.

5. The input representation must be infix. If postfix (Reverse Polish Notation) is required, it should be pre-processed to infix by the calling application.

6. The variable "LEFTSIDE" is a reserved word and should not be used in an expression.

The parser can accommodate both 'known' and 'unknown' third party functions. If the parser is aware of the intemal operations of a function (a 'known' function) then it is also able to solve for the parameters of the function, whereas if only the mathematical result of a function can be determined (an 'unknown' function) then this is not possible.

In order to solve for arguments of 'known' functions, said functions have to be broken down into their most primitive form of expression, i.e. in terms of known operators. Thus a function called "Speed" taking two arguments u and v would be defined to the parser and stored in a tokenised tree for the parser to be able to manipulate it. "Speed" is then replaced in that part of the tree by the subtree representing its definition, making it possible therefore to solve for the parameter.

'Unknown^' functions are treated as single values and are not parsed further. Their syntax is defined as FUNCTION(argl, arg2, ..., argn). They can be used in the expression but the parser will not be able to solve for one of their arguments. The design of the parser allows for the function definition table to be appended to dynamically, thus providing the users with the ability to define their own functions.

The parser has an object-oriented design (as does the calculator software), i.e. as a class consisting of private and published operations and private and published data structures. The published member functions form the Application Program Interface (API).

An operator table is maintained for all primitive operators. This contains: a token ID to represent the operator (generated by the parser when the operator is added to the table); the operator token (i.e. the literal string that represents the operator, for example "+"); a pointer to the operator function itself (e.g. a pointer to tan) whether the operator is binary or unary; the precedence of the operator; and the inverse of the operator (this is a pointer into the table).

A function table is maintained for all known functions. This contains:

1. A token ID to represent the function (generated by the parser when the function is added to the table);

2. the function token (i.e. the literal string that is the function name); 3. a pointer to the function itself (this is a pointer to a subtree that defines the function in terms of the primitive operators defined in the operator table);

4. the number of arguments that the function takes;

5. a list of function arguments;

6. The inverse of the function (this is pointer referencing within the table).

Any functions used in input strings which are not found in the function table are treated as single variables with their arguments and are not parsed further. There follows a description of the primary data classes, their data members and member functions which are used within the code of the parser.

The two stacks used during the parsing process are maintained by instances of the 'Stack' template class, which are named 'OperatorStack' and 'ExpressionTree^'. Five member functions are implemented:

Create Creates a new Empty Stack

IsEmpty Retums TRUE if Stack is Empty

Push Pushes a new element onto the stack

Pop Removes the top element from the Stack and retums it to the calling process. RemoveAll Empties the Stack of all elements.

Three memory based tables are used by the expression parser. The operator table contains the valid operators recognised by the parser. The symbol table holds the operands from the expression, and their associated values. The known function table stores the list of functions that have been registered with the parser. All of these tables are maintained by instances of the 'Table' template class (named OperatorTable', 'SymbolTable', and 'KnownFunctionTable' respectively and all of which are collection classes) which contains the following member functions:

Create Create a new Empty Table.

NumOps Retum the Number of Entries in the Table.

Add Add a new Entry to the Table.

Remove Remove an Entry from the Table.

RemoveAll Remove All Entry from the Table.

Find Find an Entry in the Table. Retums Ptr or NULL.

GetAt Return the Entry at the specified row in the Table.

The Operator Stack and the Operator Table will both contain Operator objects which consist of the following data members:

TokenID An identification generated and used within the parser to represent the operator.

Token The literal string that is the operator (e.g. '*').

Num_Args Represents the number of arguments that the operator takes. This member could be a boolean BinaryOp, although the data type actually utilised is more amenable to expansion. Precedence Holds the precedence of the operator. Inverse Token of the inverse.

ExecFunc Pointer used to execute the function.

The ExpressionNode class is an Abstract Base class. Instances of objects from classes derived from this form the expression tree, and are stored on tbe Expression Stack. The algorithms specified imply runtime type checking which is implemented via the ObjectType operation. All of the member functions are listed below:

ObjectType Returns the ClassID that this Object belongs to.

Evaluate Pure virtual function which evaluates the expression tree.

FindOperand Pure virtual function which retums the sub-tree that the operand is in.

A virtual function is one which has several definitions contained within different derived classes. The function is called via a pointer to an instance of the derived class. The run-time code determines the type of object which the pointer references, and calls the appropriate definition of the function for that object.

Since the value of the pointer is variable at run- time, the same program line in the source code may have varying results at run-time. The OperatorNode class is derived from the ExpressionNode base class.

The Expression tree is a form of binary tree, and the OperatorNode class contains the following data members:

OpTokenlD Token of Operator. LeftTree Pointer to left subtree of expression. RightTree Pointer to right subtree of expression.

It also includes the following member functions:

ObjectType Retums the ClassID that this Object belongs to. Evaluate Evaluates this Expression Tree (Placeholder)

FindOperand Retums which Subtree the Operand is in. AddLeft Adds a new Expression Node as the Left Tree

AddRight Adds a new Expression Node as the Right Tree

DelLeft Deletes the Left Tree

DelRight Deletes the Right Tree

The OperandNode class is also derived from the ExpressionNode class. It contains the following data members:

Symbol Symbol of Operand

SymbolTablelD Index into Symbol Table for this Operand

The member functions of the class are below:

ObjectType Retums the ClassID that this Object belongs to.

Evaluate Retums the Value of this Operand

FindOperand Retums value if this is the required Operand

The Expression class holds pointers to information on an expression. These are outlined below:

ExprTree Points to the expression tree for the expression.

SymbolTable Points to entry in the symbol table for this expression.

The Symbol class holds the value for an operand. The data members of this class are detailed below:

Symbol Symbol of Operand. Value Value of this operand.

The KnownFunction class represents a function that has been registered with the parser. It contains the following data members:

FuncID ID for this function, created by the Parser

Token String representing the function name Expression Expression for this function Inverse Is this required for a Known Function?

There follows a diagrammatic description of the components of the parsing software represented using the Object Modelling Technique (OMT) methodology. The OMT methodology is described in detail in a book entitled "Object-Oriented Modeling and Design", by J. Rumbaugh, published by Prentice-Hall (ISBN 0-13- 630054-5).

The methodology uses three kinds of models to describe a system: the Object model, describing the objects in the system and their relationships; the Dynamic model, describing the interactions among objects in the system; and the Functional model, describing the data transformations of the system.

The Object model employed here describes the static structure of the objects in a system and their relationships. The object model contains object diagrams, shown in Figures 17 to 22. An Object diagram is a graph whose nodes are object classes and whose arcs are relationships among classes.

List

Description is now provided of a list object according to the present invention. Once the CPU 10 has been switched on, as mentioned above, the user is presented with options as to which of the various objects it is desired to run. These are displayed from the toolbar 30 displayed on the monitor 14. A further list object, which can be selected from the toolbar, is now described with reference to Figures 23 to 28. The list object can be employed principally for listing data. The term "data" is used widely to include not only alphanumeric data but also objects and the like.

As shown in Figure 23, the user is presented with a visual display 2000 on the monitor 14 which again is generated by electrical signals output by the CPU 10. The display initially includes a grid 2002 having initially three columns, Cl to C3, and three rows, Rl to R3, the columns having column titles 2004 (initially shown as being "untitled") and the rows having row titles, initially in the form of the numbers " 1" to "3", as shown at 2006. Instead of the above row auto-titling option, the rows may by default all be called "New row".

The display 2000 includes, at the top, a title bar 2008, which displays the name of the cuπent list. By default, this name is the same as the saved name of the relevant list file, which, again by default, is "List". However, the name of the list can be filled in by typing the appropriate symbols from the keyboard 12.

The display 2000 also includes, beneath the title bar 2008, a menu bar 2010, which displays, as can be seen from Figure 23, the following pull down command menu options: "File", "Edit", Format (entitled "Blox" (trade mark)) and "Help", which generate pulldown menus when clicked upon using the mouse 18. These are explained in more detail later. Also as described in more detail later, some commands on the pulldown menus perform an action immediately, whilst others produce a dialog box, with further options. If an option is shown dimmed on the display, it is not cuπently available until a selection has been made. An ellipsis on the relevant menu command (...) is used to indicate that a dialog box will be displayed. A check mark is used to indicate that the relevant option is already on .

The display 2000 further includes. beneath the menu bar 2010, a two row toolbar 2012 which displays a series of tool symbols 2014 to 2046 having the appearance of depressible buttons. These provide speedy access to the most commonly used commands from the set of command menu options. They will be described in detail later. They can be accessed by clicking on the appropriate tool symbol using the mouse 18, or else by use of appropriate keys on the keyboard 12. The tool symbols on the second row relate generally to the manner in which various aspects of the list are viewed, and are refeπed to collectively as a viewbar 2047.

The display 2000 also includes, next to the viewbar 2047, a drop down type combo box 2048 which generates a list of the views which have been created. More detailed explanation of views is given later. The display 2000 also includes, beneath the toolbar 2012, an action bar

2050, which displays a respective sort action button-type symbol 2052, a respective search action button-type symbol 2054, and a respective filter action button-type symbol 2056 for each column Cl to C3. These effectively enable "one-touch" sorting and filtering of the data in the list, as well as simple searching. Again, they will be described in detail later. They can be accessed by clicking on the appropriate tool symbol using the mouse 18, or else by use of appropriate keys on the keyboard 12.

Again, the display 2000 includes, beneath the grid 2002. a status bar 2060. In the bottom left hand comer of this bar details are provided about the cuπent command being performed. Information about a command can be obtained by clicking on the command using the mouse 18. and reading the text in the status bar.

The list object may be used as follows. As mentioned above, initially the user as presented with a grid 2002 of three columns and three rows. The cuπent active cell in the grid is generally indicated with a bold line around its edges, as shown at (Rl, Cl) in Figure 23, although in fact the bold line, which is used for highlighting one or more cells in the list, may hence encompass more than one cell, and so may be larger than the active cell. The active cell can be filled with alphanumeric text input from the keyboard 12, or, for example, with an object, or plain data, "dragged and dropped" from elsewhere. This data is aπanged by the CPU 10 into row and column format and the arranged data is processed into output signals to be passed to the monitor 14. The aπanged data is also processed into electrical storage signals for storage in a file or database on the disc drive 16. Instead of the disc drive 16 being dedicated to a specific computer system, it may be centrally networked to a number of different computer systems. When data input to a particular cell has been completed, the ENTER key on the keyboard can be depressed; this has the effect of automatically moving down the cursor to the next cell in the column. Altematively, a new cell can be selected by clicking within the cell using the mouse 18. A line break in the lines of text can be created by depressing the CTRL and ENTER keys simultaneously. Once all required entries have been keyed in, a save tool symbol 2018 can be clicked. The user can either provide his own filename for the list to be saved, or can select from a list of pre-selected filenames (such perhaps as "to do", "address", "calls list" or "dates") which is displayed on clicking the save symbol. The list can then be saved on the hard disc drive 16 as a series of electrical signals. Altematively, if the list is embedded within a container document, it can be saved as part of that of that document.

The user can add further empty rows or columns by moving the cursor, via the keyboard 12 or mouse 18, to the edge of the last row or column. The cursor bit map then changes to a vertical or horizontal "resize" pointer as appropriate. If this pointer is clicked on using the mouse 18 and then dragged slightly and released ("dropped") by releasing the mouse button, an extra row or column is created.

New blank rows or columns can also be inserted by clicking on an insert row or an insert column tool symbol 2034, 2036 displayed on the toolbar 2012. If a row is selected before clicking on the insert row symbol 2034, then the new row is inserted before the selected row. If a number of rows are selected, then that number of rows is inserted before the first selected row. The same principle applies to the insertion of columns using the insert column symbol 2036 or the appropriate menu command.

Conversely, rows or columns can be deleted by selecting those to be removed, highlighting them, and depressing the DELETE key on the keyboard.

The title text for columns and rows, displayed in the column and row titles 2004 and 2006, may be changed by double clicking the mouse 188 on e appropriate title cell and entering the desired title. Furthermore, the title cells can be increased in size by dragging the cursor using the mouse across or down from the title separator. This also has the effect of widening or lengthening the column or row.

The commonly used commands accessible via the toolbar 2012 are next described.

A New list tool symbol 2014, also available under the "File" pulldown menu, generates on the monitor 14 a new blank list for filling in by the user.

An Open list tool symbol 2016, also available under the "File" pulldown menu, enables the opening of an existing list by clicking on the appropriate symbol in the toolbar 2012. A register of list titles is then displayed on the monitor 14 for the user to select the required list. One particular list which may be provided is a list of all lists saved to the file or database.

The function of the Save tool symbol 2018, also available under the "File" pulldown menu has already been described.

Clicking on the Template tool symbol 2020 enables the creation of a new list from a selection of possible templates. The templates are empty lists, with pre- set column and row titles and column properties. A template can be used as the basis of a new list, for example for recording telephone calls. If the new list symbol is clicked, a selection of such templates is displayed on the monitor 14. For example, a flight itinerary template could be displayed which might have columns entitled "Date", "Depart time", "Check in time", "Airport", "Airline", Flight No.", "Aπival city", and "Arrival time". A template may also possess data entries.

A particular example of a template (a "to do" list) is now described with reference to Figure 24. The appropriate column titles are given at 2004 as "Urgency", "Importance", etc. The user can then fill in the grid 2002 in the manner described above with the relevant infoπnation, as shown in Figure 24. Clicking on the Always On Top tool symbol 2022 provides the user with the choice between the list application always remaining in front of the active window, or the application moving beneath the next maximised window that is selected. Using OLE technology, the list object can either be embedded in or linked to a document. The simplest method of embedding - by dragging and dropping the object from the main toolbar 30 - has already been described. This would be appropriate if it were desired to embed a new object. If, altematively, it were desired to embed a previously created list object, then this can be achieved by first opening the object, then using the Drag list tool symbol 2024 to drag the object into position in the relevant document. Once the object is in position, it can be activated by being double clicked upon.

In order to link the list object, it is first opened, and then dragged into position in the target document using the Drag link tool symbol 2026. For example, an expense details list could be maintained which could then be linked to, say, a Word (trade mark) report document. Source data must be saved to a file before being linked. Also, individual cells of data can be linked in analogous fashion.

A Properties tool symbol 2028, available under the Format pulldown menu, when clicked on using the mouse 18 provides a list of possible data properties for the particular column or row it is desired to define, in the form of a properties dialog box, which generates property options which are specific to the particular data type which has been chosen via the properties dialog box.

The properties available for columns are (a) data types, and then, according to the data type chosen, (b) justification and (c) decimal places. The use of data properties allows accurate data input and management for such operations as sorting, searching and filtering, as will be described shortly.

As to (a) - data types, the following data types are available for columns: Text - column entries may include any alphanumeric characters. Number - column entries may only be integers.

Yes/No - column entries default to NO. A double click in a cell changes from NO to YES, and vice versa.

Traffic lights - column entries default to a block of green colour. A double click changes from green to yellow, and a single click from yellow to red. Any type of text can be typed into a cell even if it has a particular traffic light colour.

Decimal - column entries may only be numeric data with a decimal point.

OLE Item - column entries may only be OLE objects which have been drag dropped or otherwise inserted into cells. Objects can be either embedded or linked. For example, a Microsoft Word or Excel (trade marks) object can be either embedded or linked in a particular cell.

Date - column entries may only be in the form of a date. Optionally data types may be provided for time and date and time.

Pulldown - a pulldown selection box is displayed when the user clicks within a cell in the grid 2002. The box catalogues all the unique entries already input for the column. Such entries can therefore be selected from the selection box, hence saving repetitive typing. The option may be provided of only entering data into new cells which has already been input to existing cells. Position - an optional position field may identify the column which has been selected.

As to (b) - justification, various justification options may be provided. Also, for text and numeric data types, the position of an entry within its cell can be modified.

As to (c) - decimal places, if a column has been defined as decimal, then an additional field is displayed on the column properties box for the maximum number of decimal places.

The properties available for rows are the ability to input the row title. A Resize cells tool symbol 2030, also available under the Format pulldown menu, can be employed particularly when a cell contains a long entry of text. It enables the resizing of rows or columns to the size of the largest entry. The row or column width or height is increased by moving the cursor to the edge of the title cell and dragging it across or down. Conversely, the column or row size may be reduced to zero by dragging the edge of the row or column back until it crosses the edge of the previous row or column. When the cursor is dragged across the titles either side of the missing column, it changes shape to a horizontal or vertical pointer, as appropriate.

A Resize window tool symbol 2032, also available under the Format pulldown menu, enables the list's application window to be resized when using reduced screen mode, so as to hold all (or as many as possible) of the cells in the list.

The function of the Column tool symbols 2034 and 2036, also available under the "Edit" pulldown menu, has already been described.

A Manage view tool symbol 2038 can be employed to save a set of sort and filter conditions (for more details of which see below) as a view. First the entry which it is desired to filter is chosen, then the manage view symbol is clicked on. A name can be given to the view at the view dialog box which is displayed. and the "add" option should then be chosen. Subsequently, any views which have been created can be applied or removed.

A Reapply last sort and filter tool symbol 2040 enables the last sort and filter conditions to be reapplied.

The Find tool symbol 2042 is utilised for global searching within the list. A Show/hide action bar tool symbol 2044 enables the action bar 2050 to be shown or hidden as desired.

Finally, a Display current filter tool symbol 2046 allows the cuπent filter to be displayed.

If the user is part of a network, then a list can be stored in a central directory or database, which can be available to other users. Several users can view the same list at the same time. In these circumstances, it is important that the display is updated regularly, to check for updates. This can be achieved by clicking on an optional refresh list tool symbol. Altematively or additionally, an auto-refresh option can be selected which may be arranged to update the display at regular preset intervals. This can be achieved via the options dialog box available under the Format pulldown menu.

Other features which may be available on the menu bar 2010, are as follows. Available under the "File" pulldown menu may also be a "save as" option providing the opportunity to save a new or existing list with a new title name, "save as template" enabling the saving of a particular list (whether or not complete) as a template, "delete lists" providing a display of lists from which one or more can be deleted, "delete templates" providing a display of title names of all templates from which one or more can be deleted, "print" (as provided on Microsoft Windows), "print preview", for displaying a screen preview of a list as it would appear in print (including zoom in and zoom out features), "print setup" for changing the Windows printer settings, and "exit" for closing the database object.

Available under the "Edit" pulldown menu may also be editing options generally available with Windows (trade mark). Such options may be an "undo" option to reverse the previous editing or formatting operation, "cut" to remove the cuπently selected data from a list and copy it to a clipboard, from where it can be pasted into a new location, "copy" for copying the currently selected data from a list to the clipboard, from where it can be pasted into a new location, "paste" for pasting data from the clipboard to the cuπent cursor position of the active document, "paste link" for pasting data from the clipboard to the current cursor position of the active document, with the data in the new location being changed to match the original if the original is updated, "find" to open the find dialog box to search for specified entries, and "delete" to remove selected rows or columns. The find facility is also available under the find tool symbol 2042. Also available under the Edit pulldown menu is "insert new object", which enables an object of be inserted at a chosen OLE data type location within the list.

Available under the Format pulldown menu may also be "option" to open the options dialog box which contains controls which apply to the whole list (such as "save every", "refresh every", "poll on activate" for refreshing the list automatically every time the list window is activated, and "set defaults" for setting various defaults), "fonts" for accessing the fonts dialog box to enable the font to be changed, "view" for enabling the list toolbar 2012 and status bar 2060 to be displayed or hidden, and "data". Available within "data" may be "collapse" for selectively hiding parts of the list by highlighting the area to be collapsed, clicking inside the title cell, and dragging down for rows or across for columns, "uncollapse all" for restoring any collapsed rows or columns, and "delete" for removing selected rows or columns. Further options available within data are described shortly.

Available under the "Help" pulldown menu may be a number of "help" features such as a help index, an introduction to the help facility, and detailed help information.

Attention is now turned to the action bar 2050. This can provide a particularly quick and simple way of arranging and selecting data. As stated above, each column of the grid 2002 is provided with a sort symbol 2052, a search symbol 2054, for column specific searching, and a filter symbol 2056. If, as is the default "properties" option, the cells in a particular column contain text, clicking on an individual sort symbol orders the cells in that column into ascending or descending alphabetical order, dependent upon whether the up symbol 2062 or the down symbol 2064 on the sort symbol 2052 is clicked on. Coπesponding cells across the other columns will also be re-ordered. The content of the cells in a particular column may altematively be set to a property other than text using the properties tool symbol 2028. If, for instance, it is set to "Yes/No", then it will be ordered according to the yes/no sequence. If it is set to "decimal data" or some other numeric data type, then it will be ordered numerically. If it is set to "traffic light", then it will be ordered in the order green, yellow, red. Again, if is set to "date" then it will be ordered in date order.

Alternatively, the cells in a particular column may be prioritised by depressing the CTRL key whilst clicking on the various columns in the desired order. Clicking on the sort symbol 2052 then orders the cells according to their selected priority. In fact, entries can be sorted across more than one column in this way.

Sorting can also be effected using the "data" menu available under the "Format" pulldown menu, especially in circumstances where it is desired to sort entries in more than one column (that is, in circumstances where the data in the first column is the same). Via this menu can be accessed toggles to enable sorting to be carried out in ascending or descending order, and a sort dialog box, as shown in Figure 25. Into this box can be input, at primary sort box 2070, secondary sort box 2072 and tertiary sort box 2074 (and yet further sort boxes if required), the titles for the various columns it is required to sort, in the required order. A choice of ascending or descending sort can be made for each column via the three (or more) ascending sort symbols 2076 and descending sort symbols 2078. Hence, dependent upon the properties defined for each column, the primary sort column might be sorted according to the traffic light colour coding, whilst, for the secondary column, each entry in the primary column having a particular traffic light colour could be further sorted, say, alphabetically, and so on. The same multiple sort effect as described in the preceding paragraph can be achieved by holding down the SHIFT key and clicking on the sort symbol 2052 in each chosen column in turn. The data is first sorted on the first column which is chosen, and then on the second column, and so on.

The action bar 2050 can also be used for rapid filtering, via the filter action symbol 2056 provided for each column. Clicking the symbol produces a dropdown selection box 2082, as shown in Figure 26, which generates a list of all the unique entries in a particular column. A single such unique entry can be selected, the other entries then being filtered out, or else multiple entries can be selected by depressing the SHIFT key on the keyboard 12 at the same time as clicking on the appropriate entries using the mouse 18. The list then displays only the filtered entries. The names of the filtered entries may be displayed in a pop up menu, or else altematively on the action bar 2050. Column filters are removed by clicking on the relevant filter symbol 2056 and selecting "[Clear]". A previously used filter for the relevant column can be restored by clicking on a the reapply last sort and filter tool symbol 2040 on the action bar 2050.

As discussed above, filters for more than one column can be set using the SHIFT key. The combined filter is an AND filter - in other words, the conditions set by all the filters must apply. To set an OR filter, the CTRL key is depressed while clicking on the filter action symbol 2056 for the second and subsequent columns.

An example of the use of the filter facility is now described with reference to Figures 27 and 28. Figure 27 firstly shows an unfiltered list based on the "To Do" template illustrated in Figure 24, with the first two columns ("Urgency" and "Importance") containing traffic light data types. Figure 28 then shows the result of filtering the list of Figure 27 by clicking on the filter action symbol 2056 on the Who? column, and selecting "John".

The display ("view") generated using a particular sort and/or filter strategy may be saved on the hard disc drive 16 using the Define Query option available in the Data dialog box itself available under the Format pulldown menu. The view thus saved may be recalled when desired using the Apply Query option available adjacent the Define Query option.

A further feature is the search option, by which items in particular cells can be searched for via a modeless dialog box (so that the remainder of the list object functionality can be accessed whilst searching). A particular feature available using the list object is the provision of context sensitive shortcut menus. Different menus drop down from the position which has been clicked on. In fact three shortcut menus are provided for the list object, namely a list body, a column and a row shortcut menu. These are available by "right" clicking on a cell in the grid 2002, a column title or a row title as appropriate. On the list body shortcut menu are provided such options as insert row, insert column, resize cells, resize window and cell font. On the column shortcut menu are provided such options as collapse and uncollapse all, to collapse certain parts of a list, title font and properties. On the row shortcut menu are provided similar options as for the column shortcut menu, but as applied to rows rather than columns. A shortcut menu is closed, without choosing a command, either by clicking anywhere outside the menu or by depressing the ESC key on the keyboard 12.

The list object has full OLE functionality. This means that it can be used as a source object or a destination object for linking and embedding information. The list object can contain other objects within its own cells. In order to achieve this, the relevant column should be defined as data type OLE item, as described above. Indeed, the list object can be dragged into the cell of another list object. Sections of other objects can also be dragged and dropped into the cells of the list object, with care being taken that data is matched to any column properties which have already been defined. Further, entries created in the list object can be copied and placed into tables created in other applications. For example, rows and columns of a list can be selected and dragged into a table in Microsoft Word 6 (trade mark). Also, more than one instance of the list object may be open on the display at the same time. Information from one can then be transferred or copied to the other using copy and paste or drag and drop.

Further, the present list object can be activated in-place, so that it can be used whilst using other OLE compliant applications.

A summary of the above described functionality is provided in the flow diagram of Figure 29. The list object described above may be implemented computationally in many different ways. As just one example, it may be implemented using the Microsoft (trade mark) Foundation Classes. Such an implementation is now described with reference to Table 3. TABLE 3

Class Super Class Has a Reference to Named

CActionBar CDispiayBar

CBool CRTTIBase

CBoolCell CCell CString m_strStateOneText CString m strStateTwoText

CList CObject CColumnArray m_columnAιτay CRowArray m_row Array CString m_strCurrentLιst CString m_strCurrentTemplate

CCell m_pCurremlyEdιtedCel 1 CListView m_pVιew

CListApp CWinApp CObList m_IconBιtmaps

CStπng m_strDataSource

CString m_strFιiterWιndowClassName

CString strAppName

CString strVersion CObject m_pObjectType

CListContainerltem COleClicntltem CString m_str

CListDoc COleServerDoc CString m_strDefaultTemplatePath CString m_strTemplate CObList m_UndoFιleLιst

CList m_pLιst CListView m_pVιew

CListServerltem COIeServerltem CObList m_pServerEntπes

CListView CView CListEdit m_pEdιt

CQueryList m_pQueryLιst

CListEdit m_pSearchEdιt

CListContainerltem m_pSelectιon

CFilterBox m_pWndFιlterBox

CFilterDisplayWnd m_pWndFιlterPopup

CCell CObject CColumnlnfo m_pColumn

CListContainerltem m_pltem CTitlelnfo m_pRow

CColumnArray CTitlelπfoArray CActionBar m_ActιonBar

CFilterBar m_FιlterBar

CDispiayBar m_HeadιngBar

CColu nFilter CObject CObList m_pFιlterByLιst

CColumnlnfo CTitlelnfo CString m_aStrιngArray CString m_strFιlter

CColumns CRecordset CString m_strColumnName CString m_strColumnNameParam CString m_strOwner CString m_strOwnerParam CString m_strQualιfιer CString m_strQualιfιerParam CString m strTableName CString m_strTableNameParam

CString m_strTypeName

CCoiumnSoπ CObject

CDatabaseTablesDialog CDialog CString m_strTable CComboBox m_tablesLιst

CStπnε m_pTableNameLιst

CDateCell CDateTimeBaseCell

CDateTimeBaseCell CTextCell

CDateTimeCell CDateTimeBaseCell

CDispiayBar CObject

CDouble CRTTIBase

CDoubleCel! CTextCell

CEmbeddedCell CCell CLong m_ib CString m_strData

CFilenameCell CTextCell CString m strData

CFilterBox CListBox CListView m_pVιew

CFilterDisplayWnd CWnd CString m_strText

CListView m_pVιew

CFindFirstDialog CFindReplaceDialog CString m_strFιndString

CFrameWnd m_pFrame

CFixedLengthTextCel I CTextCell CString m strData CGetTypelnfoSet CRecordset CString m_strTypeName CInitDialog CDialog CInPlaceFrame COIelPFra eWnd CString m_strLastSelectStnng

CViewBar m_wndQueryBar

CToolBar m_wndToolBar

CFindFirstDialog m_pWndFindDιalog

CListBodySet CRecordset CString m_RowTιtle

CRowOfCells m_pRow

CListCells CObArray

CListEdit CEdit CListView m_pVιew

CListFilter CObArray

CListOptionsSheetTabOne CPropertyPage CListDoc m_pDoc CListOptionsSheetTabTwo CPropertyPage CListDoc m_pDoc CListSet CObject CString m_strlmportTable

CList m_pLιst CLong CRTTIBase

CLongCell CTextCell

CMainFrame CFrameWnd CString m_strLastSelectStπng

CViewBar m_wndQueryBar

CMvToolBar m_wndToolBar

CFindFirstDialog m_pWndFιndDιalog

CMfxStπng CString

CMyToolBar CToolBar

CNStateCell CCell

COb_jectType CString m MinorVersionNumber

CPullDownCell CFixedLengthTextCell

CPulldownCombo CComboBox CString m_strOrιgιnaιText

CListView m_pVιew

CQuery CObject CListFilter m_LιstFιlter

CObList m_SortιngLιst

CString m_strTιtle

CQueryDialog CDialog CStπng m_deletedNameLιst CString m_strCurrent CComboBox m_stπngLιst CStπng m_strVιew

CString m_vιewNameLιst

CQueryList CObList CQuery m_pCurrentQuery

CRowArray CTitlelnfoArray CListCells m ListBody

CRowOfCells CObArray

CRowPropertiesDialog CDialog CEdit m_ctrlTιtleCaptιonEdιt CStπng m strRowTitle

CRTTIBase CObject

CRTTlDate CRTTIBase

CRTTI String CRTTIBase CString m_stnng

CSearchEdit CEdit

CSelectViewDialog CDialog CComboBox m_strιngLιst CStπng m_strVιew

CString m_vιewNameLιst

CSortByDialog CDialog CComboBox m_ctrlFιrstCombo

CComboBox m_ctrlSecondCombo

CComboBox m_ctrlThιrdCombo

CString m_strFιrstCombo

CString m_strSecondCombo

CString m_strThιrdCombo

CList m_pLιst CListView m_pVιen CStandardListBodySet CListBodvSet

Lbumlnto CDialog CString m_str Author

CStπng m_strComments

CString m_strFιleName

CString m_strKeywords

CString m_strSubject

CString m_strTιtle

CTables CRecordset CString m_strName CStπng m_strNameParam CStπng m_strOwner CString m_strOwnerParam CStπng m_strQualιfιer CString m_strQualιfierParam CStπng m_strRemar s CString m_strType CString m_strTypeParam

CTemplateDialog CDialog CObList m_IconLιst

CStπng m_strDιrectory

CStπng m_strExe

CString m_strExtensιon

CStπng m_strFormat

CString m strSelectedFile

CTextCell CCell

CTimeCell CDateTimeBaseCell

CTitlelnfo CObject CStπng m strTitle

CTitlelnfoArray CObArray

CTitlePropertiesDialog CDialog CStπng m_aryCellNamcAιτay

CComboBox m_ctrlDataTypeCombo

CEdit m_ctrlNoOfDecιmals

CEdit m_ctrlTιtleCaptιonEdιt

CString m_strDataType

CString m_strHJust

CString m_strSelectedStπng

CString m_strTιtleCaptιon

CStπng m_strVJust

CComboBox m_wndHCombo

CEdit m_wndLιstEdιt

CListBox m_wndStπngLιst

CComboBox m_wndVCombo

CString m_pStπngArray

CToolDialog CDialog

CTrafficLightCell CNStateCell

CViewBar CToolBar CViewBox m ComboBox

CViewBox CComboBox CActionBar is the class which implements the action bar for each column, and the processing of mouse events which are channelled to it via CListView (the class responsible for input/output). It contains member functions which are responsible for drawing the action bar on the monitor 14, combined with data members necessary for this function. The CActionBar class is derived from

CDispiayBar which is responsible for the drawing of the column titles. There is an instance of both CActionBar and CDispiayBar for each individual column, and these are stored in the CColumnArray class.

The software interface to the data stored within the list is provided by the CList class which encapsulates the CColumnArray and CRowArray classes. Access to the data stored in each cell is achieved through a series of pointer arrays. The data in a cell is stored in derivatives of the CCell class. Access to all cells in a row is provided by a CRowOfCells class which contains pointers to each of the CCell instances which constitute a row. To provide access to all of the rows in the list, a CListCells class is used to hold pointers to each CRowOfCells class. This CListCells class is combined with the height/formatting information for each row, to form the CRowArray class. Thus, since the CList class contains the CRowArray class, all access to the list data (both formatting and within the cell) is achieved via CList. The title information for each row is held in a CTitlelnfo class, of which one instance exists for each row. The CTitlelnfoArray holds pointers to the

CTitlelnfo instances. The sheet of cells is being stored as an array of rows, and consequently the only data accessed via the CColumnArray class is the formatting information (e.g. width, title) of the columns. The access of the cell data is shown diagrammatically in Figure 30. The CRowArray, CListCells and CRowOfCells classes are all allocated memory dynamically. Thus the memory usage of the application grows and shrinks with the addition or removal of rows/columns. Addition of a column results in an extra pointer being stored in all instances of the CRowOfCells class. Addition of an extra row results in an extra pointer in the CListCells class instance. Any addition of cells (be they in an extra column or an extra row) results in extra instances of the CCell class derivatives (i.e. the allocation of the CCell class is independent of where the cell fits in the list). The user changes the properties of a row via the CRowPropertiesDialog class, and of a column through the CTitlePropertiesDialog class. CListApp is derived from the MFC class CWinApp and handles the initialisation necessary when a Windows application starts. The CMainFrame class is responsible for the drawing of the application's frame, its titlebar and menubar. It also coordinates the display of the floating toolbar and the viewbar (which contains actions related to the recall of previous 'views' of the data). The toolbar is implemented via the CMyToolBar class (an instance of which is stored with CMainFrame). The properties of the toolbar can be edited by the user, and the CToolDialog class is responsible for this aspect of the implementation. The viewbar and its associated combo box 2048 are rendered by the class CViewBar (derived from the MFC CToolBar), which contains an instance of CViewBox. CListContainerltem is derived from the MFC class COleCIientltem and allows the software to behave as an OLE container. For each embedded object there is an instance of the CListContainerltem class, which holds information on the object.

By default, when dropped onto an OLE container, an object from another application will not interact with the containing software. Instead it will cover a portion of the container's window and will function independently. However, the list application does not act as a traditional container, in that objects are embedded in the cells of the list rather than the list application itself. In a conventional OLE container, CView is responsible for the drawing of any embedded/linked objects, whereas in the list application, this responsibility is delegated to the CCell class. This is achieved by removing the standard code from the CView and CDocument classes and writing new code contained within CCell.

The CServerltemClass allows the application to act as an OLE server. Whenever the user initiates a drag/drop, an instance of the CServerltemClass is created. The nature of the client application onto which the object is dropped determines the format conversions that take place (e.g. the cells may be converted to a Device Independent Bitmap or text). The final form of the object data and information about the server is stored in the CServerltemClass which is passed to the client application. The class CInPlaceFrame (derived from COlelPFrameWnd) allows the software to support 'in place editing'. Here the list application can be run from within another application (which acts as a container). The CInPlaceFrame class is responsible for drawing the application frame without the titlebar/menubar which is associated with a normal application window. The CCell class is the base class for all of the different types of cells. and it defines the basic properties common to all cells such as the lines surrounding the cell, and the ability of the cell to act as an OLE container. For the latter, the cell requires details about the object so that it is then capable of displaying (and manipulating) it. The required details are stored within an instance of the CListContainerltem class, and in order to access the information, the CCell class contains a pointer (named m_pltem). This pointer is set to NULL if not embedded/linked object is present within a given cell. Also contained within the CCell class is a pointer to a CColumnlnfo class which contains the options for the column in which the cell is contained (e.g. width, colour, font). Also present is a pointer to an instance of the CTitlelnfo class, which contains the title information for the row that the cell is in.

The other cell types are derived either directly or indirectly from CCell. CBoolCell defines the properties of a Boolean (Yes/No) cell. It contains two CString class instances (named m_strStateOneText and m_^strStateTwoText), which contain the 'Yes' and 'No' text respectively. The CDateCell, CTimeCell and

CDateTimeCell classes are all derived from CDateTimeBaseCell and provide cells with the ability to store the date and or time. CDoubleCell provide cells that can have floating point (non-integer) number stored in them, whereas the CLongCell class provides cells with the ability to store large integral numbers. The CFixedLengthTextCell class is derived from the CTextCell class and gives a cell that can contain text only upto a certain number of characters. The CNStateCell class implements a cell that can have a certain set of predefined states (e.g. one of a list of names) which are cycled through on a double click event from the user. Derived from this class is the CTrafficLightCell class which implements a visual data type comprising the display of one of red, yellow or green. The

CPullDownCell contains code and data which generates a cell having a list of values which are selected from a combo box implemented by the CPullDownCombo class.

CListDoc is the document class responsible for maintaining the data. In the present object, the cells themselves store the data, including also any embedded items. The CListDoc class contains pointers to both CList (the software interface to the data stored in and about the cells), and CListView (the class providing the user interface). The CListDoc class is also responsible for some general aspects of the application, such as the provision for the undo option and the templates (e.g. default template path and name). CListView. which is derived from CView, is the class responsible for the user interface. The CListView class is the main means by which the application software communicates with the Windows environment. Thus all Windows events are channelled via CListView to the relevant part of the software (e.g. a click on an action bar will be routed through to CActionBar for handling). The CView class is a MFC which is overridden in all MFC applications.

The CListView class contains several pointers to other classes present in the software. There is a pointer to a CListEdit class which is derived from CEdit and provides the edit line in each cell and also the edit line for the search dialog box. Another pointer is present for a CQueryList class, which contains an array of pointers to CQuery instances which hold details on combinations of filter and sort actions.

Although the display of objects embedded in a cell is handled by the cell, special consideration is required when an object is selected by the user (e.g. for copying/resizing/moving). Therefore, in addition to these pointers, there is a pointer to a CListContainerltem class which points to the class instance for the currently selected object.

Input of data is performed via CListView. CListView receives the keypresses and passes them to CList. The CList class contains a pointer to the active cell's instance of CCell (named m jpCurrentlyEditedCell). CList then passes the characters to the CCell class derivative which determines whether the input data is of the correct type for the cell, and manages the storage or rejection of the data. The same flow of data occurs for Windows events such as a mouse double click. The CBoolCell class derivative, for example, is toggled between states on receiving a double click event.

Filtering is implemented using several classes. The CColumnFilter class holds the filter being applied to a single column. It contains a data member denoting whether the filter for the column is an AND/OR filter as well as a pointer to a CObList class (named m_pFilterByList) which stores the cell values to let through the filter. There is an instance of the CColumnFilter class for each column that is being filtered. The CListFilter class holds a pointer to each of these instances. The filtering process itself is controlled by the CList class, and the CListView class is also involved since it contains pointers to the CFilterBox and CFilterDisplayWnd classes. For the column being edited, the CFilterBox class is used to store a list of unique entries from which the user can select those to be screened/let through. The CFilterDisplayWnd class is responsible for displaying the pop-up box holding the unique entries stored in the CFilterBox class.

For each row the CList filtering member function assumes that the row is to be displayed. It then checks each cell in the row against the filtering criteria stored in CColumnFilter. As soon as the criteria for a cell evaluates to false the filtering algorithm moves onto the next row without displaying the current row. If CList reaches the end of the row without reaching a false condition, then the row is displayed.

The CColumns class is used to make the software compatible with the Open DataBase Connectivity (ODBC) model for the interchange of data between applications. It is a derived class of CRecordset and is used in the extraction of column details in an open database. The actual list data is transferred to an ODB via the CListBodySet class (which contains a pointer to a CRowOfCells instance). Other classes associated with ODBC are CGetTypelnfoSet, CListSet, CStandardListBodySet, CDatabaseTablesDialog and CTables. CListSet is utilised as a buffer during ODBC transfer of data, and CTables stores information on the nature of the data, and its source application.

The sorting process involves several classes. The CSortByDialog class is responsible for the display of the dialog box which prompts the user for the columns by which to sort. The alternative method of specifying the sorting criteria is via a combination of the mouse 18 and keyboard 12, wherein the user clicks the sort icons on the action bar of the columns to be sorted while depressing the CTRL key on the keyboard. Both of these methods result in the creation of an instance of the CColumnSort class for each column involved, which holds the details of the sort for the column (e.g. ascending/descending). The request for a sort is passed to CList from CListView. The sort is overseen by the CList class, although the actual comparison of the data is performed by the cell units themselves (i.e. a CCell member function).

A new instance of the CQuery class is filled during any sort or filtering action. A filter or sort or combination thereof constitutes a query of the list (or a 'view' of the data as the user sees it at the GUI level). The CQuery class contains a CListFilter instance (an array of pointers to the filters for the columns), a CObjectList class named m_SortingList (which holds pointers to the instances of the CColumnSort classes), and the title of the query ('view'). The CQueryList class holds an array of pointers to CQuery class instances allowing the user to recall previous ^'views' of the data, and also a pointer to the current query's instance of CQuery. Queries can be selected/edited/deleted by the user, and this takes place using the dialog boxes implemented by the CSelectViewDialog and CQueryDialog classes. A request for a search is initiated by CListView. The are two methods by which the user can start a search. Clicking on the column's action bar causes the CSearchEdit class (derived from the MFC Cedit edit controller) to display a edit line ready for the input of the search text. Alternatively the user can select Find from the Edit menu, which invokes a member function of the CFindFirstDialog class (derived from MFC CFindReplaceDialog) causing a dialog box to be displayed which contains a field for the search text. The search is managed by the CList class, which performs the comparison between the search text and each CCell instance in the active column. The active column is determined via the m_pCurrentlyEditedCell pointer (which is stored in CList and points to the active cell's CCell instance). The search begins from the top of the list, and stops at the first occurrence of the search text. Thus the most useful result is achieved if the list is sorted. If necessary, the user can search for the next occurrence (in which event the search continues from the active cell) by clicking the 'Find next' button present within the CFindFirstDialog class. The user can tailor the software in several respects and these are accessed from the user's point of view via the preferences pages displayed on selection of the Options command in the Blox menu. These pages are implemented in the CListOptionsSheetTabOne and -Two classes, which are both derived from the MFC CPropertyPage. The CObjectType class contains the version number of the software, and is used to maintain the count of the number of days of use the user has without registering the software. The number of days left is displayed during the loading of the software, and is the responsibility of the CInitDialog class.

When saving the user is prompted to enter summary information on the file (e.g. author/subject). The author field is filled automatically with the name of the person who registered the software (obtained from Window's registration database). The display and entry of the summary information is controlled from within the CSumlnfoDialog class. The user can also load a template rather than an individual file, and the CTemplateDialog class is the means by which the user selects a template to load. To allow both the software and the maintenance programmer to establish what a stream of bytes in the memory represents, Run-Time Type Identification (RTTI) has been implemented wherein the standard C++ data types are encapsulated into classes, all of which are derived from the CRTTIBase base class. These CRTTIBase derived classes (namely CBool, CDouble, CLong, CRTTIDate and CRTTI String) are identical in function except that they also allow RTTI.

Note

Description is now provided of a note object according to the present invention. Once the CPU 10 has been switched on, as mentioned above, the user is presented with options as to which of the various objects it is desired to run.

These are displayed from the toolbar 30 displayed on the monitor 14. A further note object, which can be selected from the toolbar, is now described with reference to Figures 31 and 32. The note object can be employed principally for writing of notes of various forms. Behind this aspect of the present invention lies the recognition that with the exception of dedicated word processor users such as secretaries and typists, most of the "word processing" needs of a computer user can be met without the need for full word processing functionality. The creation of memos, telephone messages, notes, document annotations, reminders and the like constitute a large proportion of the "word processing" work of a typical user. Employing a conventional word processing package for these functions is unwieldy, taking over what might be scarce memory resources and demanding adherence to menu/command protocols which are quite proper for dedicated word processors but are simply overkill for functions of the type that have been mentioned. Referring now to Figures 31 to 33 and initially to a Figure 31, there is shown a preferred note object according to the present invention. A note may be created by a simple drag and drop preparation from the tool bar as previously described with a window 3000 being provided. This window includes a caption bar 3001 and a menu bar 3003. These are analogous to those of the previously described objects and need no further explanation.

A tool bar 3004 is specific to the note object and is shown in more detail in Figure 32. This tool bar has a number of buttons which are shared in common with previously described objects. The use. wherever possible, of common buttons throughout the various objects will directly assist the user. The buttons 3006 and 3007 provide "New", "Open" and "Save" functions. Button 3008 provides access to templates as will be described. Button 3009 provides the "Always on top" function whilst buttons 3010 and 301 1 provide drag and drag-link respectively. Button 3012 provides wide user control over the background colour of the note. Clicking on this button opens a colour window providing a palette of perhaps 48 previously defined colours or shadings. Usefully, a further 12 or so colours are left open for customisation, the colour window having a "Define custom colours" button which allows the user to define a colour through numerical hue, saturation and luminance values; through RGB values or, graphically, by reference to a continuous palette representation.

Button 3013 provides ready access to the "Undo" function usually accessible only via an edit menu. Button 3014 provides a time and date feature allowing - through a simple button click - the insertion of current time and date into a note. Finally, button 3015 provides a "Find" function. Clicking this button opens a dialogue box enabling the user to enter a string of characters to be searched for in a note.

Returning to the window shown in Figure 31, a title region 3016 appears beneath the tool bar. This can be written to directly by the user but, more conveniently, a function is provided within the note object which automatically inserts in the title region, a suitable title from the body of the note. The title is assumed to be the first line of the note up to the first return. Next to the title region 3016 is a stamp 3017 in which is inserted the date and time of creation of the note. This information is automatically recorded. In an option, more detailed summary information can be recorded. If the "Save summary information" option is activated, a summary information dialogue box is brought up each time a note object is saved. This dialogue box contains, in addition to the file name, the title as automatically generated or edited by the user, and the author name which is automatically entered by the system as the current user. This may, again, be overwritten by the user if required. Additional boxes are provided for entry by the user of a subject area, one or more key words, and appropriate comments.

The largest portion of the note window is occupied by the text area 3018 into which free form text can be entered. This text area has scroll controls 3019. Beneath the text area is a status bar 3020 displaying appropriate information about the current task. The note object has full OLE functionality. This means that it can be used as a source object or a destination object for linking and embedding information. The note object can contain other objects within itself. Sections of other objects can also be dragged and dropped into the note object. Further, entries created in the note object can be copied and placed into tables created in other applications. For example, a note can be selected and dragged into a table in Microsoft Word 6 (trade mark). Also, more than one instance of the note object may be open on the display at the same time. Information from one can then be transferred or copied to the other using copy and paste or drag and drop.

Further, the present note object can be activated in-place. so that it can be used whilst using other OLE compliant applications.

A summary of the above described functionality is provided in the flow diagram of Figure 33.

The note object described above may be implemented in many different ways. As just one example, it may be implemented using the Microsoft (trade mark) Foundation Classes. Such an implementation is now described with reference to Table 4.

TABLE 4

Class Super Class Has a: Reference to: Named

CAboutDialog CDialog

CAmendTemplate CDialog

CAttachTemplate CDialog

CNotesApp CWinApp CObjectType m_ptrObj ectTy pe

CNotesContainerltem COleClientltem

CNotesDoc CDBDoc

CNotesServerlte CDBServerltem

CNotesView CEditView CNotesContainerltem m_pSelection CNotesSet m_pSet

CDBDoc COleServerDoc

CDBServerltem COIeServerltem

CIconExt CObject

CInPlaceFrame COlelPFrameWnd CNoteBar rn_wndDialogBar CIPToolBar m wndToolBar

CIPToolBar CMyToolBar

CMainFrame CFrameWnd CNoteBar m_wndDialogBar CMyToolBar m wndToolBar

CMyToolBar CToolBar

CNote CPropertyPage

C oteBar CDialogBar

CObjectType

CSaveTemplate CDialog

CSumlnfo CDialog

CTemplateDialog CDialog CToolBar m ToolBar

CTemplateOptions CPropertyPage

CToolDialog CDialog

CToolOpts CDialog The class CNotesApp is important as for all Windows applications, and is a derived class from the MFC class CWinApp, which performs initialisation on program entry, and a cleanup on program exit in addition to managing the program as a whole during its execution. Each Windows application creates exactly one instance of the CWinApp class.

The note application is able to act as both an OLE container (where objects are dropped into it) and as a server (where a note is itself dropped into another application). The former is provided by the CNotesContainerltem class of which a new instance is created whenever an object is dropped from another application into the client area (which is managed by the CNotesView class). The

CNotesContainerltem class contains the information required by the note software to display the object (the presentation data), and also data to manipulate the object (the native data). Also included is a reference to the server such that it can be located if necessary (e.g. in the event that the user double clicks the object to activate in-place editing).

When acting as an OLE server, the software utilises the CNotesServerltem and CDBDoc classes. The CNotesServerltem class is derived indirectly from the COleServerltem class (a Microsoft Foundation Class) via the CDBServerltem class. During the embedding procedure, a conversion takes place between the internal format of the note software and a format suitable for embedding (e.g. a Windows metafile). This conversion is the responsibility of the CNotesServerltem class, as is the storage of the presentation data once converted. The presentation data allows the object to be displayed without activating its host application. There is one instance of the CNotesServerltem class for each note object which is embedded in an external OLE container and the CDBDoc class consists of a list of all said OLE objects.

In order to act as an OLE server, the note application must derive its document class (CNotesDoc) from COleServerDoc rather than CDocument. This takes place indirectly via the CDBDoc class. The CNotesDoc class is used in the transferral of data between the note software and the backing store (e.g. hard disc drive).

Rather than embed a note object, the user can opt to create a link to a file on disc. In this case only a reference to the file is stored in the container application; to obtain the presentation data the application must read the data file. This results in a smaller file size for the container, and more efficient storage of data if the same object is embedded in several independent containers. However, the retrieval of the object will be slightly slower due to the extra slow step of retrieving the object's presentation data from disc. The note software also supports in-place (IP) editing, wherein the note object can be edited with no need for the user to switch applications. This is possible since the note software has the ability to run from within an OLE container application. To activate IP editing, the user double clicks on the object in the containing application. The object's native code is invoked which initializes the note application. Under normal circumstances the window surrounding the note application, the title bar, the toolbar, the note dialogue bar, and the minimise/maximise buttons are rendered by the CMainFrame class. The operation of the program is identical when executing in place, except that the responsibilities of the CMainFrame class are transferred to the CInPlaceFrame class. This class draws only the window frame, the toolbar, and the note dialog bar. Both the CMainFrame and CInPlaceFrame classes contain an identical instance of the CNoteBar class which is responsible for the construction and display of the note dialog bar. This bar contains the title of the current note, along with the date that it was last edited. The toolbar however, is implemented by two separate classes. The CIPToolBar class (derived from CMyToolBar and contained within

CInPlaceFrame) renders the toolbar when the note software is running in-place (i.e. is embedded in another application), whereas it is rendered by CMyToolBar (derived from CToolBar and contained within CMainFrame) under normal circumstances. Two classes are necessary due to the differences present between the two toolbar displays.

CNotesView inherits the data members and member functions of the MFC class CEditView which itself is derived from the MFC CView. CNotesView is therefore responsible for the client area, providing the basic word processing functions such as text entry, deletion and scrolling as well as rendering the display. In order that any embedded objects will scroll with the text, the default OLE container code for displaying an embedded object (contained within the CEditView class) is replaced with code that displays any objects in a position relative to the note windows rather than the note text. CNotesView handles the display of the data, whether the application is running in-place or normally. The use of the CEditView class to provide text editing for a note taking function is not unique to this invention; what is unique is the creation of a note object which (in this instance through the properties of the COleClientltem and COleServerDoc classes) is capable of being embedded into or linked with other applications and which is able to receive other objects as a container. This combination produces an object which is simple in software terms yet extremely powerful, offering the user immense flexibility in his ways of working. It is a straightforward matter, for example, to embed (or link) notes in individual cells of a list provided in accordance with a different aspect of this invention. Notes can be embedded at appropriate locations in a word processing document (provided for example by Microsoft Word (trade mark). A particularly useful feature can be provided by making use of the WINDOWS 95 short cut feature. If a note is embedded at a critical passage in a word processing document and a short cut is then established to that note, activating the short cut on the desk top will open the word processing document and display it suitably positioned to show the critical passage. A short cut is typically established using the right mouse button to copy the note and then paste it to the desktop using the special "paste short cut" command.

Another unique feature of the note aspect of the present invention is the manner in which the user is given control over the colour and font of the text editing area. This provides opportunities for distinguishing between notes of different categories in a simple eye-catching fashion and also allows the note object to be identified immediately in a container application.

Several features exist which save the user time in setting up and maintaining a collection of notes. To avoid retyping the same basic format for a note, the user can select a template wherein basic text and layout is stored. This is the function of button 3008, mentioned previously. Thus, when loaded, the user is presented with a semi-complete note into which the only text which changes from one note to another need be typed. The creation and selection of templates are handled by the CSaveTemplate and CTemplateDialog classes respectively. Both of these classes are responsible for displaying and managing dialog boxes. At the software level a template file is essentially the same as a conventional note file. The only difference is the way in which the saving of a note generated from a template is saved. If the user opens a normal note file, makes some modifications, and then selects save, the modified note will overwrite the previous version. If however a template file is loaded and text entered into the note, upon selecting save the user will be prompted for a new note filename. Therefore, a template file cannot be overwritten inadvertently. The note software automatically derives the title from the text input by the user by assuming that the first line of the note constitutes the title. The dialog bar (rendered by the CNoteBar class) contains an edit box which is filled with the title, in addition to the date and time of the note's last edit. As the user types, the CNotesView class extracts the first line of the text (i.e. all characters up to but not including the carriage retum) and passes it to the CNoteBar class which updates the display of the title. There is a data member within CNoteBar which contains the title. In the event that the first line of the note is not the title, the user can click on the edit box in the dialog bar and enter a different title. The new title becomes independent of the first line of the note and future alterations thereto. Ingeniously, this title is taken as the default file name if the note is to be saved. This frees the use from the need consciously to develop new file names. In many cases, however, the file name will not need to be employed explicitly since a note can remain on the desktop for the period of time during which it is to be referred to. To allow notes to be distinguished easily, an option is available which causes the note software to prompt the user for 'summary' information about the file (e.g. author, subject). The software aids the user by automatically completing several of the fields. A filename for the note is derived from its title, and the author of the note is also established without input from the user. To achieve the latter the software looks up the name of the person who purchased the software, in the registration database. The entry of the summary information takes place in the dialog box generated by the CSumlnfo class.

During the saving of the note, the note software requests the current system time and date from the operating system. This is then encoded into the note file and becomes the date/time of the last edit. There are date members within the CNoteBar class which hold said date and time.

The note software is extensively configurable. The general configuration options are coordinated by the CNote class (derived from the MFC CPropertyPage), the toolbar options by the CToolDialog/CToolOpts classes and the template options by the CTemplateOptions class.

The CObjectType class is responsible for recording how many days the software has been used for, in order that unregistered use is limited. The CAboutDialog displays the about box which gives details on the entity to which the software is registered.

Work

Description is now provided of a work object according to the present invention. Once the CPU 10 has been switched on, as mentioned above, the user is presented with options as to which of the various objects it is desired to run. These are displayed from the toolbar 30 displayed on the monitor 14. A further work object, which can be selected from the toolbar, is now described with reference to Figures 34 and 35. The list object can be employed principally for organising work files.

It has been explained that one aspect of the present invention provides an elegant and powerful graphical approach to the organisation and retrieval of files. A specific example will now be described with particular reference to Figure 34 which shows a typical screen display and to Table 5 which lists the principal classes employed together with - in each case - the MFC class whose properties they inherit and, as appropriate, references to other classes.

TABLE 5

Class Super Class Has a. Reference to. Named

CAddTab CDialog

CDes App CWinApp CNoteBkCfgDoc m_CfgDoc

CDeskContainerltem COIeClientlte

CDeskDoc COIeLinkingDoc CTabData m_pTab

CDeskView CScrollView COIeDropTarget m_dropTarget

CDeskContainerltem m_pSelectιon

CCustMin CDialog

CDeskWnd CWnd CMyOleDropTarget m_dropTarget

CTabData m_pActιveLevel CTabData m_pEdιtTab CTabData m_pTabRoot CDeskView m_pTabVιew

CDirList CListBox

CDπveCombo CComboBox CLayout CObject

CMainFrame CFrameWnd CStatusBar m_wndStatusBar CToolBar m_wndToolBar

CDeskWnd m_pwπdDesktop

CMyOleDropTarget COIeDropTarget CTabData m_pLockedLevel

CNoteBkCfgDoc CObject

CPrefl CPropertyPage

CPreΩ CPropertyPage

CPreβ CPropertyPage

CPrefs CPropertySheet CPrefl m_Page 1 CPreΩ m_Page2 CPreO m_Page3

CSearchDialog CDialog CDirList m_DirLιst CDπveCombo m_DπveCombo

CSubStyle CDialog

CSumlnfo CDialog

CTabAdvanced CDialog

CTabData CObject CTabData m_pParentTab

CTabDir CObject The arrangement is provided by which directories are related one-to-one with main or top-level tabs such as those indicated in Figure 34 at 4000. The procedure for creating a new main tab will default to creating a new directory, the name of the directory being derived from the name of the main tab. The user has the option of calling up an existing directory, which he may have created previously under a different application or which may "belong to" another user or group of users. All security and access controls are of course available from the existing directory handling procedures in the operating system.

A configuration file (having in this example the extension .WTX) keeps track of what directories are pointed to by the various main tabs. The configuration file also contains information defining the overall look of the window.

Relevant files in the directory are distinguished through use of a common extension (in this example .WBX). These are compound document files and correspond with the relevant sub-tabs, taking the sub-tab name. The compound document file Toplevel.WBX is provided as the home for objects in a main tab for which no sub-tabs have been defined. The "naming" relationship between files and sub-tabs is symmetrical in that changing of the sub-tab name by the user results in an automatic change of name of the file whilst (though perhaps less usual) changing the file name through an appropriate file handling routine, will automatically result in a change of name of the sub-tabs.

These automatic naming arrangements make it possible for the user effectively to "forget" about the names of files and directories. Organisation and retrieval of files can be handled graphically with the user confident that an object assigned graphically to a particular tab can always be accessed through that tab with no conscious thought being given to path names in either storage or retrieval of the object.

Each compound document file (.WBX), with the exception of the special file Toplevel.WBX, corresponds with a sub-tab depicted as a page on the screen display as shown at 4010 in Figure 34. The ability is provided to scroll to parts of the page not currently visible and - advantageously - an option is provided from the tool bar of displaying the entire page, scaled to fit the window.

Since each sub-tab page corresponds with a compound document, objects can be embedded in the sub-tab or linked to the sub-tab using the object drag and drop routines provided in OLE. The default is preferably set to object linking (rather than embedding) to avoid unnecessary duplication of stored data. Embedded or linked objects can be displayed as icons and examples of this are shown in Figure 34 at 4020 and 4030 respectively. Note that a linked object is distinguishable through the dotted line border. Objects can of course also be displayed in full as in-place objects. A paπicularly preferred form of the present invention, however, provides an ingenious altemative by which objects can be displayed as miniaturized versions of the object content. In terms of providing a workable display when more than just a handful of objects are to be displayed, this miniaturization approach has most of the advantages of iconic display. The principal disadvantage of icons is removed however since a context-specific display is produced enabling (in most cases) the user to identify which object is required even where there are many objects having a common icon form.

Miniature display of objects is achieved through scaling of the metafile. Scaling is automatic but the nature and degree of scaling is under user control through appropriate dialog boxes. The user may, for example, choose relative scaling selecting the actual ratio (say 10%) through which the metafile is scaled. An altemative, which may be useful is some applications, enabling tiie user to define the size of the miniature in absolute terms (such as number of pixels) with scaling routine selecting the appropriate scaling ratio depending upon the size of the metafile.

A brief description will now be given of the manner in which the above described procedures are implemented in a specific example. Referring to Table workzl (see above), there are shown the classes employed. Under the heading "Super Class" are shown the classes whose properties are inherited. In the case of the "work" software, these are all Microsoft Foundation Classes.

CDeskApp, which inherits the properties of the MFC CWinApp handles initialization of the program (e.g. setting of defaults) and the exit cleanup (e.g. closing all files, and freeing allocated memory). It has, as a data member, an instance of the class CNoteBookCfgDoc which is an object specifically adapted to handle the configuration of the tabs. During program initialisation, the CDeskApp class reads the directory corresponding with the "on-top" main tab and creates automatically instances of the CTabData class for each .WBX file in the directory. The CTabData class holds the attributes (e.g. colour/font) of the each of the sub- tabs, and consequently each .WBX file contains the necessary information on the look of its associated sub-tab. A reference is provided between instances of CTabData which identifies for each tab its parent tab, except in the event that the tab is itself the top-level tab, in which case the pointer contains NULL. A directory of top level tabs is provided by the CTabDir class.

The user adds tabs by means of a dialog box rendered by the CAddTab class. This class accommodates for the addition of both top-level and sub- level tabs and prompts the user for the various formatting options available. Advanced options are configured by the dialog box displayed by the CTabAdvanced class. General program preferences can be edited via the CPrefl, CPref2, CPref3 and CPrefs classes.

The CMainFrame class (which is derived from the MFC CFrameWnd) is responsible for drawing the window surrounding the "work" application, in addition to the status and tool bars (which are rendered by CStatusBar and CToolBar respectively under the control of CMainFrame).

The display of the tabs is undertaken by the CDeskWnd and CDeskView classes. The former draws (and controls the selection of) the tab and its associated background, and the latter creates the window in which the OLE objects for the tab are displayed (the tab page). CDeskView is derived from the CScrollView class which allows the tab page to be scrolled in the event that the entire page is too large to be viewed as a whole. This is in preference to the CView class which does not support this feature. It also contains an instance of the COIeDropTarget class which provides the tab page with its ability to receive and manipulate objects which have been dropped on to it. For each object that is dropped, an instance of the

CDeskContainerltem class (derived from COleClient Item) is created which contains the data members and member functions necessary for the display of the object. When an OLE object is selected, the responsibility of its display is transferred from the CDeskContainerltem class to the CDeskView class, and thus the CDeskView class also contains a pointer to the relevant instance of the CDeskContainerltem class. The CDeskView class accommodates the moving, sizing, and dragging from tab to tab of selected objects.

The CDeskWnd class is derived from the MFC CWnd. This class contains three pointers to instances of CTabData classes. The first two pointers reference the active level of the tabs (i.e. the top level or second level tabs), and the tab currently being viewed/edited. The third is a "Tab Root" reference to an object in the CTabData class which serves as a place holder for the top level tab on the desktop. It also contains a pointer to the CDeskView class, which is used during the passing of infoπnation (e.g. display co-ordinates where the tab page is to be displayed).

The CDeskWnd class is also involved during drag and drop operations. It is possible for the user to drop an OLE object on to a tab which is cuπently not active (i.e. for which the tab page is not visible). This is achieved by dragging the object over the tab's selection button (which is the responsibility of CDeskWnd), whereupon the software causes the relevant tab page to be made visible. The CDeskWnd class contains an instance of the CMyOleDropTarget class which is derived from the COIeDropTarget class. Various member functions of the COIeDropTarget class are oveπidden in the CMyOleDropTarget class so that its behaviour is modified. The ability of COIeDropTarget to initiate the embedding of an object is removed, and the member function responsible for updating the cursor (to indicate that it is over a valid OLE container) is intercepted. Instead of only performing this action, the member function determines the tab button over which the cursor is positioned and makes it active. CDeskDoc is derived from the COleLinkingDoc class, providing a single document interface (SDI) wrapper for compound documents in addition to the functionality of a linking container (i.e. the ability for the document to receive a linked object as well as an embedded one). The SDI implies that only one compound document can be open at any one time. The CDeskDoc class also controls the loading and saving of compound documents under the name of their coπesponding sub-tabs. A reference is provided to a CTabData object, so that the compound document can, as mentioned, control the font, colour and other aspects of the look of the sub-tab. A dialog box CSubStyle is conveniently provided to enable the user to control the colour and font of sub-tabs. When the user opts to open a previous set of tabs, browsing of directories is made available through CDirList whilst choice of drives is provided through CDriveCombo. This is controlled through the dialog box CSearchDialog (which contains instances of the above two classes). Searching for a set of tabs is assisted by the provision for summary information (e.g. author/subject) to be stored with each file. This information is requested when the tab file is created initially, and the dialog box is rendered by the CSumlnfo class.

To aid the user in maintaining a visually clear organisation, an auto-aπange feature is provided which, within a compound document, can provide for automatic organisation of objects in a manner analogous to the automatic aπanging of icons in previously known window approaches. This auto-arranging is controlled through a dialogue box CLayout as is the generation of place holders around each object.

A further dialog box CCustMin assists the user in customizing the miniaturization routines described previously. A summary of the functionality of the work object is provided in the flow diagram of Figure 35.

It will be understood that the present invention has been described above purely by way of example, and modifications of detail can be made within the scope of the invention. Each feature disclosed in the description, and (where appropriate) the claims and drawings may be provided independently or in any appropriate combination.

Claims

1. Computer software having :- a) a specific business related application; b) less than 500 kbytes of executable code; c) the ability to generate an object which can be embedded and linked, which has drag-and-drop capability, and which can be edited in-place; d) the ability to act both as a container and a server.

2. Computer software according to Claim 1 , having less than 400, preferably less than 300, kbytes of executable code.

3. Computer software according to Claim 1 or 2. having the ability to generate an object, and individual data items contained within that object can be dragged and dropped.

4. Computer software according to Claim 1, 2 or 3, having the ability to generate an object in template form.

5. Computer software according to any of the preceding claims, having the ability to generate an object which, as a default, takes up less than the full amount of available space on the display of a display means.

6. A suite of computer software according to any of the preceding claims.

7. A computer when programmed with computer software according to any of Claims 1 to 5 or a software suite according to Claim 6.

8. Use of a computer according to Claim 7.

9. Processing apparatus, comprising: input means for receiving command signals; processing means for generating a toolbar signal for displaying a representation of a toolbar on a display means and an object signal for a representation of a computer object on the toolbar, the toolbar and object signals being generated in such a way that, in response to a given drag and drop command signal from the input means, the object representation would appear on the display means to be dragged from the toolbar and dropped at a specified location; and output means for outputting the toolbar and object signals to the display means.

10. Apparatus according to Claim 9, wherein the processing means is adapted to create the object in response to the object representation being dragged and dropped from the toolbar representation.

1 1. Apparatus according to Claim 9 or 10. wherein the object representation when on the toolbar representation is iconic, and remains iconic when the representation has been dragged from the toolbar representation.

12. Apparatus according to Claim 9 or 10, wherein the object representation when on the toolbar is iconic, but changes to the appearance of the in-place object when it has been dragged and dropped off the toolbar representation.

13. Apparatus according to any of Claims 9 to 12, wherein the processing means is adapted to generate the toolbar signal such that the toolbar representation would appear on the display means to be on top of any other active window.

14. Apparatus according to any of Claims 9 to 13, wherein the processing means is adapted, in response to a command signal from the input means which would have the appearance on the display means of dragging and dropping a representation of a computer application onto the toolbar representation, to load the computer application onto the toolbar.

15. Apparatus according to any of Claims 9 to 14. wherein the processing means is adapted, in response to a command signal from the input means, to create a selected object with a given template.

16. Processing method, comprising: receiving command signals; generating a toolbar signal for displaying a representation of a toolbar on a display means and an object signal for displaying a representation of a computer object on the toolbar, the toolbar and object signals being generated in such a way that, in response to a given drag and drop command signal, the object representation would appear on the display means to be dragged from the toolbar and dropped at a specified location; and outputting the toolbar and object signals to the display means.

17. A method according to Claim 16, wherein the object is created in response to the object representation is being dragged and dropped from the toolbar representation.

18. A method according to Claim 16 or 17, wherein the object representation when on the toolbar representation is iconic, and remains iconic when the representation has been dragged from the toolbar representation.

19. A method according to Claim 16 or 17, wherein the object representation when on the toolbar is iconic, but changes to the appearance of the in-place object when it has been dragged and dropped off the toolbar representation.

20. A method according to any of Claims 16 to 19, wherein the toolbar signal is such that the toolbar representation would appear on the display means to be on top of any other active window.

21. A method according to any of Claims 16 to 20, wherein, in response to a command signal which would have the appearance on the display means of dragging and dropping a representation of a computer application onto the toolbar representation, the computer application is loaded onto the toolbar.

22. A method according to any of Claims 16 to 21 , wherein. in response to a command signal, a selected object is created with a given template.

23. Processing apparatus substantially as herein described with reference to and as illustrated in Figures 4 to 1 1 of the accompanying drawings.

24. Processing method substantially as herein described with reference to Figures 4 to 1 1 of the accompanying drawings.

25. Processing apparatus comprising: means for generating on a display means a representation of a keypad; input means for entering by reference to said keypad representation operands and operators in discrete data entry elements; computational means for deriving results from the data entry elements; storage means for storing a list of previously entered elements with coπesponding results; and means for generating on said display a representation of said list.

26. Apparatus according to Claim 25, wherein the input means further comprises means for editing the elements with reference to said representation of said list, with said computational means serving to update said results in response to said editing.

27. Apparatus according to Claim 25 or 26, wherein each data entry element includes a label for referencing said element.

28. Apparatus according to Claim 27, further comprising processing means for assigning to each label a value representative of the data entry element, and wherein a selected label can be entered by the input means as an operand.

29. Apparatus according to any of Claims 25 to 28, wherein the list is in row and column format, and has as a default, before any data entry elements have been entered, less than twenty, preferably less than ten, preferably less than seven, rows and columns.

30. Apparatus according to Claim 29, wherein the list representation generating means is adapted to increase the size of the list in accordance with the number of data entry elements.

31. Apparatus according to any of Claims 25 to 30, further comprising means for locking a selected data entry element or a selected portion thereof.

32. Apparatus according to any of Claims 25 to 31, wherein, in response to user input entered via the input means, the keypad representation generating means is adapted to generate on said display means a representation of at least one altemative keypad.

33. Apparatus according to any of Claims 25 to 32, wherein the computational means comprises means for backsolving an expression.

34. Apparatus according to Claim 33, wherein the computational means further comprises means for deriving from the expression an expression tree, the backsolving means being adapted to backsolve using the expression tree derived by the deriving means.

35. Processing method comprising: generating on a display means a representation of a keypad; entering by reference to said keypad representation operands and operators in discrete data entry elements; deriving results from the data entry elements; storing a list of previously entered elements with coπesponding results; and generating on said display a representation of said list.

36. A method according to Claim 35, wherein the elements are edited with reference to said representation of said list, said results being updated in response to said editing.

37. A method according to Claim 35 or 36, wherein each data entry element includes a label for referencing said element.

38. A method according to Claim 37, wherein a value is assigned to each label representative of the data entry element, and wherein a selected label can be entered as an operand.

39. A method according to any of Claims 35 to 38, wherein the list is in row and column format, and has as a default, before any data entry elements have been entered, less than twenty, preferably less than ten. preferably less than seven, rows and columns.

40. A method according to Claim 39, wherein the size of the list is increased in accordance with the number of data entry elements.

41. A method according to any of Claims 35 to 40, wherein a selected data entry element or a selected portion thereof is locked.

42. A method according to any of Claims 35 to 41, wherein, in response to user input, a representation of at least one altemative keypad is generated on said display means.

43. A method according to any of Claims 35 to 42, wherein the results deriving step comprises the step of backsolving an expression.

44. A method according to Claim 43, wherein the results deriving step further comprises the step of deriving from the expression an expression tree, the backsolving using such expression tree.

45. Processing apparatus substantially as herein described with reference to and as illustrated in Figures 12 to 22 of the accompanying drawings.

46. Processing method substantially as herein described with reference to Figures 12 to 22 of the accompanying drawings.

47. Processing apparatus, comprising: input means for receiving data in the form of input signals; processing means for aπanging the data into row and column format and generating output signals based on the arranged data, and for generating a respective action symbol signal, for each row or column of data, which can cause a respective action symbol to be displayed on a display means in conjunction with each row or column, the processing means being such that the symbol for a particular row or column can be selected via the input means and such that selection of that symbol causes a specified action to be performed on the particular row or column; and output means for outputting the output signals and action symbol signals to the display means.

48. Apparatus according to Claim 47, wherein the processing means is adapted to generate an action bar signal so that the action symbols can be displayed on the display means in an action bar.

49. Apparatus according to Claim 47 or 48 wherein the specified action is a sorting action, for sorting the order of the cells in the particular row or column.

50. Apparatus according to any of Claims 47 to 49, wherein the specified action is a filtering action, for selectively filtering the cells in the particular row or column.

51. Apparatus according to any of Claims 47 to 50, wherein the specified action is a searching action.

52. Apparatus according to any of Claims 47 to 51, further including storage means for storing a representation of the aπanged data on which the specified action has been performed.

53. Apparatus according to any of Claims 47 to 52, wherein the data for the particular row or column comprises a visual, non-textual data type.

54. Apparatus according to any of Claims 47 to 53, wherein the processing means as a default is adapted to aπange the data into no more than ten rows and ten columns.

55. Processing apparatus, comprising: input means for receiving data in the form of input signals; processing means for arranging the data into row and column format and generating from the aπanged data output signals, the processing means as a default arranging the data into no more than ten rows and ten columns; and output means for outputting the output signals to a display means to generate a visual display of the data in row and column format.

56. Apparatus according to Claim 54 or 55, wherein the processing means is adapted, on receipt of a given command input via the input means, to increase the number of rows or columns.

57. Apparatus according to Claim 56, wherein the given command is a drag and drop command.

58. Apparatus according to any of Claims 47 to 57, further comprising storage means in which is stored at least one template into which the data can be aπanged.

59. Apparatus according to any of Claims 47 to 58, wherein the processing means is adapted to permit embedding of a computer object only within an individual cell defined by the row and column format.

60. Processing method, comprising: receiving data in the form of input signals; aπanging the data into row and column format and generating output signals based on the aπanged data, and generating a respective action symbol signal, for each row or column of data, which can cause a respective action symbol to be displayed on a display means in conjunction with each row or column, such that the symbol for a particular row or column can be selected and such that selection of that symbol causes a specified action to be performed on the particular row or column; and outputting the output signals and action symbol signals to the display means.

61. A method according to Claim 60. wherein an action bar signal is generated so that the action symbols can be displayed on the display means in an action bar.

62. A method according to Claim 60 or 61 , wherein the specified action is a sorting action, for sorting the order of the cells in the particular row or column.

63. A method according to any of Claims 60 to 62, wherein the specified action is a filtering action, for selectively filtering the cells in the particular row or column.

64. A method according to any of Claims 60 to 63, wherein the specified action is a searching action.

65. A method according to any of Claims 60 to 64, wherein a representation is stored of the arranged data on which the specified action has been performed.

66. A method according to any of Claims 60 to 65, wherein the data for the particular row or column comprises a visual, non-textual data type.

67. A method according to any of Claims 60 to 66, wherein as a default the data is adapted into no more than ten rows and ten columns.

68. Processing method, comprising: receiving data in the form of input signals; arranging the data into row and column format and generating from the aπanged data output signals, as a default the data being aπanged into no more than ten rows and ten columns; and outputting the output signals to a display means to generate a visual display of the data in row and column format.

69. A method according to Claim 67 or 68, wherein, on receipt of a given command, the number of rows or columns is increased.

70. A method according to Claim 69, wherein the given command is a drag and drop command.

71. A method according to any of Claims 60 to 70, wherein at least one template is stored into which the data can be arranged.

72. A method according to any of Claims 60 to 71 , wherein embedding of a computer object is permitted only within an individual cell defined by the row and column format.

73. Processing apparatus substantially as herein described with reference to and as illustrated in Figures 23 to 30 of the accompanying drawings.

74. Processing method substantially as herein described with reference to Figures 23 to 30 of the accompanying drawings.

75. Processing apparatus, comprising: input means for receiving textual data in the form of input signals; processing means for generating output signals representative of a visual metaphor of a note, with the textual data appearing as at least one line of text on the note, and for generating a default file name in dependence on the text in the note; and output means for outputting the output signals to a display means.

76. Apparatus according to Claim 75, wherein the processing means is adapted to generate the default file name in dependence on a predetermined portion of the text, beginning with the first character of text.

77. Apparatus according to Claim 75 or 76, wherein the processing means is adapted to generate a title for the note in dependence on the text in the note.

78. Processing apparatus comprising a display; means for generating a user editable text area on said display; means for generating a storable file representative of user edited text and means for generating automatically a default file name for said file from user entered text.

79. Apparatus according to Claim 78, wherein said means for generating automatically a default file name operates to select an initial character string from said user edited text.

80. Processing apparatus comprising a display; and means for generating a user editable text area on said display; wherein said text area is represented by a data processing element which is both a server and a container of objects.

81. Processing method, comprising: receiving textual data in the form of input signals; generating output signals representative of a visual metaphor of a note, with the textual data appearing as at least one line of text on the note, and generating a default file name in dependence on the text in the note; and outputting the output signals to a display means.

82. Processing apparatus substantially as herein described with reference to and as illustrated in Figures 31 to 33 of the accompanying drawings.

83. Processing method substantially as herein described with reference to Figures 31 to 33 of the accompanying drawings.

84. Processing apparatus, comprising: file storage means arranged into directories which may be local or remote: and processor means and a plurality of objects held in the file storage means. each object being accessible through user actuation of a representation thereof in a display means; wherein said objects can be aπanged by the user into main classes and within each main class into sub-classes, each sub-class of one or more objects having associated therewith a compound document with its file stored in a directory of the file storage means, said compound document having the or each object of the coπesponding sub-class embedded therein or linked therewith, and all the compound document files coπesponding respectively with sub-classes of a main class being stored within a common directory in the file storage means unique to that main class.

85. Apparatus according to Claim 84 wherein there is provided means for generating on said display a hierarchical tab representation of main classes and sub¬ classes with each class being selectable through user actuation of a coπesponding tab representation in the display, main and sub-class tabs being hierarchical.

86. Apparatus according to Claim 84 or 85. which is adapted, on user selection of a particular sub-class tab. to provide a display representation of the compound document coπesponding thereto.

87. Processing method, comprising: providing file storage means arranged into directories which may be local or remote; and providing processor means and a plurality of objects held in the file storage means, each object being accessible through user actuation of a representation thereof in a display means; wherein said objects are aπanged by the user into main classes and within each main class into sub-classes, each sub-class of one or more objects having associated therewith a compound document with its file stored in a directory of the file storage means, said compound document having the or each object of the coπesponding sub-class embedded therein or linked therewith, and all the compound document files coπesponding respectively with sub-classes of a main class being stored within a common directory in the file storage means unique to that main class.

88. A method according to Claim 87 wherein a hierarchical tab representation of main classes and sub-classes is generated on the display means with each class being selectable through user actuation of a coπesponding tab representation in the display means, main and sub-class tabs being hierarchical.

89. A method according to Claim 87 or 88, wherein, on user selection of a particular sub-class tab, a display representation of the compound document coπesponding thereto is provided.

90. Processing apparatus substantially as herein described with reference to and as illustrated in Figures 34 to 35 of the accompanying drawings.

91. Processing method substantially as herein described with reference to Figures 34 to 35 of the accompanying drawings.