WO2001069402A1

WO2001069402A1 - Apparatus for recompiling instruction produced from graphical based system

Info

Publication number: WO2001069402A1
Application number: PCT/US2001/001271
Authority: WO
Inventors: Scott Posey
Original assignee: Stagecast Software, Inc.
Priority date: 2000-03-13
Filing date: 2001-01-12
Publication date: 2001-09-20
Also published as: AU2001227911A1

Abstract

A method for recompiling a portion of the logic in a graphics-based logic driven application program includes receiving an indication that a graphical object is changed in a graphics-based logic driven application program. The logic in the application program that is associated with the graphical object is searched for and found. Once some or all of the logic associated with the graphical object is found, it is recompiled in the application program that is associated with the graphical object. A system for recompiling logic associated with an object upon changing the object in a graphics-based logic driven application program (fig. 4-9) includes a processor that receives an indication that a graphical object is changed in a graphics-based logic driven application program, a search program that searches for logic in the application program that is associated with the graphical object, and a compiler that recompiles the logic in the application program that is associated with the graphical object (fig. 9a).

Description

APPARATUS FOR RECOMPILING INSTRUCTION PRODUCED FROM GRAPHICAL BASED SYSTEM

BACKGROUND OF THE INVENTION

This invention relates generally to computer programming, and more particularly to recompiling logic associated with an object upon changing the object in a graphics-based logic driven application program. .

As computer programming steps into the new millennium, more and more emphasis will be placed on simplifying programming. An emerging technology is graphics-based programming, which permits such activities as drag and drop programming on a display. For example, the programming may be accomplished by demonstrating desired reactions of an object. To create a program, an object is moved from its current cell on the display to another cell using a mouse. This movement automatically creates code including a rule of movement for the graphical object, which the object will follow to move independently from cell to cell across the display. The code remains transparent to the user.

As more objects and rules are added, simulations are created, which may encompass such things as animations, games, and interactive environments. The objects move according to the rules. The objects may also be taught to interact with each other. Examples of such interactions include movement, playing sounds, spawning another graphical object, and deleting another object. One graphics-based programming program is Stagecast Creator developed by Stagecast Software, Inc. 580 College Avenue, Palo Alto, CA 94306.

In a system utilizing a programming language based on graphical-rewrite rules, such as the one described by U.S. Patent No. 5,566,295 which is herein incorporated by reference in its entirety, the first stage of rule-matching is a pattern match between the rule's before board template and the current simulation. Referring to Figures 1 a-d, the template consists of one or more objects 100 which must exist in the simulation in order for the rule to match. The template also records the relative positions of these objects 100, and the areas they occupy. The locations of the cells 102 occupied by a graphical object 100 is determined by its shape. A graphical- rewrite rule (GRR) is said to match when the simulation contains all of the graphical objects 100 in the template and the objects in the simulation occupy the same areas as the graphical objects 100 in the template.

In order to simplify and accelerate pattern-matching, each rule is compiled into a series of matching-tests 104-107, where there is one test 104 for each cell 102, in the template. A test 104 succeeds when the corresponding cell 102 in the simulation contains analogues of all the graphical objects that were in that cell 102 at the time the rule was created. The rule matches when all of these tests 104-107 succeed.

A problem arises when the shape of a graphical object 100 changes as the result of a manual change by a user. When this is done, all of the instances of that graphical object 100 in the simulation will be updated to have the new shape. As a result, the instances may occupy more or fewer cells 102, or a different arrangement of cells 102.

In that case, any rules that use the graphical object 100 and were compiled into tests 104 before the shape changed will no longer match, because occurrences of the graphical object 100 in the simulation will have a different pattern of cells 102 than what is in the templates. For instance, if the object 100 in figure la is resized so that it occupies four cells as in figure lc, tests 105-107 will fail. Consequently, the program will no longer work and the user would have to manually rewrite every rule whose "before" part includes the graphical object whose shape changed.

Therefore, the compiled representation of any rules that make use of the graphical object 100 must be altered to match the changed representation. Figure lc illustrates the graphical rewrite rule after the user has resized an object 100 and figure Id presents the recompiled tests 108-111 corresponding to the original tests 104-107.

Further problems are encountered when attempting to search for the rules affected by the change in shape. Lists of rules are maintained by subroutines, which in turn may be contained arbitrarily by other subroutines. Subroutines, in turn, are contained by simulation object types, which are contained by simulations. The hierarchy therefore involves four types of objects (simulation, simulation object types, subroutines, rules) which maintain their data in different ways. Computer programs typically group data into structures which then refer to other structures. A simple example of such a structure is the binary tree, where each branch point, or node, of the tree contains some amount of information. Each node might contain data about a person, and the tree could be organized such that a left branch off of a node contains a record of a person whose last name is alphabetically before the node before it, and the right branch similarly contains the record of a person whose last name is alphabetically after it.

The search through such a tree for a particular person therefore consists of examining each node recursively, navigating to the next left or right node according to whether or not the target person's name is alphabetically before or after the current node. The search terminates when there are no more nodes or when the node containing the record of the desired person is found. Such algorithms are highly efficient for their application.

However, such algorithms are inflexible. For instance, to count the total number of nodes in the binary tree, an entirely different algorithm would be required.

Further issues arise if a new kind of node is added to the tree. In the case of our example, it might be necessary to update both the person-locating algorithm and the node-counting algorithm.

The invention addresses these issues by ensuring that all nodes present a common interface and that all searches utilize it.

SUMMARY OF THE INVENTION

The present invention overcomes the limitations of the prior art and allows modification of a graphical object by automatically recompiling some or all of the rules which make use of the object upon a change in the object. More particularly, logic is updated so that the rules throughout the simulation continue to operate as they did before the object was changed.

There are two aspects to the invention: rule recompilation and a search mechanism for locating the rules which must be recompiled. The search mechanism has a plug-in module which permits different kinds of searches to be performed. Automatic rule recompilation is accomplished by one such plug-in module. A similar plug-in module is used to count the number of rules which require recompilation.

While rule recompilation is specific to systems using Graphical Rewrite Rules, the search algorithm is applicable to any data represented in a directed acyclic graph (DAG). It is useful specifically in situations where the nodes of the DAG are of different types.

Accordingly, the present invention recompiles a portion of the logic in a graphics-based logic driven application program. The present invention receives an indication that a graphical object is changed in a graphics-based logic driven application program. The logic in the simulation containing the object is searched. As the logic associated with the graphical object is found, it is changed automatically. Preferably, the present invention searches through the rules in the simulation to identify the rules which make use of the object, and compiles their "before" portions with the modified shape.

The object may be changed manually by a user. The change in the object may include a change in the object's size and/or shape. For example a change in the size of the object could include causing the object to occupy more cells on the template or board. In a preferred embodiment, the object may be edited in a manner similar to the way it would be edited in conventional paint programs. For example, an editing palette that allows the user to select an editing tool such as a paintbrush or an eraser using the input device could be generated and displayed. Input devices include a keyboard, mouse, joystick, etc. As an option, the recompilation of the logic may be carried out only upon receiving permission from a user. One manner of obtaining permission from the user is through the display of a pop-up window which prompts the user for the permission. An affirmation or negation of permission to make the change would then be received from the user based on a user interaction with the pop-up window. For example, the window displays a message such as "Do you wish to make the change to the graphical object? The change will require updating 23 rules" and two buttons, one affirmative and one negative. If the user chooses the affirmative button, such as by pointing to it with a mouse pointer and clicking a button on the mouse, recompilation of the logic is performed. If the user chooses the negative button, no recompilation of the logic is performed, and the change to the graphical object is cancelled.

In one aspect of the present invention, the automatic recompilation of the logic is accomplished by clearing all objects from the "before" portion of a rule and then adding them back in. As a result, the changed object is restored to the "before" portion of the rule with its new shape. The new logic replaces the old logic entirely. The new logic ensures that the object continues to function properly throughout the simulation. No user actions are required in this recompilation process.

The preferred searching architecture for locating the rules which make use of the changed object decomposes the search into two parts: an interface which is implemented by objects which contain rules, and an interface which is implemented by searching functions which examine them. The searching architecture is described hereafter in Sun's Java programming language. Those skilled in the art will recognize that the searching architecture could be implemented in virtually any object-oriented programming language.

In one aspect of the invention, the searching architecture is used to count the number of rules which make use of the object which is changed. In another aspect, the same searching architecture is used to locate the logic to be recompiled.

Thus, logic affected by a change in the graphical object is found and automatically recompiled and errors in the program are averted. Further, the preferred searching architecture provides a flexible and efficient tool that can be adapted arbitrarily to examine all of the rules in the simulation. These and other advantages of the present invention will become apparent to those skilled in the art upon a reading of the following descriptions of the invention and a study of the several figures of the drawing.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure la illustrates a prior art graphical representation of a graphical rewrite rule;

Figure lb illustates a compiled representation of the graphical rewrite rule presented in la;

Figure lc illustrates the rule in la after the user has altered object 0ι such that it occupies four cells;

Figure Id illustrates the recompiled representation of the graphical rule in lc;

Figure 2 illustrates a process for asking a user for permission to recompile logic that is related to an object being changed in a graphics-based logic driven application program;

Figure 3 illustrates a calling chain where different objects implement the node interface, permitting a variety of searches to be implemented;

Figure 4 is a flow diagram illustrating the implementation of the "iterate" method by nodes (containers and meta-containers);

Figure 4A is a flow diagram illustrating the implementation of the iterate method by leaf nodes (rules);

Figure 5 is a flow diagram showing a general process item flow that can be used to perform operation 421 of Figure 4A;

Figure 6A is a flow diagram depicting a searcher which uses the Searcher state parameter as an accumulator to count the number of objects meeting the criteria of a search;

Figure 6B is a flow diagram illustrating operation 416 of Figure 4 when the process of Figure 6A is used in operation 502 of Figure 5; Figures 7A and 7B collectively represent the implementation of a Searcher object which locates and returns a Rule making reference to some simulation object, such as a simulation variable or appearance which the user would like to delete;

Figure 7A is a flow diagram illustrating a process for changing the Searcher state in operation 502 of Figure 5 such that the Searcher state represents an identity of one or more objects meeting the criteria of a search;

Figure 7B is a flow diagram illustrating operation 416 of Figure 4 when the process of Figure 7A is used in operation 502 of Figure 5;

Figures 8 A and 8B collectively represent a Searcher object whose purpose is to locate all rules making use of a changed simulation object, and recompile them;

Figure 8 A is a flow diagram illustrating a process for recompiling a rule during operation 502 of Figure 5 when the search architecture of Figure 4 is used to find a rule that uses the graphical object in operation 216 of Figure 2;

Figure 8B is a flow diagram illustrating operation 416 of Figure 4 when the process of Figure 8A is used in operation 502 of Figure 5; Figure 8B is identical to 6B in that the return value of "no" effectively indicates that the entire tree is to be searched;

Figure 9 is a flow diagram that illustrates a process for recompiling logic during operation 804 of Figure 8 A; and

Figure 9A is a depiction of a change in the size of a graphical object from one cell on a "before" portion of a rule to several cells, and the corresponding change in the tests which are effected by the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

To create a graphics-based logic driven application program, or programming through demonstration, a graphical object is "moved" from a repository of objects and positioned in a cell or cells of a grid on a template or board, i.e., a display or other graphical user interface, such as by clicking on the object with a mouse pointer and dropping the object in the cell, for example. A system utilizing a programming language based on graphical-rewrite rules is described by U.S. Patent No. 5,566,295, which is herein incorporated by reference in its entirety for all purposes.

The graphical object is moved from its current cell to another cell or cells using the mouse or other input device. This movement automatically creates logic, i.e., code, including a rule of movement for the object, which the object will follow to move independently from cell to cell across the board.

In one embodiment of the present invention, each rule is compiled into a series of matching tests, where there is one test for each cell, or rectangle, on the board. A test succeeds when the corresponding cell in the simulation contains all of the objects that were in that cell at the time the template was created. The rule matches when all of these tests succeed.

In the exemplary embodiment, the "before" portion of a graphical rewrite rule (GRR) is compiled in order to make execution more efficient. When any object in the "before" portion of the GRR is changed such that it occupies more or fewer cells in the simulation, the GRR must be recompiled. In the current invention, the rules that use the graphical object are located and automatically recompiled. Thus, the changed graphical object will continue to function according to the rules during execution of the program as it did before it was changed by the user. It should be noted that it is not necessary that the changed graphical object be in contiguous cells. For example, the object may be altered so that it surrounds a cell in the simulation which it does not itself occupy.

In Figure 2, a process 200 for asking a user for permission to recompile logic that is related to an object being changed in a graphics-based logic driven application program begins at 202 once an indication is received that a graphical object is or has changed in the program such that it occupies more or fewer cells In an operation 204, the number of rules that make use of the object in their "before" portions are counted utilizing the searching mechanism which is also the subject of the invention. The number of rules which make use of the object is presented to the user before any changes are made, so that the user may have the option to avoid such changes in order to avoid the automatic recompilation, which may take a long time. Each instance of logic is part of a rule that refers to the object. Refer to the discussion of Figures 4, 5, 6A and 6B for a description of an illustrative searching mechanism that may be used to count the number of rules that make use of the object in their "before" portion.

As an option, a user may be queried in an operation 210 as to whether the change in the object is desired. One purpose of this operation is to ensure that the user gives permission for the recompilation of the logic, the other is to inform the user of the scope of the recompilation required by his change. One way of querying the user is through the display of a pop-up window which prompts the user for the permission. An affirmation or negation of permission to make the change would then be received from the user based on a user interaction with the pop-up window. For example, the window could display a message such as "Do you wish to make the change to the graphical object? 132 rules will be changed!" and two buttons, one affirmative and one negative. In a decision operation 212, it is determined whether the user desires the change in the object based on the user interaction. For example, if the user chooses the negative button in the pop-up window, the object is reverted to its original state in operation 214 and the process ends at 208 with no recompilation of the logic because the object has reverted to its previous state. If the user chooses the affirmative button, such as by pointing to it with a mouse pointer and clicking a button on the mouse, the process continues with the modified object.

In operation 216, the logic that is associated with the changed object is found and recompiled. A searching mechanism that may be used to find the logic associated with the object in operation 216 is described with reference to Figures 4, 5, 7A and 7B. More information regarding recompilation of the logic is found below with reference to Figures 8 A through 9 A. The process ends at 218.

The search mechanism has three design goals: 1) to provide a mechanism by which all rules in a simulation may be examined 2) to enable different kinds of searches to be performed, that is, to scan an entire simulation for a particular rule or to count all rules which make use of an object, such as a simulation object type or a variable. (In the prior art, there were separate calling chains for these uses) 3) to enable different kinds of containers and meta-containers for rules to be added without having to rewrite any searches or any calling chains.

Simulations and objects which are or contain rules, including simulation object types, subroutines, and rules all implement a single "iterate" method. This method has two parameters: an object which implements the Searcher interface and a parameter which may be any object or null. The purpose of the second parameter is to provide the Searcher with a way of maintaining its internal state. For instance, when counting rules referring to a particular object, the second parameter would be the number of rules found thus far. Those skilled in the art will recognize that this is a standard technique that permits the code of the Searcher object to be re-entrant, or thread-safe. That is, it permits a single instance of a Searcher object to be in use by multiple threads without having one thread distort the internal state of a search being performed by a second thread..

Figure 3 illustrates a calling chain where different objects implement the node interface, permitting a variety of searches to be implemented. The searching architecture 302 of Figure 3 decomposes the search into two parts: an interface which is implemented by nodes 304, and an interface which is implemented by searching functions 306. These interfaces are described below in Sun's Java® programming language, although the searching architecture 302 could be implemented in virtually any programming language. Each node 304 determines what data are subjected to the searching function. The searching function 306 then determines whether it is done. If not, searching continues.

Figure 4 illustrates the preferred process 400 of an "iterate" method as implemented by objects which contain nodes (containers and/or meta-containers), for performing searches such as those described in relation to Figure 3. The process 400 of Figure 4 represents a searching architecture with variable applications. For example, this process 400 may be used to count the number of rules that are associated with the graphical object. See operation 204 of Figure 2. This process 400 may also be used to identify logic that is associated with the graphical object so that the logic may be recompiled. See operation 216 of Figure 2.

Referring again to Figure 4, the process 400 starts at 402 with the receipt of a Searcher software object and a "Searcher state" parameter. The "Searcher state" parameter will generally be null at the beginning of search. In a decision operation 404, it is determined whether data remains to be searched, for instance, whether or not the Searcher software object has been passed to all simulation objects. If no more data is to be searched, the Searcher state is returned in operation 406 and the process ends at 408.

If data is found to search, a data item is retrieved in operation 410. The data item will be a rule or a container which must also implement the "iterate" method. The Searcher software object and the "Searcher state" parameter are given to the data item's "iterate" method in operation 412. A new "Searcher state" is received from the invocation of the data item's "iterate" method in operation 414.

The Searcher is asked whether it is done in a decision operation 416 by invoking the Searcher's "done" method using the Searcher state. This operation 416 separates the criterion of being done from the act of performing the objective of the search, such as counting or finding particular data items. Those skilled in the art will recognize this as an alternative to testing the Searcher for a particular value. If the searcher indicates that it is not done in operation 416, the process 400 repeats beginning with operation 404 to determine whether there is more data to search. If the searcher indicates that it is done, the current Searcher state is returned in operation 406 and the process ends at 408. It should be noted that it is possible for the original Searcher state to be returned in operation 406, such as when the search does not find data items it is searching for.

The process 400 shown in Figure 4 searches through a set of data structures about which nothing is known, other than any contained objects implement the "iterate" method. This permits the container objects to organize the data however they like. The searcher does not need to know how the container objects organize their data; it merely processes each contained object one-by-one.

In the case of a Rule, the process of the "iterate" method is depicted in Figure 4A. As before, the process starts at 420 with the receipt of the Searcher software object and the searcher's state. In 421, the Rule invokes the Searcher's "processltem" method, passing itself and the Searcher's state as parameters. The Searcher's "processltem" method then returns the new or updated state 422 which is finally returned to whoever invoked the Rule's "iterate" method in 423.

Figure 5 illustrates an exemplary process that the searcher can perform to create a new Searcher state once it receives the Searcher state and data item in operation 421 of Figure 4A. The process starts at 500. In operation 502, the searcher uses the item and Searcher state to find a new Searcher state, which is returned in operation 504. The process ends at 506. Following is a code segment that may be used to perform the process of Figure 5. The code segment is written in Java.

/**

* An Iteration Processor is used to iterate over all rule list items in the World,

* by calling World.iterateOverRules. Each rule list item will have iterate

* called on it with the IterationProcessor. It is up to the item to decide

* whether or not to call the processor with itself or iterate over its contents

* with the processor.

* The iterate implementor should pass the result of the previous processltem

* to the next one using the processorState parameter. It should then call done

* with the result to see if it's done. This technique can be used to return

* objects up the chain. */

// figure 5 interface IterationProcessor

{ public Object processItem(RuleListItem item, Object processorState); // 502/504 public boolean done(Object processorState);

Figures 6 A and 6B collectively illustrate the implementation of a Searcher software object whose purpose is to count the number of Rules in a Simulation which make reference to a given simulation object.

Figure 6A illustrates an exemplary searcher process for counting all Rules which make reference to a simulation object during performance of operation 502 of Figure 5. The searcher process begins at 600 and in a decision operation 602 it is determined whether the Rule makes such a reference. If the item meets the criteria, the Searcher state, in this case a number, is incremented by one in operation 604 and the Searcher state is returned in operation 606. If the item does not make reference to the Simulation object, the Searcher state is returned unchanged in operation 606. The process ends at 608. Those skilled in the art will recognize that this counting procedure could be used to count objects which meet any given criteria.

Following is a code segment that may be used to perform the process of Figure 6A. The code segment is written in Java.

// sample implementation of a function for counting the number // of rules in a simulation referring to some object (Fig. 6) int countRulesReferringTo (final ReferencedObject obj)

{

RuleListltem.IterationProcessor ruleCounter = new RuleListItem.IterationProcessor()

{

// expects processorState to be an Integer public Object processItem(RuleListItem item, Object processorState)

Integer count = (Integer) processorState; if (item.refersTo(obj)) count = new Integer(count.intValue() + 1); return count;

}

// always returns false so that all rules are scanned public boolean done(Object processorState) { return false; }

} ;

Integer count = new Integer(O); // start counting at 0 count = (Integer) simulation.iterateOverRules(ruleCounter, count); return count.intValue();

In Figure 6B, a second searcher method "done" corresponding to the searcher process of Figure 6A begins at 610 and, in operation 612, returns an answer to the question posed to the searcher in operation 416 of Figure 4, namely, whether the searcher is "done" given the new Searcher state. Because this search must check all Rules in the simulation to make an accurate count, "done" is always false, regardless of the current count. Those skilled in the art will recognize that an alternative might be to return "true" if the count has reached a certain limit. The searcher process ends at 614.

Figures 7A and 7B collectively represent the implementation of a Searcher object which locates and returns a Rule making reference to some simulation object, such as a simulation variable or appearance which the user would like to delete. In Figure 7A, a searcher process for performing operation 502 of Figure 5 finds data items meeting predetermined criteria. The searcher process begins at 700 with a Searcher state equal to null. In a decision operation 702, it is determined whether the item meets the criteria. If the item meets the criteria, the Searcher state is altered to identify the item in operation 704 and returned in operation 706. If the item does not meet the criteria, the Searcher state is returned as null. The process ends at 708.

Figure 7B illustrates a second searcher process, corresponding to the searcher process of Figure 7A, that returns an answer to the question posed to the searcher in operation 416 of Figure 4, which is whether the searcher is done given the new Searcher state. The searcher process of Figure 7B begins at 710 and, in operation 712, the searcher determines whether the Searcher state has a null value. If the Searcher state is null, the searcher returns a negative response in operation 714 and the process of Figure 4 is repeated to continue searching for the data item. If the Searcher state is not null, the searcher returns a positive response in operation 716, which causes the Searcher state to be returned in operation 406 of Figure 4. The searcher process of Figure 7B ends at 718.

Following is a code segment that may be used to perform the process of Figures 7A and 7B. The code segment is written in Java.

// sample function for finding a single rule that makes // reference to some object (Fig. 7)

//

Rule findRuleReferringTo (final ReferencedObject obj)

{

RuleListltem. IterationProcessor ruleFinder = new RuleListItem.IterationProcessor()

{ public Object processItem(RuleListItem item, Object processorState)

{

// note that object is passed in through the outside // function if (item.refersTo(obj) && item instanceof Rule) return item; return null;

} public boolean done(Object processorState) { // done if processorState is ever non-null, // indicating something was found return processorState != null;

}

};

Rule rule = null; rule = simulation.iterate(ruleFinder,rule); return rule;

Figures 8 A and 8B collectively represent a Searcher object whose purpose is to locate all rules making use of a changed simulation object, and recompile them.

Figure 8 A depicts a process for performing operation 502 of Figure 5 for recompiling the logic and/or rule that is associated with the graphical object, in accordance with operation 216 of Figure 2. In this embodiment, operation 502 is in turn used to perform part of the process of operation 412 of the process 400 of Figure 4. Operation 216 of Figure 2 is in turn partially or fully performed by the process 400 of Figure 4. The process of Figure 8 A begins at 800 and in operation 802 it is determined whether the logic is associated with the graphical object. If the logic is associated with the graphical object, the rule is recompiled in operation 804 and a Searcher state is returned in operation 806. The Searcher state is always returned as null in operation 806 because the Searcher state is not being used to return any information. The process ends at 808.

In Figure 8B, a process, corresponding to the process of Figure 8 A, returns a negative response to the question posed to the searcher in operation 416 of Figure 4. The process begins at 810 and the negative response is returned in operation 812. The process ends at 814. By consistently returning a negative response, the search process of Figure 4 is repeated until all of the logic associated with the graphical object has been found and recompiled if necessary.

Following is a code segment that may be used to perform the process of Figures 8 A and 8B. The code segment is written in Java.

// example of function for recompliling all rules that make use of target object

// figure 8

// example of function for recompiling all rules that make use of target object void recompileRuleReferringTo(fmal ReferenceObject target) {

RuleListltem. IterationProcessor ruleRecompiler = new RuleListltem.IterationProcessorO

{ public Object processItem( RuleListltem item, Object processorState)

{ if ( item.refersTo(target) && item instanceof Rule)

{

Rule rule = (Rule) item; rule.recompileO;

} return null; // not using a return value here

} public boolean done(Object processorState)

{

// always return false so that all // rules are scanned return false;

}

} ; simulation.iterateOverRules( ruleRecompiler, null);

Figure 9 illustrates a process for performing operation 804 of Figure 8 A for recompiling logic. See also Figure 9A for a graphical depiction of the process of Figure 9. The process begins at 900. A before board, i.e., a template or a board of a graphical user interface on which the graphical object is positioned before its movement according to the rules, is cleared of the graphical object in operation 902 to create a new blank before board. Preferably, all of the objects on the before board are cleared, including those remaining unaltered. The altered graphical object is placed on the new before board with its new size, shape, etc. in operation 904. In operation 906, new logic, preferably new tests, are generated on the new before board, which are used to replace the old logic and/or tests in operation 908. The process ends at 910. It should be noted that any searching mechanism or search engine could be used to find and recompile the logic affected by the change in the graphical object, not just those presented here.

Figure 9A is a graphical depiction of the process of Figure 9. As shown, the before board 920 has a first graphical object 922 positioned in cell (0,0) and a second graphical object 924 positioned in cell (1,1). The before board 920 is cleared of the objects 922,924 to create the new before board 926. In one embodiment of the present invention, each rule is compiled into a series of matching-tests, where there is one test for each cell, or rectangle, in the before board 920. A test succeeds when the corresponding cell in the simulation contains all of the objects that were in that cell at the time the template was created. The rule matches when all of these tests succeed.

Each cell on the before board 920 has a list 928 of graphical objects in that cell. Each test is based on the list 928 of the objects found in the cell. When a graphical object changes to be positioned in more or less cells, the lists for the affected cells change. The tests are recompiled based on the new lists for some or all of the cells on the new before board 926. In this way, the tests will be updated so that they do not fail thus causing the rule to not match, thereby causing the program to malfunction. Thus, the graphical object will move to another cell or cells according to the rules during execution of the program. It should be noted that it is not necessary that the changed graphical object be in contiguous cells.

It should be noted that the logic used in the examples herein and the processes illustrated in the Figures exemplify only one implementation of the present invention. Those skilled in the art will appreciate that other logic components can accomplish the design goals of the present invention. Likewise, alternative process operations can be used to implement the present invention.

Claims

C L A I M S What is claimed is:

1. A method for recompiling logic associated with an object upon changing the object in a graphics-based logic driven application program comprising: receiving an indication that a graphical object is changed in a graphics-based logic driven application program; searching for logic in the application program that is associated with the graphical object; and recompiling the logic in the application program that is associated with the graphical object.

2. A method as recited in claim 1, wherein the graphical object is changed manually by a user.

3. A method as recited in claim 1 , wherein the graphical object is changed in size.

4. A method as recited in claim 1, wherein the recompilation of the logic is carried out only upon receiving permission from a user.

5. A method as recited in claim 4, wherein a pop-up window prompts the user for the permission.

6. A method as recited in claim 1 , wherein the recompilation of the logic includes clearing the graphical object from a template, re-positioning the graphical object on the template to reflect the change, generating recompiled logic based on the re-positioning of the graphical object, and replacing the logic with the recompiled logic.

7. A method as recited in claim 6, wherein the template is cleared of all other objects and the recompiled logic is generated based also on the position of the other objects.

8. A method as recited in claim 1, wherein the searching includes counting rules of the logic and terminating the searching upon finding no more rules.

. A method as recited in claim 1, wherein the logic is recompiled in order to ensure that the changed graphical object functions properly in accordance with the logic.

10. A computer program embodied on a computer readable medium for recompiling logic associated with an object upon changing the object in a graphics-based logic driven application program comprising: a code segment that receives an indication that a graphical object is changed in a graphics-based logic driven application program; a code segment that searches for logic in the application program that is associated with the graphical object; and a code segment that recompiles the logic in the application program that is associated with the graphical object.

11. A computer program as recited in claim 10, wherein the graphical object is changed manually by a user.

12. A computer program as recited in claim 10, wherein the graphical object is changed in size.

13. A computer program as recited in claim 10, wherein the recompilation of the logic is carried out only upon receiving permission from a user.

14. A computer program as recited in claim 13, wherein a pop-up window prompts the user for the permission.

15. A computer program as recited in claim 10, wherein the recompilation of the logic includes clearing the graphical object from a template, re-positioning the graphical object on the template to reflect the change, generating recompiled logic based on the repositioning of the graphical object, and replacing the logic with the recompiled logic.

16. A computer program as recited in claim 15, wherein the template is cleared of all other objects and the recompiled logic is generated based also on the position of the other objects.

17. A computer program as recited in claim 10, wherein the searching includes counting rules of the logic and terminating the searching upon finding no more rules.

18. A computer program as recited in claim 10, wherein the logic is recompiled in order to ensure that the changed graphical object functions properly in accordance with the logic.

19. A system for recompiling logic associated with an object upon changing the object in a graphics-based logic driven application program comprising: a processor that receives an indication that a graphical object is changed in a graphics- based logic driven application program; a search program that searches for logic in the application program that is associated with the graphical object; and a compiler that recompiles the logic in the application program that is associated with the graphical object.

20. A system as recited in claim 19, wherein the graphical object is changed manually by a user.

21. A system as recited in claim 19, wherein the graphical object is changed in size.

22. A system as recited in claim 19, wherein the recompilation of the logic is carried out only upon receiving permission from a user.

23. A system as recited in claim 22, wherein a pop-up window prompts the user for the permission.

24. A system as recited in claim 19, wherein the recompilation of the logic includes clearing the graphical object from a template, re-positioning the graphical object on the template to reflect the change, generating recompiled logic based on the re-positioning of the graphical object, and replacing the logic with the recompiled logic.

25. A system as recited in claim 24, wherein the template is cleared of all other objects and the recompiled logic is generated based also on the position of the other objects.

26. A system as recited in claim 19, wherein the searching includes counting rules of the logic and terminating the searching upon finding no more rules.

27. A system as recited in claim 19, wherein the logic is recompiled in order to ensure that the changed graphical object functions properly in accordance with the logic.