WO2002041140A2

WO2002041140A2 - Graphical user interface enabling entry of non trivial parameters

Info

Publication number: WO2002041140A2
Application number: PCT/IB2000/001702
Authority: WO
Inventors: Stephen P. Kruger
Original assignee: Sun Microsystems, Inc.
Priority date: 2000-11-17
Filing date: 2000-11-17
Publication date: 2002-05-23
Also published as: AU2001212925A1; WO2002041140A3

Abstract

The invention is applied in a computer system with a user interface. In this computer system, an object-oriented software environment proposes to create and process software objects. For this use, a software code presents a clipboard through the user interface, for possible use in creating further objects.

Description

Graphical user interface enabling entry of non trivial parameters

This invention relates to computer technology, more particularly to the interaction of computer software with user interfaces.

Many advantages are found in providing computers systems with a graphical environment or graphical user interface (GUI).

On another hand, the object-oriented software approach is in fast expansion, in view of its numerous advantages. One of these advantages is the ability to deal with complex objects, i.e. to process items each comprising a specific set of various data related to the item being considered.

Now, inputting values for the various data components into a a complex object is not easy, unless a specific user entry form has been designed. On another hand, it is often impractical to write such a user entry form, e.g. where the object will likely be created only once, as it will be discussed hereinafter in more detail, or when the object structure is not known at the time of writing or designing the input form.

A general aim of the present invention is to bring a solution to this problem.

In accordance with an aspect of this invention, there is proposed a computer system, comprising: - a user interface, - an object-oriented software environment adapted to create and process software objects, and - software code capable of presenting object related data through the user interface, for possible use in creating further objects.

In accordance with another aspect of this invention, there is proposed a method of creating objects in an object-oriented software environment, having a repository, adapted for storage of existing objects, comprising the steps of: a. Determining whether an object to be created has a non- default constructor, having parameters, b. Checking the repository for objects compatible with the parameter when the object has a non-default constructor. c. When the repository has compatible objects: cl. Displaying such compatible objects for the user to select amongst such compatible objects, c2. Creating the object with the non-default constructor, with one or more selected objects as parameters.

This invention also encompasses the software code as defined in the above defined computer system, and/or the software code for at least partially performing the steps in the above method. It also encompasses an object-oriented software environment, comprising such software code.

This invention further defines a graphical user interface, having a desktop area, a clipboard area, objects presented in said clipboard area, and an object creation section, said objects presented in the clipboard area being movable to serve as parameters in the object creation section.

Other alternative features and advantages of the invention will appear in the detailed description below and in the appended drawings, in which :

- figure 1 is a general diagram of a computer system in which the invention is applicable; - figure 2 is a general diagram of an object-oriented software environment in a distributed computer system;

- figure 3 is a flow chart showing the creation of objects in accordance with the prior art;

- figure 4 schematically shows a screen for use in implementing the invention;

- figure 5 shows a class browser window in the screen of figure 4;

- figure 6 shows a first form of a "Create Object" window applicable in the screen of figure 4;

- figure 7 shows a second form of the "Create Object" window;

- figure 8 shows a third form of the "Create Object" window;

- figure 9 is a flow chart of the "Create object" window software;

- figure 10 is a flow chart detailing the input field display step 610 of the software of figure 9;

- figure 11 is a flow chart detailing the "scan clipboard" step 620 of the software of figure 10;

- figure 12 shows a fourth form of the "Create Object" window;

- figure 13 is a flow chart detailing the response to actuation of a special button by the user at step 610 of figure 9;

- figure 14 shows a fifth form of the "Create Object" window; - figure 15 shows an object browser window in the screen of figure 4;

- figure 16 shows a sixth form of the "Create Object" window;

- figure 17 is a more general flow chart of the object creation in accordance with this invention; and

- figure 18 is a flow chart illustrating the storage of created objects in a clipboard.

As they may be cited in this specification, Sun, Sun Microsystems, Solaris, Java, EmbeddedJava, PersonalJava, Java- Beans, Java Naming and Directory Interface, JDBC (Java Data Base Connectivity), Enterprise JavaBeans, Jini, Java Workshop, BeanBox, and Sun Spontaneous Management are trademarks of Sun Microsystems, Inc. SPARC is a trademark of SPARC International, Inc.

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright and/or author's rights whatsoever.

This specification is supplemented with an Exhibit 1, showing examples of code showing an object structure with its members and its creation.

Now, making reference to software entities imposes certain conventions in notation. For example, in the detailed description, the quote sign " and/or Italics may be used when deemed necessary for clarity, e.g. to distinguish between a basic object and another object having the same name. For example, an address book may be represented by an "Address- Book" object.

However, in code examples: ) - quote signs are used only when required in accordance with the rules of writing code, i.e. for string values.

- a name followed with [] indicates an array.

- also, <attribute> may be used to designate a value for the attribute "attribute" (or attribute) .

The dot notation is used as necessary for clarity. For example: AddressBook. getEntries f ) means the operation getEntries ( ) applied to the AddressBook object.

This invention may be implemented in a computer system, or in a network comprising computer systems. The hardware of such a computer system is for example as shown in Fig. 1, where:

- 11 is a processor, e.g. an Ultra-Sparc;

- 12 is a program memory, e.g. an EPROM for BIOS; 0 - 13 is a working memory, e.g. a RAM of any suitable technology (SDRAM for example);

- 14 is a mass memory, e.g. one or more hard disks;

- 15 is a display, e.g. a monitor;

- 16 is a user input device, e.g. a keyboard and/or mouse; 5 and

- 21 is a network interface device connected to a communication medium 20, itself in communication with other computers. Network interface device 21 may be an Ethernet device, a serial line device, or an ATM device, inter alia. Medium 20 0 may be based on wire cables, fiber optics, or radio-communications, for example.

Data may be exchanged between the components of Figure 1 through a bus system 10, schematically shown as a single bus 5 for simplification of the drawing. As is known, bus systems may often include a processor bus, e.g. of the PCI type, connected via appropriate bridges to e.g. an ISA bus and/or an SCSI bus.

Figure 2 shows a simple distributed environment, in the example of two machines Ml and M2 , interconnected by a link 20, e.g. a network medium. The invention may also apply within a single machine. The machines may have the exemplary structure of figure 1, or any equivalent structure. In figure 2, the CPU and hardware of figure 1 is diagrammatically shown as 1M1 and 1M2. In the drawing, the blocks showing the same functions are identified by the same reference number, immediately followed by the machine identifier, which may be omitted in this description. Each computer system also has an operating system 3, e.g. Solaris. Operating systems other than Solaris may be used in accordance with the invention. An object supporting software 4 may be installed over operating system 3.

The object supporting software 4 may e.g. include the necessary software to build a Java virtual machine or JVM. It includes an object processor or object provider 41, e.g. the method ClassLoader( ) of the Java language. Object supporting software other than a JVM may be used in accordance with the invention. The object supporting software 4 may then serve to run object oriented application software 5. When required, changes in object oriented application software 5 may be made using software management tools 6. The software management tools may be designed in accordance with the JMX specification. However, the invention may apply to other software management tools as well.

As shown, an exemplary architecture may include the object oriented application software 5M1 in machine Ml, and the software management tools 6M2 in machine M2, which thus may be dedicated to software management. However, many other combinations are possible, based on two machines or more. Provision for a management dedicated machine is an option. One or more machines may include both application software and management tools, as shown in figure 2. Also, each machine may support one or more Java virtual machines or other types of machines or devices.

The reader is assumed to be familiar with object oriented programming in general, more specifically with Java, still more specifically with JavaBeans. Details may be found at: http: //Java. sun. com for Java htt : //Java. sun . com/beans/spec .html for JavaBeans and/or in the corresponding printed documentation, e.g. "The Java Language Specification", James GOSLING; Bill JOY, Guy STEELE, Addison Wesley, 1996, ISBN 0-201-63451-1.

Generally, an object may be viewed as a re-useable structure, possibly inheriting properties from an ancestor or parent, and which groups inter-related functionalities.

In object oriented programming, an object may comprise properties and methods, together termed [object] members. For convenience, the methods are usually identified by their name followed with (). Where a method requires parameters, these are inserted between the two round brackets . Most of the methods are directed to the members or internal contents of the object: get () for reading a property, set () for writing a property, other property-related methods, access to other methods, etc ...

An object may also be manipulated using other methods such as "reflections" and "introspection", e.g. in the case of software management objects as is commonly done in the Java programming language.

Generally (Fig. 2), an object oriented programming environment may be viewed as including an object processor or provider 41, adapted to work with software entities defined as objects. Such objects are used for running^ application software(s) 5.

Defining an object, irrespective of the implementation language in use, means storing a representation of the desired corresponding object structure in the memory. The object definition is usually called an "object class". Now, support for application programming may be found in "object instances". An object instance has a name, and memory areas are prepared to receive values for the object members in the structure. An object may be initially created (instantiated) by means of an object constructor (in short, a "constructor"). At least one constructor must be available in order to instantiate an object.

The existing ways to create an object will now be considered, using the purely illustrative example of an AddressBook object, as defined in Exhibit 1. With a view to avoid unnecessary redundancies, the exemplary AddressBook object used hereinafter is simplified to have only the- following members: Name, Address (street only), and Telephone number. It is now assumed that a corresponding AddressBook class has been defined. The AddressBook class may then be "instantiated", i.e. an object is created therefrom, so that the object members (Name, Address, Telephone) may be given values corresponding e.g. to a particular individual.

The way an object may be created in accordance with previous methods is shown on figure 3. Step 500 is a request for creating an object, e.g. an AddressBook object. Test 501 reflects the fact that a default and/or a non-default constructor may be available.

An object may be instantiated as an empty structure, using a so-called "default constructor", taking no arguments (step 502). The member data in that structure may be filled in at a later stage, using e.g. pre-existing data, or a suitable user entry form, made accessible to the user through the user interface. This necessitates some programming, e.g. to build a user entry form. In the example, a default constructor would instantiate an AddressBook object with no entries. Within a program, this default constructor may be invoked by writing code as shown in illustrative code Example 1 (given in Java style code. Please not that all code example are illustrated in exhibit 1). The code creates an empty AddressBook object, having no member values for the time being (except when default values for the members are defined in the class being instantiated) . The syntax of the code instruction is: AddressBook = type of object, addressbookl = name of the object instance being created, new AddressBook( ) = method calling the default constructor for creating the object.

Alternatively, an object may be instantiated with attribute values being directly defined at object creation (step 503). This uses a so-called "non-default constructor", taking one or more arguments (or parameters). Thus, in the example, the AddressBook object may also be created by a constructor which takes an array of Entry objects in its parameter list. The Entry objects are items to be introduced into the AddressBook object.

Code example 2 creates another AddressBook object, named "Addressbook2" , and containing two entries for two different individuals:

- entry 1 is the name of an Entry object, created by the object constructor pursuant to a "new entry()" method having three- parameters : "Stephen", "4 Maple Road" , "555-5879411" ; - entry2 is the same, however with three other values of the parameters corresponding to another individual; and - Addressbook2 is the name of an AddressBook object created by the object constructor, pursuant to a new AddressBook (entryl _f entry 2) method having objects entry! and entry2 as parameters. In short, Example 2 instantiates an AddressBook object containing the Entry objects "Entryl" and "Entry2", that are passed in the constructor.

Non-default constructors are advantageous e.g. where it may be desirable to fill in an object immediately upon its creation, without having recourse to the help of a preprogrammed user entry form. Such a situation may appear for example with system objects: an empty system object often has no utility; also, since a number of system objects will be created only once, it would be practically inefficient to write an entry form program for each of them.

The non-default constructor for such an object may take a single string as a parameter (or another simple or trivial parameter) . If so, it is possible to use code cooperating with the graphical user interface with a view to simply prompt the user to enter a string value (this is hereinafter called an "entry window"). Then, the object constructor will create the object, with the string value (or other trivial input) within it.

Such entry windows may also be used for stepwise entry of parameter values within an empty object, after it has been created by a default constructor. However, this only applies when such parameter values individually have one of the primitive types, e.g.: string, integer, long, boolean. Now, parameter objects may also be "complex", i.e. the non-default object constructor then takes one or more non-trivial parameters, for example a Vector (Java Vector, i.e. a dynamically re-sizable array), or an Address Book object parameter. In such a case, it becomes difficult to provide a uniform way to get this information from the user, since it is not easy, if possible at all, to type in a "Vector" object into an input field, presented to the user in a window.

The problem is how to allow a user to input enough information to create a complex object using non-trivial parameters, in a graphical environment. In other words, currently known graphical user interfaces do not spontaneously allow the creation of objects taking non-trivial parameters in their object constructor.

The invention intends to address this problem. However, the solution finds more general use, as it will be appreciated.

Other aspects of the problem will now be discussed.

Java is an example of an object-oriented programming environment. It uses objects not only in the application software it may support, but also in its "software system functions" (e.g. MBean-based software management tools), which involve a programmer, rather than a final user. Software management tools may involve complex objects.

Many tools are available for graphically manipulating complex objects, such as "Java Workshop", or the "BeanBox". Such tools are available e.g. at: http: // iava. sun.com However, these tools only offer a default constructor for creating objects. Where objects to be used cannot be created with a default constructor, then it is necessary to write a program, instead of working through the graphical user interface. This is of course economically inefficient, especially for objects to be used only once and/or complex objects, such as those whose definitions may not be known as the time of writing the code for the input interface. As mentioned, a default constructor basically creates an empty object. One may then use object methods, popping up suitable pre-programmed entry forms, to set the values of the object members.

When the input required for that empty object to become meaningful is trivial (e.g. inputting a string, or a number, or a boolean), then the graphical user interface may simply prompt the user to enter a string value, and an object constructor in the system is given the user input to create the object, with the string (or number or boolean) value within it. Such a prompting facility with a single entry field is available in many graphical user interfaces, if not in all of them.

Now, the above described approach operates only where the constructor requires little and/or trivial user input, which may be processed as mentioned above.

Otherwise, in a more complex situation, the prompting facility does not operate correctly, and it would be necessary to write code enabling to enter the non trivial input. However, while it makes sense that the programmer writes entry form programs for the final user, he will generally not like to write such forms for himself, especially for objects he will create a small number of times, possibly only once.

After having been created, object instances often require manipulation. For example, after an AddressBook object has been instantiated, one might then want to perform some operations on it, such as changing, deleting or adding Entry objects to it.

The method of performing an action, or setting an attribute on an object is highly specific to the object definition.

This will be illustrated in the exemplary case of JavaBeans type of objects. However, this example should not be viewed as limiting the present invention, as applicability to other types of objects is contemplated. Details on the JavaBeans may be found at: http: //Java. sun.com/beans/spec .html and/or in the corresponding printed documentation. Basically it outlines what is meant by an operation or an attribute. Through standard JavaBean definitions, object managing operations are exposed (accessible from outside the object) for any object, as indicated in Example J41 in Exhibit 1.

The problem is thus to allow creation and manipulation of objects, even when these require non-trivial user input.

The invention will now be described with reference to the non-limiting exemplary screen structure diagrammatically shown in figure 4. The objects being used are now system objects.

In the screen heading, the acronym JDMK reflects the fact that in this particular example the user, e.g. a software developer, is using the Java Agent Manager of the Java Dynamic Management Kit. The screen may have the following windows : - a window 152 forming a graphical representation of an MBean server (optional), for use in software management;

- a class browser window 154, for listing available object classes;

- an object browser window 156, for listing available instantiated objects.

Windows 152, 154 and 156 (like other windows to be described) may have the usual window handling icons or metaphors, e.g. expanding, reducing, moving or closing the window, scrolling through a list, and buttons for triggering operations. An example is the "Create as object" button 1540 in class browser window 154.

One or more of windows 152, 154 and 156 (and other windows to be described) may be used as a clipboard, i.e. enabling the user to select an object instance in the window, for use as a parameter during creation of a new object. The clipboard data may be stored in corresponding memory areas . The expression "memory area" here designates one or more memory locations used for a common purpose. The memory locations need not be contiguous. Nor do they need to be on the same memory medium: portions of the memory area may e.g. be dynamically swapped between RAM and a hard disk.

In the example, object browser window 156 is a two-part window, having an upper part 1560 for listing objects, and a lower part 1561 for listing details of the currently highlighted object 15604 (if any) in upper part 1560. The last line of lower part 1561 may indicate at 1569 the type of the currently highlighted object 15604 (if any). Object browser window 156 may form part of the clipboard.

Fig 5 shows an example of class browser window 154 in more detail. The available classes appear in the form of a list, in which "HttpConnectorAddress" is currently highlighted. The available classes may be found in the Java "class path", partially visible at 1541.

Clicking on the "Create as object" button 1540 will initiate the creation of an object instantiating • the currently highlighted class, i.e. "HttpConnectorAddress". Action on button 1540 pops up a further "create object" window 158-i, which appears overlying the current windows in the screen of figure 4, or is placed in the empty space 15E of that screen of figure 4. Reference 158-i, i varying from 1 to 5, designa- tes different "create object" windows in figures 6, 7, 8, 12 and 14.

The basic operation of the "create object" window may be defined by the flow chart of figure 9, where the initial step 600 may be launched e.g. by clicking button 1540 of figure 4 (or figure 5) .

A first form of window 158 is shown as 158-1 in figure 6. Generally, window 158 has:

- a heading 1580, recalling the function and offering window handling icons;

- a read only section 1581 recalling the class being current ly instantiated; - a constructor section 1582 indicating one or more available object constructors available for that class;

- a constructor parameter section 1583 indicating available parameters, as needed by the currently highlighted constructor; and - a command button section 1584.

In the example, constructor section 1582 has one line initially displaying a first constructor, which is normally the default constructor (step 602 on figure 9). The right end of constructor section 1582 is provided with a tool button 1582B enabling selection of another constructor by popping up a list in the well known "combobox" mode.

Upon its initial appearance, the "create window" is as shown as 158-1 in figure 6. The default constructor is selected in section 1582. Accordingly, no parameter is shown in section 1583 (nothing is displayed between the parentheses). Thus, steps 610 and 650 of figure 9 do not apply, as it will be understood. Section 1584 shows the buttons "create" 15840 and "cancel" 15841, which, if actuated (step 652 on figure 9), would respectively create a new object (step 656 on figure 9) using the default constructor with no parameter, or cancel the create object operation. In both cases, the "create object" window will thereafter disappear (step 658 on figure 9), unless one or more of the supplied parameters is found to be illegal or non-compatible, in which case some error handling or recovery may be provided.

The newly created object will appear in object browser window 1560 of figure 4 (if it meets its current display criteria). However, it is empty, and therefore useless as the intended "HttpConnectorAddress", in the example.

Thus, the user will more likely select another constructor in constructor section 1582. After clicking tool button 1582B, and selecting another constructor in a list (not shown), one obtains e.g. a "create window" as shown as 158-2 in figure 7. Constructor section 1582 now shows an object constructor having two parameters, a string and an integer, and constructor parameter section 1583 now shows two entry fields, corresponding to the parameters, and indicating the required type in each field, i.e. string at 1584-21 and integer at 1584-22. The user may type in the desired values for the "HttpConnectorAddress". Thus, a complete object may be obtained, having for example the values: string: "localhost" integer: 8080 Alternatively, the user may click on a detail property in section 1561 of the screen (figure 4), and drag and drop that property to one of the entry fields 1584-21 and integer at 1584-22. Assuming the value has not the correct type, the system may automatically effect a type conversion, if available and/or meaningful. For example, if the above second parameter value is available as a string "8080", a function like toInteger( ) may convert it into the required integer type. These primitive type conversions are well known to people skilled in the art of Object Orientated programming.

To obtain this, the system has responded to the change in the constructor selection by implementing step 610 on figure 9 (with no result, for reasons to be described later), and step 650, using either manual entry, or drag and drop therein.

In more general terms, the class (object definition) being selected may have a non-default constructor, which takes a primitive parameter, such as a character string or number. Then, the user may be prompted to enter the desired primitive value through any of the normal Graphical User interface (GUI) methods, such as popping up an input dialog, requesting user input. The above is an example of trivial input, since only a string and an integer are required. The entry fields in section 1583 enable the user to define the required input.

Now, it has been observed that non-trivial user input is often required to create meaningful objects in certain applications or situations. The case of such a more complex object will now be considered, in the example of creating an object from the "CascadingAgent" class, an example of a sophisticated Java object definition, explained in detail in the Java Dynamic Management Kit documentation, available e.g. at http: //sun.com.

From the initial window with the default constructor (not shown), the user may access a non default constructor, as shown for example within window 158-5 of figure 8. Section 1582 now shows that the constructor has a "ConnectorAddress" as a parameter. In section 1583, frame 1583-51 shows the parameter name (in fact the end of it). In addition, a button 1583-52 appears, meaning that help may be obtained in creating the object with that parameter. The way this may be obtained will now be described with reference to figure 10. Upon changing the object constructor, step 610 is entered. Next step 612 scans the parameters of the newly selected constructor, and, for each parameter (step 614):

- step 616 displays an entry field for that parameter;

- step 620 (to be described in more detail) determines whether at least one compatible object exists;

- if so (step 640), step 642 additionally displays a special button in connection with the parameter.

This is repeated (steps 644,646) until the end, when all parameters have been considered.

The detail of step 620 is shown in an example in figure 11. The currently considered parameter object is noted "OAl". Step 622 determines the structure of object OAl, using, e.g. the well known reflection tools of Java, or tools having similar functions in other languages.

Now, object structures may be compared. Two object structures OAl and OB may be found compatible, in the sense that the structure of object OB may be useful for constructing object OAl. The compatibility may be determined automatically, e.g. from the following criteria: - the object OB comprises an assignable instance of the required parameter under scrutiny for the object OAl under construction; or

- the structure of object OB derives from a class or subclass having the required object definition for the object OAl under construction.

Step 624 thereafter gets objects existing on the "clipboard", which, in the example comprises the instantiated "httpConnectorAddress" in window 1560 of figure 15. Then, until all objects have been seen (step 626): - step 630 examines the structure of the currently proposed object, e.g. using again introspection,

- step 632 compares that structure with the one of OAl,

- if the structures are not compatible, test 634 returns to test 626,

- if the structures are compatible, test 634 passes to step 636 for generating a special button (or other equivalent display), and then to the end. This is preferred to accelerate the display; however, step 636 might also return control to test 626 (as shown in dash line), thus immediately building, a full list of compatible objects.

In the exemplary display, the special button 1583-52 in figure 8 (or 1583-62 in figure 14) has a double dot within a frame and is positioned adjacent to the parameter entry field 1583-51 (or 1583-61) on its right side. This has been found to correctly suggest that a continuation is available for the parameter in the entry field. However, this choice is in no way limiting, and other possibilities exist both in terms of button icon and button positioning. Moreover, other solutions than a button may be used: for example, it may be possible to present several entry fields for the same parameter, one for manual entry, and another configured as a push-button and/or a combobox, for selection of compatible objects. The active one of the entry field may be the last one selected, or defined by an associated checkbox.

Reference is now made to figures 12 (screen in part) and 13 (flow chart). After clicking on button 1583-52 of figure 8 (step 700), there appears another window 1586, proposing a compatible object instantiated from the "HttpConnectorAddress" class. The display in the window may indicate the particulars of the object instance being proposed (with or without the full path, as may be selected in known fashion); it may include a corresponding icon 1586-1. The above created "HttpConnector-Address" is proposed in the example. The list is obtained at step 702, e.g. by executing again the steps of figure 11, however only for the parameter under consideration, and now with step 636 merely returning control to test 626. This enables to build a full list of compatible objects, if it is not already available. The list may be built dynamically, in accordance with the needs of display in window 1586, at step 704. Steps 706 and 708 enable the user to accept or cancel the selection, in a known fashion.

Selecting the object in window box 1586 means accepting the proposed object as a parameter for constructing the object being currently created in window 158. This results in a new appearance of window 158, as shown at 158-6 in figure 14. Box 1583-61 now displays the selected "ConnectorAddress" , in fact the end of it in the example, which has horizontal scrolling.

If desired, the object browser window 156 of figure 4 may be used to get full information on the "ConnectorAddress" object which is being selected as a parameter for the non-default object constructor of the "CascadingAgent" class.

Alternatively, the user may select another object in the object browser window 156 (figure 4), and "drag and drop" it within box 1583-61 (figure 14). The selection of such an object in the object browser window 156 is shown in figure 15, where it will be noted that the connector address parameters are different from those of figure 12.

If the user decides that the connector address shown in figure 14 is correct, clicking on the create button 15840 will create a new object, using the constructor shown in section 1582, with the parameter shown in section 1583-61.

Reverting to the selection of an object constructor for the "CascadingAgent" class, the user may prefer another constructor, as shown in figure 16. This other constructor takes an additional parameter, of the "string" type. The "connector" parameter (complex, i.e. non trivial) may be defined as discussed with reference to figures 8 through 15. The "string" parameter may be defined as discussed with reference to figures 6 and 7.

Thus, the number of parameters may vary, and include one or more non trivial parameters and/or one or more trivial parameters .

It has been observed that almost all complex objects are in turn made up of simpler objects. Normally, a computer system enables the user to create or manipulate "simple" objects, taking trivial constructor parameters. Thus, these simple objects may be built up, and subsequently re-used to create progressively more complex objects. Conversely, complex objects may usually be created by combining one or more less complex objects. As the objects become less and less complex, more and more of them require only trivial parame- ters, or, in fact, have default constructors using default values for all parameters.

The previously created objects may be stored e.g. on a "clipboard", allowing their usage in further creating new objects, potentially more complex. Thus, an intuitive graphical user interface is obtained, which can "sense" when needed complex objects are available on the clipboard.

In a particular embodiment of this invention, the clipboard comprises a graphical list of all object definitions (class browser) and all instances thereof (object browser) being currently known in the system. More generally, objects provide an intuitive way to encapsulate functionalities in programming, and thus lend themselves toward manipulation (e.g. selection) in a graphical drag and drop type environment. Thus, each object instance may be inspected, giving access to its members. Clicking on a member in turn gives access to the member value.

In more general terms, the invention uses the concept of an object clipboard, which consists of a memory area, acting as an object repository. The clipboard may be queried for compatible objects and/or displayed graphically, at least partially.

An exemplary embodiment of the Object Clipboard will now be described in more detail. The clipboard may e.g. be an object extending: java. lang.Vector which may e.g. have the method FindCompatible ( ) , implementing all or part of the flow chart of figure 11, to allow the list of objects contained in a Vector to be queried for compatible object instances.

The clipboard provides a unique way to allow to get at all/any internal values of a complex object. It is now assumed, for example, that an AddressBook object is on the clipboard, and the user would like to know what it contains. To this effect, the introspecting methods described in Example J41 may be used (or similar methods, if not in Java). When the user e.g. clicks on the AddressBook object, the clipboard object will then display to the user the introspected operators available, e.g. in object details section 1561 in figure 4. When one operator is selected, any return values of the operator may be placed themselves on the clipboard. Referring e.g. to figures 4 and 15, window 156 has an "object" section 1560 and an "object detail" section 1561, showing the details, i.e. properties and methods, of the currently highlighted object. In section 1560, the "httpCon- nectorAddress" object is accompanied with a particular address value. Similarly, clicking on or otherwise selecting a "detail" object in window 1561 may trigger display of the value or content of that "detail" object, either on the same line as the object name, or in another appropriate form, e.g. a special window displaying the return value of a method being currently selected.

In the example of the AddressBook object, the following sequence of user actions may take place:

- getEntr±es ( ) , resulting in a list of AddressBook Entry objects being placed on the clipboard; - selecting one of these Entry objects would in turn expose their methods, accessed by reflection. The methods may be e.g. getName ( ) , getAddress ( ) , ge tTe 1 eph on eNumber ( ) ;

- subsequent activation of one of these methods would also place the result they give - e.g. an object, a String or an Integer value - on the clipboard.

So, it becomes possible to recurse down through an object and obtain as much information as desired, and expose all desired internal information on that object.

A general flow chart of the operation in accordance with the invention is shown in figure 17 and 18, with Figure 18 continuing figure 17.

Steps 500 - 501 are the same as in figure 3. If only a default constructor is available (step 521), an attempt to create the object is made (step 580), using that default constructor. If this is not possible, an error condition is generated (step 523).

Finally in figure 18, for a default constructor, the created objects as used are stored on the clipboard (i.e. into the clipboard memory area) at step 591.

For this purpose, one may identify each unique object e.g. by using its hash ( ) function (outputting a unique digital identifier). Preferably, for user's convenience, the object is also identified using its toString ) function (outputting the object name or a user defined alias therefor). Both hash () and toString( ) functions are known in Java; similar functions may be used in other languages as well.

Coming back to figure 17, if at least one non-default constructor is available, one will be selected by the user at step 506, then it will be executed at step 510. The execution begins with searching in the clipboard for possible compatible objects, as defined above.

If it is assumed that no such compatible object is found at step 510, then step 520 will be performed, allowing parameter selection from other sources.

For example, assuming the clipboard already contains a string object, then the user may drag and drop that object three times on a desktop portion of the screen: 1. As a "name" entry field,

2. As an "address" or street entry field,

3. As a "telephone" entry field (assuming e.g. the string object contains only digits).

After suitable string length adjustment (if required; programming this is accessible to men skilled in the art), the user now has all what is necessary for him to input the desired <Name>, <Address>, <Telephone> values of the Addressbook EntryObject, at step 530. In fact, taken together, the three Entry fields form an entry field for the Addressbook EntryObject.

After the object is created at 580, step 591 of figure 18 will operate to incorporate the newly defined Addressbook Entryfield into the clipboard. Step 591 may be executed always, or only when the creation - or other manipulation - is successful. Furthermore, its execution may be subject to other conditions, e.g. a prompt to the user asking him whether he wishes to store some or all of the recently used objects in the clipboard, or not.

In broader terms, the object manipulation is started by creating a single Entry object. Since a single entry object takes trivial parameters, the user may easily be prompted for the required data to be passed in the constructor; alternatively, the object may simply be instantiated with the default constructor (if available), implying that the user does not want to enter data at that time.

Once this object is created, then a representation thereof is placed onto the aforementioned object clipboard. Representation here means the object itself or a reference of any kind to it.

An example of application of the flow-chart of Figure 17 and Figure 18 will now be described, in connection with the creation of an AddressBook object.

When selecting the AddressBook object for creation, the GUI inspects the parameter (member) list for each of the constructors (step 501).

Assuming again that no default constructor exists, the GUI will propose to the user at least one constructor. At step 506, the user selects a constructor requiring parameters of the type "Entry". At step 510, it then scans the object clipboard to determine if there are any compatible objects stored there. It will find the corresponding objects, as created earlier. It then offers to the user a list of "compatible" objects, of which he elects one matching each of the complex parameters for the selected constructor (step 530).

Turning back to the AddressBook example, the Entry object may likely have to be extended to define two new object types, e.g. BusinessEntry and PersonalEntry. This will be dealt with at step 520. Depending on the specific object implementation, it is not difficult to see how one expects the AddressBook object to accept any of these three object types in a constructor: AddressBook, BusinessEntry and PersonalEntry. So, if any preexisting BusinessEntry objects are available on the clipboard, and the constructor requires an Entry object, since they are assignable to each other, the compatible BusinessEntry objects will be presented to the user for possible use in the desired constructor.

This is an example of objects being compatible because each of them comprises compatible instances of required parameters for an AddressBook object.

The flow chart of figure 17 is sequential, as any flow chart is by essence. However, the description made with reference to the screen and its windows has shown that the system responds to user events, which may occur in any desired order. Accordingly, the sequence of the operations in figure 17 is purely illustrative. In fact, these operations may be also be considered as responsive to events, which may occur in any order.

Further applications of the invention will now be described.

In the same way as described for object constructors, performing operations on, or setting attributes on objects, may require non-trivial parameters. While this is easy to accomplish within a program, by contrast, this is difficult to present in a Graphical User Interface, for the same reasons as described hereinabove.

The problem may be solved in the same way, by sensing if the required parameter to the operation (or attribute) is a complex object, and if it is, presenting the user with a list of all available objects from our object clipboard.

As an implementation specific process, performing operations may return a value. For example the AddressBook object may have an operation called getEntries ( ) , which takes no parameters, but returns an array of all the Entry objects it contains. In accordance with this invention, these return values may then be added to the clipboard, since they may be of use in further object manipulations, as outlined above, e.g. for passing in other parameters to other object manipulations .

As mentioned, this invention is of particular interest for enabling developers to create system objects, using a Graphical User Interface. However, it may find more general use as well, e.g. for complex objects used a small number of times (thus not deserving the preparation of a specific entry form) . Such situations may also happen at the level of the final user.

This invention also covers the software code to implement the invention, especially when made available on any appropriate computer-readable medium. The expression "compu- ter-readable medium" includes a storage medium such as magnetic or optic, as well as a transmission medium such as a digital or analog signal. Such software code may include: - the code for at least partially implementing the steps of any of figures 3, 9 through 11, 13, 17 and 18 (hereinafter named "basic code"), and/or - code at least partially defining an object-oriented software environment, at least partially incorporating the "basic code", and/or

- code at least partially defining an user interface and at least partially incorporating the "basic code", and/or any equivalent of those codes performing similar functions, especially as defined in this description.

Exhibit 1 - Examples

Structure of the "AddressBook" object Members (example): "Name", "Address" (street), "City", "zip code", "country", "Telephone" Methods (examples ) :

- CheckTelephone ( ) , checking that the telephone number entered in the "Telephone" attribute has an acceptable number of digits.

- MailOutput ( ) , returning the Name, street, zip code, City and country attribute values, in an adequate format for printing onto a mailing envelope.

- getNamef ) , returning <name> (the value of the "name" attribute) as a string.

- setName( "Smith " ) , setting "Smith" as the value of the "name" attribute in the object.

Code Example 1

AddressBook addressbookl = new AddressBook( ) ;

Code Example 2

Entry entryl = new Entrγ("Stephen","4 Maple Road", "555-5879411 ") ;

Entry entr2 = new Bτιtry("John", "120akAvenue","555-73443") ;

AddressBook addressboofcZ = new AddressBook(entryl, entry2) ; ■ >

Example J41

Standard JavaBean operators exposed for any object, which is named for convenience "MyObject" :

- getName( ) returns the name of the object, here "MyObject" - getEntries() returns the list of the Entry objects existing in "MyObject" return type : string object

- getEntryCount( ) returns the number of entries in "MyObject". return type : integer object

Claims

1. A computer system, comprising:

- a user interface, - an object-oriented software environment adapted to create and process software objects, and

- software code capable of presenting object related data through the user interface, for possible use in creating further objects.

2. The computer system of claim 1, wherein said object related data comprise data used during object creation.

3. The computer system of claim 1, wherein said software code is arranged to present said object related data as a clipboard through the user interface.

4. The computer system of claim 1, wherein said software code is arranged to dynamically present said object related data, enabling browsing of the object related data while expanding a currently selected one of the object related data.

5. The computer system of claim 1, wherein said software environment defines at least one object constructor, capable of creating objects, and said software code is operable during operation of such an object constructor.

6. The computer system of claim 5, wherein said software code is arranged to enable user selection of at least an object constructor.

7. The computer system of claim 5, wherein said object constructor is a non-default object constructor.

8. The computer system of claim 7, wherein said software code is operable to determine existing objects, compatible with a parameter in said non-default object constructor, and for enabling selection of such compatible objects by the user.

9. The computer system of claim 8, wherein said software code is operable to display at least one parameter definition for the non-default object constructor, and is responsive to a determination of existing compatible objects for displaying a corresponding icon concurrently with the display of said parameter definition for the non-def ult object constructor.

10. The computer system of claim 8, wherein said software code is operable upon lack of compatible objects for enabling the user to gather parameters from other sources.

11. The computer system of claim 1, wherein the software code is arranged to initially store simple objects, and to create progressively more complex objects from such simple objects.

12. The computer system of claim 1, wherein the objects being created comprise software management objects.

13. The computer system of claim 11, wherein the software code is arranged to display details on available objects.

14. A method of creating objects in an object-oriented software environment, having a repository, adapted for storage of existing objects, comprising the steps of: a. Determining whether an object to be created has a non- default constructor, having parameters, b. Checking the repository fo objects compatible with the parameter when the object has a non-default constructor. c. When the repository has compatible objects: cl. Displaying such compatible objects for the user to select amongst such compatible objects, c2. Creating the object with the non-default constructor, with one or more selected objects as parameters .

15. The method of claim 14, further comprising the following steps : d. When the repository has no compatible objects, determining whether parameter selection from other source is possible, dl. If so, creating the object with the non- default constructor, with such parameter selection as parameters, d2. Else, determining whether object creation is possible through a default constructor with no parameter, d21. If so, creating the object from the default parameter.

16. The method of claim 14, further comprising the step of: e. Storing at least some of the newly created objects in said repository.

17. The method of claim 16, wherein step e. is performed upon successful object creation.

18. The method of claim 14, wherein step cl. comprises displaying the repository as a clipboard.

19. The method of claim 14, comprising initially storing simple objects in the repository, with more complex objects being progressively created from such simple objects.

20. The method of claim 14, comprising storing existing Entry objects in the repository.

21. The method of claim 14, comprising storing object attributes and/or object methods in the repository.

22. The method of claim 14, wherein the objects being created comprise software management objects.

23. The software code as defined in any of claims 1 - 13.

24. The software code for at least partially performing the steps in any of claims 14 - 22.

25. An object-oriented software environment, comprising the software code as defined in claim 24 or 25.

26. A graphical user interface, having a desktop area, a clipboard area, objects presented in said clipboard area, and an object creation section, said objects presented in the clipboard area being movable to serve as parameters in the object creation section.

27. The graphical user interface of claim 26, wherein said object creation section further admits manual input of object parameters.