CA2144730A1 - Object-oriented graphic picking system - Google Patents
Object-oriented graphic picking systemInfo
- Publication number
- CA2144730A1 CA2144730A1 CA002144730A CA2144730A CA2144730A1 CA 2144730 A1 CA2144730 A1 CA 2144730A1 CA 002144730 A CA002144730 A CA 002144730A CA 2144730 A CA2144730 A CA 2144730A CA 2144730 A1 CA2144730 A1 CA 2144730A1
- Authority
- CA
- Canada
- Prior art keywords
- recited
- geometric
- search
- framework
- hit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
- G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
- G06F3/0484—Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range
- G06F3/04842—Selection of displayed objects or displayed text elements
Abstract
A method and apparatus for defining customizable pick, hit or find detection criteria for geometric types and using the results of the search as a basis for determining whether to perform an action. According to the inventive method, a search protocol is defined for geometric types. The search criteria is compared with graphic objects to determine whether the object matches the criteria. Based on the results of the comparison, an output is produced. In addition to allowing customized hit criteria for primitive geometric types, the hit object framework allows hit criteria to be specified for geometric types created by the application developer.
Description
~WO 9S/04962 214 4 7 3 ~ PCT/US94/00005 OBJECr ORIENTED GRAPHIC PICKING SYSTEM
BACKGROUND OF THE INVENTION
The present invention generally relates to a mechanism for "hit" detection and, more particularly, to a hit detection mechanism in an object oriented 5 programming (OOP) environment. The subject invention is a framework ~y~Le which allows a progr~mm~r or applications developer to customize the search rrit~riA for graphic objects so that an application can identify objects on which to perform a specified action. The invention is disclosed in terms of a ~reL~lled embodiment which uses a popular object oriented programming language, C++, but 10 the principles are applicable to other computer programming languages both object oriented and procedural.
Description of the Prior Art Object oriented programming (OOP) is the ~refelled environment for building user-friendly, intelligent computer software. Key elements of OOP are data 15 encapsulation, inheritance and polymorphism. These elements may be used to generate a graphical user interface (GUI), typically charact~ri7etl by a windowing ellvi~ol~ment having icons, mouse cursors and menus. While these three key elements are common to OOP languages, most OOP languages implement the three key elements differently.
Examples of OOP languages are Smalltalk, Object Pascal and C++. Sm~llt~lk is actually more than a language; it might more accurately be characterized as aprogramming environment. Smalltalk was developed in the Learning Research Group at Xerox's Palo Alto Research Center (PARC) in the early 1970s. In Smalltalk, a m~ss~ge is sent to an object to evaluate the object itself. Messages perform a task similar to that of function calls in conventional programming languages. The programmer does not need to be concerned with the type of data; rather, the pro~ er need only be concerned with creating the right order of a m~s~ge and using the right message. Object Pascal is the language used for Apple's Macintosh(~) computers. Apple developed Object Pascal with the collaboration of Niklaus Wirth, the designer of Pascal. C++ was developed by Bjarne Stroustrup at the AT&T Bell Laboratories in 1983 as an extension of C. The key concept of C++ is class, which is a user-defined type. Classes provide object oriented programming features. C++
modules are compatible with C modules and can be linked freely so that existing C
libraries may be used with C++ programs. The most widely used object based and 21~30 object oriented programming languages trace their heritage to Simula developed in the 1960s by O-J. Dahl, B. Myhrhaug and K. Nygrad of Norway. Further informationon the subject of OOP may be had by reference to Object Oriented Design with Applications by Grady Booch, the Benjamin/Cummings Publishing Co., Inc., 5 Redwood City, Calif. (1991).
There has been a long felt need in the art for a developer of an application to be able to identify geometric objects, to define custQmi7e~1 search criteria for each geometric object and to specify the performance of an action based on the results of the search. To date, no system has been developed which addresses this need.
SUMMARY OF THE INVENTION
It is therefore an object of the present invention to provide an object orientedframework for defining hit criteria for geometric types. The criteria can be customized by the application developer and can specify the requirements for a hit 15 (pick) or a find, the extent of the search to be performed and the action to take when a hit (pick) or find is s~lcc~qsful.
According to the invention, there is provided a system for defining hit or find criteria for geometric types. The system uses this criteria to directly manipulate graphic objects which conform to the geometric type. The developer of an 20 application can also specify a specific hit criteria for two dimensional (2D) and three dimensional (3D) graphic objects which they have created.
BRIEF DESCRI1~rION OF THE DRAWINGS
The foregoing and other objects, aspects and advantages will be better 25 un.ler~stood from the following detailed description of a preferred embodiment of the invention with reference to the drawings, in which:
Figure 1 is a block diagram of a personal computer system of the type used in the practice of the subject invention;
Figure 2 is a screen print of a display in accordance with a plefeLled 30 embodiment;
Figure 3 is an illustration of various MGraphics and their geometries in accordance with a preferred embodiment;
2l44r~ ~G
~WO 95/04g62 PCT/US94/00005 Figure 4 shows the combination of primitive geometries to form simple and complex subclasses of MGraphic in accordance with a ~ref~lled embodiment;
Figure 5 illustrates an example of a graphic object, a bicycle, with many instances of the same MGraphic, a wheel in accordance with a preferred 5 embodiment;
Figure 6 illustrates the use of a path to record the correct instance for a hierarchical object in accordance with a preferred embodiment;
Figure 7 is a flowchart illustrating the detailed logic of a hit (picking) operation in accordance with a ~ref~lled embodiment;
Figure 8 is a flowchart illustrating the detailed logic for a graphic find operation in accordance with a preferred embodiment;
Figure 9 is a flowchart illustrating the detailed logic for a graphic search operation in accordance with a preferred embodiment; and Figure 10 and 11 illustrate various three dimensional (3D) objects in 15 accordance with a preferred embodiment.
DETAILED DESCRI1~rION OF A PREFERRED
EMBODIMENT OF THE INVENTION
The invention is preferably practiced in the context of an operating ~ysL~
20 resident on a personal computer such as the IBM (~) PS/2 (~ or Apple ~) Macintosh computer. A representative hardware environment is depicted in Figure 1, which illustrates a typical hardware configuration of a workstation in accordance with the subject invention having a central processing unit 10, such as a conventional microprocessor, and a number of other units inleLcol~l~ected via a ~y~L~ bus 12.25 The workstation shown in Figure 1 includes a Random Access Memory (RAM) 14, Read Only Memory (ROM) 16, an I/O adapter 18 for connecting peripheral devices such as disk units 20 to the bus, a user interface adapter 22 for connecting a keyboard 24, a mouse 26, a speaker 28, a microphone 32, and/or other user interface devices such as a touch screen device (not shown) to the bus, a communication adapter 3430 for connecting the workstation to a data processing network and a display adapter 36 for connecting the bus to a display device 38. The workstation has resident thereon an operating ~ysLell~ such as the Apple System/7 (~) operating system.
WO 95/04962 21~ ~ 7 3 ~ PCT/US94/00005 ~
In a pLerelled embodiment, the invention is implemented in the C++
programming language using object oriented programming techniques. As will be understood by those skilled in the art, Object-Oriented Programming (OOP) objects are software entities comprising data structures and operations on the data.
5 Together, these elements enable objects to model virtually any real-world entity in terms of its characteristics, represented by its data elements, and its behavior, represented by its data manipulation functions. In this way, objects can model concrete things like people and computers, and they can model abstract concepts like numbers or geometrical concepts. The benefits of object technology arise out of 10 three basic principles: encapsulation, polymorphism and inheritance.
Objects hide, or encapsulate, the internal structure of their data and the algorithms by which their functions work. Instead of exposing these implementation details, objects present interfaces that represent their abstractions 15 cleanly with no extraneous information. Polymorphism takes encapsulation a step further. The idea is many shapes, one interface. A software component can make arequest of another component without knowing exactly what that component is.
The component that receives the request interprets it and figures out according to its variables and data, how to execute the request. The third principle is inheritance, 20 which allows developers to reuse pre-existing design and code. This capability allows developers to avoid creating software from scratch. Rather, through inheritance, developers derive subclasses that inherit behaviors, which the developer then customizes to meet their particular needs.
A prior art approach is to layer objects and class libraries in a procedural environment. Many application frameworks on the market take this design approach. In this design, there are one or more object layers on top of a monolithic operating system. While this approach utilizes all the principles of encapsulation, polymorphism, and inheritance in the object layer, and is a substantial improvement over procedural programming techniques, there are limitations to this approach. These difficulties arise from the fact that while it is easy for a developer to reuse their own objects, it is difficult to use objects from other systems and the developer still needs to reach into the lower non-object layers with procedural Operating System (OS) calls.
Another aspect of object oriented programming is a framework approach to application development. One of the most rational definitions of frameworks comefrom Ralph E. Johnson of the University of Illinois and Vincent F. Russo of Purdue.
2~7~
~WO 95/04g62 PCT/US94/00005 In their 1991 paper, Reusir~g Object-Oriented Designs, University of Illinois tech report UIUCDCS91-1696 they offer the following definition: "An abstract class is a design of a set of objects that collaborate to carry out a set of responsibilities. Thus, a framework is a set of object classes that collaborate to execute defined sets of5 computing responsibilities." From a programming standpoint, frameworks are essentially groups of interconnected object classes that provide a pre-fabricated structure of a working application. For example, a user interface framework might provide the support and "default" behavior of drawing windows, scrollbars, menus, etc. Since frameworks are based on object technology, this behavior can be inherited 10 and overridden to allow developers to extend the framework and create customized solutions in a particular area of expertise. This is a major advantage over traditional programming since the programmer is not changing the original code, but rather extending the software. In addition, developers are not blindly working through layers of code because the framework provides architectural guidance and15 modeling but at the same time frees them to then supply the specific actions unique to the problem domain.
From a business perspective, frameworks can be viewed as a way to encapsulate or embody expertise in a particular knowledge area. Corporate 20 development organizations, Independent Software Vendors (ISV)s and ~ysl~ s integrators have acquired expertise in particular areas, such as manufacturing, accounting, or currency transactions as in our example earlier. This expertise is embodied in their code. Frameworks allow organizations to capture and package the common characteristics of that expertise by embodying it in the organization's code.
25 First, this allows developers to create or extend an application that utilizes the expertise, thus the problem gets solved once and the business rules and design are enforced and used consistently. Also, frameworks and the embodied expertise behind the frameworks have a strategic asset implication for those organizationswho have acquired expertise in vertical markets such as manufacturing, accounting, 30 or bio-technology would have a distribution mechanism for packaging, reselling, and deploying their expertise, and furthering the progress and dissemination of technology.
Historically, frameworks have only recently emerged as a mainstream 35 concept on personal computing platforms. This migration has been assisted by the availability of object-oriented languages, such as C++. Traditionally, C++ was found mostly on UNIX ~y~L~ s and researcher's workstations, rather than on Personal Computers in commercial settings. It is languages such as C++ and other wo 95,04962 2 1 ~ 4 7 3 ~ PCT/US94/00005 ~
object-oriented languages, such as Smal~ltalk and others, that enabled a number of university and research projects to pr~duce the precursors to today's commercialframeworks and class libraries. Some examples of these are InterViews from Stanford University, the Andrew toolkit from Carnegie-Mellon University and 5 University of Zurich's ET++ framework.
There are many kinds of frameworks depending on what level of the system you are concerned with and what kind of problem you are trying to solve. The types of frameworks range from application frameworks that assist in developing 10 the user interface, to lower level frameworks that provide basic system software services such as communications, printing, file systems support, graphics, etc.
Commercial examples of application frameworks are MacApp (Apple), Bedrock (Symantec), OWL (Borland), NeXTStep App Kit (NeXT), and Smalltalk-80 MVC
(ParcPlace) to name a few.
Programming with frameworks requires a new way of thinking for developers accustomed to other kinds of systems. In fact, it is not like "programming" at all in the traditional sense. In old-style operating systems such as DOS or UNIX, the developer's own program provides all of the structure. The 20 operating system provides services through system calls--the developer's program makes the calls when it needs the service and control returns when the service has been provided. The program structure is based on the flow-of-control, which is embodied in the code the developer writes.
When frameworks are used, this is reversed. The developer is no longer responsible for the flow-of-control. The developer must forego the tendency to understand programming tasks in term of flow of execution. Rather, the thinking must be in terms of the responsibilities of the objects, which must rely on the framework to determine when the tasks should execute. Routines written by the developer are activated by code the developer did not write and that the developer never even sees. This flip-flop in control flow can be a significant psychological barrier for developers experienced only in procedural programming. Once this is understood, however, framework programming requires much less work than other types of programming.
In the same way that an application framework provides the developer with prefab functionality, system frameworks, such as those included in a yrefelled embodiment, leverage the same concept by providing system level services, which ~4~3~
~VO 95/04962 PCT/US94/00005 developers, such as system programmers, use to subclass/override to create customized solutions. For example, consider a multi-media framework which could provide the foundation for supporting new and diverse devices such as audio, video, MIDI, animation, etc. The developer that needed to support a new 5 kind of device would have to write a device driver. To do this with a framework, the developer only needs to supply the characteristics and behavior that is specific to that new device.
The developer in this case supplies an implementation for certain member 10 functions that will be called by the multi-media framework. An immediate benefit to the developer is that the generic code needed for each category of device is already provided by the multi-media framework. This means less code for the device driver developer to write, test, and debug. Another example of using ~y~Lt~ s framework would be to have separate I/O frameworks for SCSI devices, NuBus 15 cards, and graphics devices. Because there is inherited functionality, each framework provides support for common functionality found in its device category.
Other developers could then depend on these consistent interfaces to all kinds of devices.
A ~referred embodiment takes the concept of frameworks and applies it throughout the entire ~yslelll. For the commercial or corporate developer, ~y~lelns integrator, or OEM, this means all the advantages that have been illustrated for a framework such as MacApp can be leveraged not only at the application level for such things as text and user interfaces, but also at the system level, for services such as graphics, multi-media, file systems, I/O, testing, etc. Application creation in the architecture of a preferred embodiment will essentially be like writing domain-specific puzzle pieces that adhere to the framework protocol. In this manner, the whole concept of programming changes. Instead of writing line after line of codethat calls multiple API hierarchies, software will be developed by deriving classes from the preexisting frameworks within this environment, and then adding new behavior and/or overriding inherited behavior as desired.
Thus, the developer's application becomes the collection of code that is written and shared with all the other framework applications. This is a powerfulconcept because developers will be able to build on each other's work. This alsoprovides the developer the flexibility to customize as much or as little as needed.
Some frameworks will be used just as they are. In some cases, the amount of customization will be minimal, so the puzzle piece the developer plugs in will be -WO 95/04962 2, ~ PCT/US94/000~5 small. In other cases, the developer may make very extensive modifications and create something completely new. With the overview of OOP above in mind, Figure 2 is an illustration of a display of the type produced by an object oriented operating system. It includes a command b-ar 200, a selected menu item 210, a text display window 220, and an overlying graphics display window 230. A selection of a particular graphic object, a circle, within the graphics window 240 is shown by means of the square dots 250 surrounding that object.
It is important to an appreciation of the nature of the invention to understand the concept of a "framework" and the relationship of a framework to "objects" and "object oriented programming". "MacApp: An Application Framework" by Kurt A. Schmucker, published in Byte magazine in August 1986 is an early article describing a framework and the basic concepts embodied therein,which is hereby fully incorporated by reference. An important property of objects is their ability to encapsulate data and methods for which the object is responsible.
That is, a generic command may be issued to an object without the need for any other object to know the internal details of how the object will carry out the command. By the same token, there is no need for global compatibility of coInm~nds, data, file names and the like and thus objects may be freely associated with one another. A framework is, in essence, a generic application comprising an association of classes of objects with which other objects may be associated, asnecessary, to form a more specific application. The framework, as an association of classes of objects with functional interrelationships between classes of objectsdefined therein may provide any desired degree of general or specific functionality of additional objects which may be associated with the framework.
A framework may thus be regarded as a system which provides an implied network of responsibilities between objects, provides for inheritance between classes of objects (e.g. data and methods of superclasses at higher hierarchical levels of classes of objects), and provides for calling of libraries in response to events. A
~y~lem formed as a framework may also be customized by the addition of objects which perform more specific functions and which may also override functions provided by the framework. Machine-specific and device-specific objects in various classes and subclasses of the framework allow the framework, itself, to be machine-and device-independent and of generalized applicability. Further, a particular framework is characterized by the interrelationships it establishes between objects and classes of objects in terms of division of responsibilities and inheritance and the functionality it thus achieves. A framework, itself, is also useful as a template for ~vo 9s/04962 2 1 ~ 4 7 3 0 ~CT~S94/01)(105 the development of specific applications in which customization and functional overrides may be provided as specific objects therein.
The present invention, a hit detection framework provides a mechanism to allow the application developer the flexibility to define the behavior for both 5 primitive and custom geometric types. Hit detection, enables an application todirectly manipulate graphic objects by defining a behavior for each geometric type.
The developer can specify criteria as to what determines a hit, the extent of the search for a hit and the action to be performed in the event a hit occurs. The framework provides a default search protocol for the primitive geometric types.
10 However, these default search protocols can be overridden and customized by the user.
MGraphic is a utility class for applications. It holds geometry related data including geometric objects, attributes (in a bundle) and hierarchies. Figure 3 shows various MGraphics and their corresponding geometries. These primitive geometric 15 types can be combined by the user to create simple and complex subclasses of MGraphic, as shown in Figure 4. The hit object framework allows customized hit rritPri~ to be specified for any MGraphic subclass. Criteria can be defined for each primitive and self-defined geometric class. The MGraphic subclass then calls thea~pro~riate method for the geometric types which they contain.
TGrafSearch & TGrafSearch3D are the principal objects containing the definitions of the criteria for hit detection and the action to be taken in the event a hit occurs. This information is used by the MGraphic::Find method to conduct thehit detection. When an application wants to perform hit detection on a group of MGraphics, the application creates a subclass of TGrafSearch, an object which defines (1) what constitutes a "hit" for each primitive geometric type; (2) the extent of the search, i.e. find one that satisfies or all that satisfy the criteria; and (3~ the action to be performed if a successful hit occurs. The action to be performed if a sllccessful hit occurs is application specific, but could include deleting, selecting or copying the selected object.
The first factor of TGrafSearch, hit criteria, is defined by the Find methods.
The Find methods take the primitive geometry transformation matrix and the bundle of attributes as parameters and the methods can be defined as required by the application. Some examples of Find methods include testing a point against the bounding box of the geometry or determining whether a geometry is completely enclosed by a polygon and whether its bundle has a particular color.
WO 95/04962 214 ~ 7 ~ ~ PCT/US94/00005 ~
The second type of information included in TGrafSearch defines the extent of the search for geometric objects which meet the hit criteria. An application maywant to find all graphic objects which satisfy the search criteria or may want to find only the first occurrence which satisfies the criteria. For example, an application may wish to find all circles located within a rectangle or to find only the first line which intersects a circle.
The third element of TGrafSearch hit object framework is the definition of the desired action to be performed when the search criteria is satisfied. Examples of such desired actions include the collection of MGraphics which satisfy the search criteria for processing, performance of an application specific action, or generation of a value which sllmmArizes the results of the search.
As an example of how hit objects are used, the code below shows TMySearch performing an application defined action on the first MGraphic which satisfies the criteria of intersection with a circle defined about the cursor.
/ / TMySearch is a subclass of TGrafSearch TMySearch searcher( GetMousePosition(), kHitRadius );
for (myGraphic = graphicList->First();
(myGraphic && myGraphic->Find( searcher ) !=
TGrafSeach!:kDoneSearching);
myGraphic = graphicList->Next() ) TGrafSearch defines many routines of the form virtual EFindResult Find(const TGSomething& geometry, const GrafMatrix&, .. matrix, const TGrafBundle& b) for each type of primitive geometry. These methods define the criteria the TGrafSearch uses to determine if a hit has occurred. They retum a result, EFindResult, which has one of two values, kDoneSearching, which indicates that the search can be stopped or kContinueSearching, which in~ic~t~ that the search 30 must continue. Two other routines, PushGraphic and PopGraphic are defined in TGrafSearch and both routines are used to regulate the behavior of the MGraphic as a whole. PushGraphic is a method which is used both to start the search within aspecific MGraphic and to implement hierarchical MGraphics (to be discussed infra).
PopGraphic retums the search status for the entire MGraphic. For example, if the35 application should search all MGraphics in the database, then PopGraphic is set to always return kContinueSearching.
21447~0 ~VO 95/04g62 PCT/US94/00005 A further example demonstrates the use of the second factor defined by TGrafSearch regarding the extent of the search to be performed. The code that follows is an example of both the routines used within MGraphics and those used to regulate the behavior of the MGraphic as a whole. The first TGrafSearch subclass, 5 TIntersectsGrafSearch, finds first the item which intersect a rectangle, TGRect, while the second subclass, TContainsGrafSearch, finds all of the items which are completely contained within a rectangle, TGRect.
The pseudo code for TIntersectsGrafSearch is as follows:
class TIntersectsGrafSearch: public TGrafSearch {
TIntersectsGrafSearch( const TGRect& bounds ) fBoundsRect = bounds;
initialize list of intersecting MGraphics to empty EFindResult Find( const TGRect& const TGrafMatrix&, const TGrafBundle& ) / / As soon as an intersection is found, return "done", because the rest of the / / MGraphic need not be searched.
if (fBoundsRect.Intersects( r )) if fGraphic != NIL, add fGraphic to list of intersecting objects fGraphic = NIL; / / So it isn't added twice return kDoneSearching;
else return kContineSearching;
// Other geometric primitives are defined similarly void PushGraphic( MGraphic * graphic ) fGraphic = graphic;
EFindResult PopGraphic() // Pop Graphic stack & Return kContineSearching so the client will search all MGraphics return kContineSearching;
21~73~
WO 9~/04962 PCT/US94/00005 The pseudo code for TContainsGrafSearch is as follows:
class TContainsGrafSearch: public TGrafSearch {
TContainsGrafSearch ( const TGRect& bounds ) fBoundsRect = bounds;
0 initialize list of contained MGraphics to empty EFindResult Find( const TGRect& r, const TGrafBundle& ) if (! fGraphic) return kDoneSearching; // Graphic is not contained // Stop the search if a geometry outside fBoundsRect is found, since / / to qualify everything must be contained within it.
if (fBoundsRect.Contains( r )) return kContineSearching;
{else fGraphic = NIL / / Flag graphic as not contained return kDoneSearching;
/ / Other geometric primitives are defined similarly void PushGraphic( MGraphic * graphic ) {
fGraphic = graphic;
EFindResult PopGraphic() if fGraphic != NL, add fGraphic to list of contained objects fGraphic = NIL; / / So it isn't added twice // Return kContineSearching so the client will search all MGraphics return kContineSearching;
}
The framework also provides mechanisms to overcome the problems associated with hit testing of hierarchical data, the use of an MGraphic in multiple instances in an object. Figure 5 shows a bicycle, with multiple instances of the 214~7~0 ~VO 95/04962 PCT/US94/00005 wheel MGraphic. This type of data presents a problem because the return of only a pointer to a wheel will not uniquely identify the particular wheel on which the user has actuated (i.e. "clicked") the pointer. Therefore, it is necessary to distinguish between multiple instances of the same MGraphic. The framework accomplishes this by recording the path to the particular instance of the MGraphic which is desired. Figure 6 illustrates how a path is used to identify the selected wheel on the bicycle. For example, to hit the rear wheel (object D), the path would be A, B, D.
The framework implements the hit testing of hierarchical MGraphics using the PushGraphic and PopGraphic methods of the TGrafSearch class. These methods take as parameters the MGraphic pointer, the bundle and the matrix for the particular group. If a hit occurs, PushGraphic can record the accumulated path which is a collection of transforms and pointers to groups. The following pseudocode illustrates a find routine for a TGroup, a group of MGraphics.
TGraphicGroup::Find( const TGrafSearch& h ) {
h.PushGraphic( *this, fMatrix, GetBundle() );
for (each child node &&
(child->Find( TGrafSearch ) == TGrafSearch::kContinueSearching ) h.PopGraphic();
}
In addition to the subclasses of TGrafSearch which define the hit criteria, the extent of the search and the action to be taken for a hit, TGrafSearch can have subclasses which store information regarding the geometrically important features of the hit object. The information can be used by the application in a variety of 25 ways, for example in defining "snap to" behavior.
Figure 7 is a flowchart illustrating the detailed logic of a hit (picking) operation in accordance with a preferred embodiment. Processing commences at terminal 700 and immediately passes to function block 710 to obtain the next graphic. Then, a test is performed at decision block 720 to determine if the graphic is 30 nil. If so, then hit data is obtained from the grafsearch object as shown in function block 750, the command associated with the graphic hit/pick is executed as shown in function block 760, and processing is completed at terminal 770. If the graphic tests negative at decision block 720, then at function block 730, a function call to the graphic search routine is invoked as shown in function block 730 and detailed in35 Figure 8. Value is set as a result of the function call and a test is performed at decision block 740 to determine if searching should continue based on value. If searching should not continue, then processing passes to function block 750 and hit 214473~
-1~
data is obtained from the grafsearch object, then, the command associated with the graphic hit/pick is executed as show~ in function block 760, and processing is completed at terminal 770.
Figure 8 is a flowchart illustrating the detailed logic for a graphic find operation in accordance with a preferred embodiment. Processing commences at function block 800, where the graphic is pushed onto a stack. Then, at function block 810, geometries of the search are defined to grafsearch, a function call to locate the graphic is made at function block 820, and detailed in Figure 9; and a test is performed at decision block 830 to determine if the value returned from the function call indicates that the graphic was located. If so, then processing is resumed by passing control via label 850 to Figure 7, label 788. If not, then value is set equal to the value of the graphic on the stack, and control is passed via label 850 to Figure 7, label 788.
Figure 9 is a flowchart illustrating the detailed logic for a graphic search operation in accordance with a preferred embodiment. Processing commences at function block 900 where hit detection is performed. Then, at decision block 910, a test is performed to determine if a graphic was hit. If not, then control is returned to label 888 of Figure 8. If a graphic was hit, then another test is performed at decision block 920 to determine if the search should continue. If so, then value is set equal to a value indicative of continue searching. If not, then value is set equal to a value indicative of done searching. In either case, control is returned from the function to the calling routine. Figure 10 and 11 illustrate various two dimensional (2D) objects in accordance with a preferred embodiment. 3D surfaces are shown atlabel 1000, 3D curves are presented at 1010, 3D line and polyline are presented at 1020 and a 3D box is presented at 1030. In Figure 11, an example of a 2D font 1100 and a graphic area 1110 are illustrated.
While the invention has been described in terms of a single preferred embodiment, those skilled in the art will recognize that the invention can be practiced with modification within the spirit and scope of the appended claims.
BACKGROUND OF THE INVENTION
The present invention generally relates to a mechanism for "hit" detection and, more particularly, to a hit detection mechanism in an object oriented 5 programming (OOP) environment. The subject invention is a framework ~y~Le which allows a progr~mm~r or applications developer to customize the search rrit~riA for graphic objects so that an application can identify objects on which to perform a specified action. The invention is disclosed in terms of a ~reL~lled embodiment which uses a popular object oriented programming language, C++, but 10 the principles are applicable to other computer programming languages both object oriented and procedural.
Description of the Prior Art Object oriented programming (OOP) is the ~refelled environment for building user-friendly, intelligent computer software. Key elements of OOP are data 15 encapsulation, inheritance and polymorphism. These elements may be used to generate a graphical user interface (GUI), typically charact~ri7etl by a windowing ellvi~ol~ment having icons, mouse cursors and menus. While these three key elements are common to OOP languages, most OOP languages implement the three key elements differently.
Examples of OOP languages are Smalltalk, Object Pascal and C++. Sm~llt~lk is actually more than a language; it might more accurately be characterized as aprogramming environment. Smalltalk was developed in the Learning Research Group at Xerox's Palo Alto Research Center (PARC) in the early 1970s. In Smalltalk, a m~ss~ge is sent to an object to evaluate the object itself. Messages perform a task similar to that of function calls in conventional programming languages. The programmer does not need to be concerned with the type of data; rather, the pro~ er need only be concerned with creating the right order of a m~s~ge and using the right message. Object Pascal is the language used for Apple's Macintosh(~) computers. Apple developed Object Pascal with the collaboration of Niklaus Wirth, the designer of Pascal. C++ was developed by Bjarne Stroustrup at the AT&T Bell Laboratories in 1983 as an extension of C. The key concept of C++ is class, which is a user-defined type. Classes provide object oriented programming features. C++
modules are compatible with C modules and can be linked freely so that existing C
libraries may be used with C++ programs. The most widely used object based and 21~30 object oriented programming languages trace their heritage to Simula developed in the 1960s by O-J. Dahl, B. Myhrhaug and K. Nygrad of Norway. Further informationon the subject of OOP may be had by reference to Object Oriented Design with Applications by Grady Booch, the Benjamin/Cummings Publishing Co., Inc., 5 Redwood City, Calif. (1991).
There has been a long felt need in the art for a developer of an application to be able to identify geometric objects, to define custQmi7e~1 search criteria for each geometric object and to specify the performance of an action based on the results of the search. To date, no system has been developed which addresses this need.
SUMMARY OF THE INVENTION
It is therefore an object of the present invention to provide an object orientedframework for defining hit criteria for geometric types. The criteria can be customized by the application developer and can specify the requirements for a hit 15 (pick) or a find, the extent of the search to be performed and the action to take when a hit (pick) or find is s~lcc~qsful.
According to the invention, there is provided a system for defining hit or find criteria for geometric types. The system uses this criteria to directly manipulate graphic objects which conform to the geometric type. The developer of an 20 application can also specify a specific hit criteria for two dimensional (2D) and three dimensional (3D) graphic objects which they have created.
BRIEF DESCRI1~rION OF THE DRAWINGS
The foregoing and other objects, aspects and advantages will be better 25 un.ler~stood from the following detailed description of a preferred embodiment of the invention with reference to the drawings, in which:
Figure 1 is a block diagram of a personal computer system of the type used in the practice of the subject invention;
Figure 2 is a screen print of a display in accordance with a plefeLled 30 embodiment;
Figure 3 is an illustration of various MGraphics and their geometries in accordance with a preferred embodiment;
2l44r~ ~G
~WO 95/04g62 PCT/US94/00005 Figure 4 shows the combination of primitive geometries to form simple and complex subclasses of MGraphic in accordance with a ~ref~lled embodiment;
Figure 5 illustrates an example of a graphic object, a bicycle, with many instances of the same MGraphic, a wheel in accordance with a preferred 5 embodiment;
Figure 6 illustrates the use of a path to record the correct instance for a hierarchical object in accordance with a preferred embodiment;
Figure 7 is a flowchart illustrating the detailed logic of a hit (picking) operation in accordance with a ~ref~lled embodiment;
Figure 8 is a flowchart illustrating the detailed logic for a graphic find operation in accordance with a preferred embodiment;
Figure 9 is a flowchart illustrating the detailed logic for a graphic search operation in accordance with a preferred embodiment; and Figure 10 and 11 illustrate various three dimensional (3D) objects in 15 accordance with a preferred embodiment.
DETAILED DESCRI1~rION OF A PREFERRED
EMBODIMENT OF THE INVENTION
The invention is preferably practiced in the context of an operating ~ysL~
20 resident on a personal computer such as the IBM (~) PS/2 (~ or Apple ~) Macintosh computer. A representative hardware environment is depicted in Figure 1, which illustrates a typical hardware configuration of a workstation in accordance with the subject invention having a central processing unit 10, such as a conventional microprocessor, and a number of other units inleLcol~l~ected via a ~y~L~ bus 12.25 The workstation shown in Figure 1 includes a Random Access Memory (RAM) 14, Read Only Memory (ROM) 16, an I/O adapter 18 for connecting peripheral devices such as disk units 20 to the bus, a user interface adapter 22 for connecting a keyboard 24, a mouse 26, a speaker 28, a microphone 32, and/or other user interface devices such as a touch screen device (not shown) to the bus, a communication adapter 3430 for connecting the workstation to a data processing network and a display adapter 36 for connecting the bus to a display device 38. The workstation has resident thereon an operating ~ysLell~ such as the Apple System/7 (~) operating system.
WO 95/04962 21~ ~ 7 3 ~ PCT/US94/00005 ~
In a pLerelled embodiment, the invention is implemented in the C++
programming language using object oriented programming techniques. As will be understood by those skilled in the art, Object-Oriented Programming (OOP) objects are software entities comprising data structures and operations on the data.
5 Together, these elements enable objects to model virtually any real-world entity in terms of its characteristics, represented by its data elements, and its behavior, represented by its data manipulation functions. In this way, objects can model concrete things like people and computers, and they can model abstract concepts like numbers or geometrical concepts. The benefits of object technology arise out of 10 three basic principles: encapsulation, polymorphism and inheritance.
Objects hide, or encapsulate, the internal structure of their data and the algorithms by which their functions work. Instead of exposing these implementation details, objects present interfaces that represent their abstractions 15 cleanly with no extraneous information. Polymorphism takes encapsulation a step further. The idea is many shapes, one interface. A software component can make arequest of another component without knowing exactly what that component is.
The component that receives the request interprets it and figures out according to its variables and data, how to execute the request. The third principle is inheritance, 20 which allows developers to reuse pre-existing design and code. This capability allows developers to avoid creating software from scratch. Rather, through inheritance, developers derive subclasses that inherit behaviors, which the developer then customizes to meet their particular needs.
A prior art approach is to layer objects and class libraries in a procedural environment. Many application frameworks on the market take this design approach. In this design, there are one or more object layers on top of a monolithic operating system. While this approach utilizes all the principles of encapsulation, polymorphism, and inheritance in the object layer, and is a substantial improvement over procedural programming techniques, there are limitations to this approach. These difficulties arise from the fact that while it is easy for a developer to reuse their own objects, it is difficult to use objects from other systems and the developer still needs to reach into the lower non-object layers with procedural Operating System (OS) calls.
Another aspect of object oriented programming is a framework approach to application development. One of the most rational definitions of frameworks comefrom Ralph E. Johnson of the University of Illinois and Vincent F. Russo of Purdue.
2~7~
~WO 95/04g62 PCT/US94/00005 In their 1991 paper, Reusir~g Object-Oriented Designs, University of Illinois tech report UIUCDCS91-1696 they offer the following definition: "An abstract class is a design of a set of objects that collaborate to carry out a set of responsibilities. Thus, a framework is a set of object classes that collaborate to execute defined sets of5 computing responsibilities." From a programming standpoint, frameworks are essentially groups of interconnected object classes that provide a pre-fabricated structure of a working application. For example, a user interface framework might provide the support and "default" behavior of drawing windows, scrollbars, menus, etc. Since frameworks are based on object technology, this behavior can be inherited 10 and overridden to allow developers to extend the framework and create customized solutions in a particular area of expertise. This is a major advantage over traditional programming since the programmer is not changing the original code, but rather extending the software. In addition, developers are not blindly working through layers of code because the framework provides architectural guidance and15 modeling but at the same time frees them to then supply the specific actions unique to the problem domain.
From a business perspective, frameworks can be viewed as a way to encapsulate or embody expertise in a particular knowledge area. Corporate 20 development organizations, Independent Software Vendors (ISV)s and ~ysl~ s integrators have acquired expertise in particular areas, such as manufacturing, accounting, or currency transactions as in our example earlier. This expertise is embodied in their code. Frameworks allow organizations to capture and package the common characteristics of that expertise by embodying it in the organization's code.
25 First, this allows developers to create or extend an application that utilizes the expertise, thus the problem gets solved once and the business rules and design are enforced and used consistently. Also, frameworks and the embodied expertise behind the frameworks have a strategic asset implication for those organizationswho have acquired expertise in vertical markets such as manufacturing, accounting, 30 or bio-technology would have a distribution mechanism for packaging, reselling, and deploying their expertise, and furthering the progress and dissemination of technology.
Historically, frameworks have only recently emerged as a mainstream 35 concept on personal computing platforms. This migration has been assisted by the availability of object-oriented languages, such as C++. Traditionally, C++ was found mostly on UNIX ~y~L~ s and researcher's workstations, rather than on Personal Computers in commercial settings. It is languages such as C++ and other wo 95,04962 2 1 ~ 4 7 3 ~ PCT/US94/00005 ~
object-oriented languages, such as Smal~ltalk and others, that enabled a number of university and research projects to pr~duce the precursors to today's commercialframeworks and class libraries. Some examples of these are InterViews from Stanford University, the Andrew toolkit from Carnegie-Mellon University and 5 University of Zurich's ET++ framework.
There are many kinds of frameworks depending on what level of the system you are concerned with and what kind of problem you are trying to solve. The types of frameworks range from application frameworks that assist in developing 10 the user interface, to lower level frameworks that provide basic system software services such as communications, printing, file systems support, graphics, etc.
Commercial examples of application frameworks are MacApp (Apple), Bedrock (Symantec), OWL (Borland), NeXTStep App Kit (NeXT), and Smalltalk-80 MVC
(ParcPlace) to name a few.
Programming with frameworks requires a new way of thinking for developers accustomed to other kinds of systems. In fact, it is not like "programming" at all in the traditional sense. In old-style operating systems such as DOS or UNIX, the developer's own program provides all of the structure. The 20 operating system provides services through system calls--the developer's program makes the calls when it needs the service and control returns when the service has been provided. The program structure is based on the flow-of-control, which is embodied in the code the developer writes.
When frameworks are used, this is reversed. The developer is no longer responsible for the flow-of-control. The developer must forego the tendency to understand programming tasks in term of flow of execution. Rather, the thinking must be in terms of the responsibilities of the objects, which must rely on the framework to determine when the tasks should execute. Routines written by the developer are activated by code the developer did not write and that the developer never even sees. This flip-flop in control flow can be a significant psychological barrier for developers experienced only in procedural programming. Once this is understood, however, framework programming requires much less work than other types of programming.
In the same way that an application framework provides the developer with prefab functionality, system frameworks, such as those included in a yrefelled embodiment, leverage the same concept by providing system level services, which ~4~3~
~VO 95/04962 PCT/US94/00005 developers, such as system programmers, use to subclass/override to create customized solutions. For example, consider a multi-media framework which could provide the foundation for supporting new and diverse devices such as audio, video, MIDI, animation, etc. The developer that needed to support a new 5 kind of device would have to write a device driver. To do this with a framework, the developer only needs to supply the characteristics and behavior that is specific to that new device.
The developer in this case supplies an implementation for certain member 10 functions that will be called by the multi-media framework. An immediate benefit to the developer is that the generic code needed for each category of device is already provided by the multi-media framework. This means less code for the device driver developer to write, test, and debug. Another example of using ~y~Lt~ s framework would be to have separate I/O frameworks for SCSI devices, NuBus 15 cards, and graphics devices. Because there is inherited functionality, each framework provides support for common functionality found in its device category.
Other developers could then depend on these consistent interfaces to all kinds of devices.
A ~referred embodiment takes the concept of frameworks and applies it throughout the entire ~yslelll. For the commercial or corporate developer, ~y~lelns integrator, or OEM, this means all the advantages that have been illustrated for a framework such as MacApp can be leveraged not only at the application level for such things as text and user interfaces, but also at the system level, for services such as graphics, multi-media, file systems, I/O, testing, etc. Application creation in the architecture of a preferred embodiment will essentially be like writing domain-specific puzzle pieces that adhere to the framework protocol. In this manner, the whole concept of programming changes. Instead of writing line after line of codethat calls multiple API hierarchies, software will be developed by deriving classes from the preexisting frameworks within this environment, and then adding new behavior and/or overriding inherited behavior as desired.
Thus, the developer's application becomes the collection of code that is written and shared with all the other framework applications. This is a powerfulconcept because developers will be able to build on each other's work. This alsoprovides the developer the flexibility to customize as much or as little as needed.
Some frameworks will be used just as they are. In some cases, the amount of customization will be minimal, so the puzzle piece the developer plugs in will be -WO 95/04962 2, ~ PCT/US94/000~5 small. In other cases, the developer may make very extensive modifications and create something completely new. With the overview of OOP above in mind, Figure 2 is an illustration of a display of the type produced by an object oriented operating system. It includes a command b-ar 200, a selected menu item 210, a text display window 220, and an overlying graphics display window 230. A selection of a particular graphic object, a circle, within the graphics window 240 is shown by means of the square dots 250 surrounding that object.
It is important to an appreciation of the nature of the invention to understand the concept of a "framework" and the relationship of a framework to "objects" and "object oriented programming". "MacApp: An Application Framework" by Kurt A. Schmucker, published in Byte magazine in August 1986 is an early article describing a framework and the basic concepts embodied therein,which is hereby fully incorporated by reference. An important property of objects is their ability to encapsulate data and methods for which the object is responsible.
That is, a generic command may be issued to an object without the need for any other object to know the internal details of how the object will carry out the command. By the same token, there is no need for global compatibility of coInm~nds, data, file names and the like and thus objects may be freely associated with one another. A framework is, in essence, a generic application comprising an association of classes of objects with which other objects may be associated, asnecessary, to form a more specific application. The framework, as an association of classes of objects with functional interrelationships between classes of objectsdefined therein may provide any desired degree of general or specific functionality of additional objects which may be associated with the framework.
A framework may thus be regarded as a system which provides an implied network of responsibilities between objects, provides for inheritance between classes of objects (e.g. data and methods of superclasses at higher hierarchical levels of classes of objects), and provides for calling of libraries in response to events. A
~y~lem formed as a framework may also be customized by the addition of objects which perform more specific functions and which may also override functions provided by the framework. Machine-specific and device-specific objects in various classes and subclasses of the framework allow the framework, itself, to be machine-and device-independent and of generalized applicability. Further, a particular framework is characterized by the interrelationships it establishes between objects and classes of objects in terms of division of responsibilities and inheritance and the functionality it thus achieves. A framework, itself, is also useful as a template for ~vo 9s/04962 2 1 ~ 4 7 3 0 ~CT~S94/01)(105 the development of specific applications in which customization and functional overrides may be provided as specific objects therein.
The present invention, a hit detection framework provides a mechanism to allow the application developer the flexibility to define the behavior for both 5 primitive and custom geometric types. Hit detection, enables an application todirectly manipulate graphic objects by defining a behavior for each geometric type.
The developer can specify criteria as to what determines a hit, the extent of the search for a hit and the action to be performed in the event a hit occurs. The framework provides a default search protocol for the primitive geometric types.
10 However, these default search protocols can be overridden and customized by the user.
MGraphic is a utility class for applications. It holds geometry related data including geometric objects, attributes (in a bundle) and hierarchies. Figure 3 shows various MGraphics and their corresponding geometries. These primitive geometric 15 types can be combined by the user to create simple and complex subclasses of MGraphic, as shown in Figure 4. The hit object framework allows customized hit rritPri~ to be specified for any MGraphic subclass. Criteria can be defined for each primitive and self-defined geometric class. The MGraphic subclass then calls thea~pro~riate method for the geometric types which they contain.
TGrafSearch & TGrafSearch3D are the principal objects containing the definitions of the criteria for hit detection and the action to be taken in the event a hit occurs. This information is used by the MGraphic::Find method to conduct thehit detection. When an application wants to perform hit detection on a group of MGraphics, the application creates a subclass of TGrafSearch, an object which defines (1) what constitutes a "hit" for each primitive geometric type; (2) the extent of the search, i.e. find one that satisfies or all that satisfy the criteria; and (3~ the action to be performed if a successful hit occurs. The action to be performed if a sllccessful hit occurs is application specific, but could include deleting, selecting or copying the selected object.
The first factor of TGrafSearch, hit criteria, is defined by the Find methods.
The Find methods take the primitive geometry transformation matrix and the bundle of attributes as parameters and the methods can be defined as required by the application. Some examples of Find methods include testing a point against the bounding box of the geometry or determining whether a geometry is completely enclosed by a polygon and whether its bundle has a particular color.
WO 95/04962 214 ~ 7 ~ ~ PCT/US94/00005 ~
The second type of information included in TGrafSearch defines the extent of the search for geometric objects which meet the hit criteria. An application maywant to find all graphic objects which satisfy the search criteria or may want to find only the first occurrence which satisfies the criteria. For example, an application may wish to find all circles located within a rectangle or to find only the first line which intersects a circle.
The third element of TGrafSearch hit object framework is the definition of the desired action to be performed when the search criteria is satisfied. Examples of such desired actions include the collection of MGraphics which satisfy the search criteria for processing, performance of an application specific action, or generation of a value which sllmmArizes the results of the search.
As an example of how hit objects are used, the code below shows TMySearch performing an application defined action on the first MGraphic which satisfies the criteria of intersection with a circle defined about the cursor.
/ / TMySearch is a subclass of TGrafSearch TMySearch searcher( GetMousePosition(), kHitRadius );
for (myGraphic = graphicList->First();
(myGraphic && myGraphic->Find( searcher ) !=
TGrafSeach!:kDoneSearching);
myGraphic = graphicList->Next() ) TGrafSearch defines many routines of the form virtual EFindResult Find(const TGSomething& geometry, const GrafMatrix&, .. matrix, const TGrafBundle& b) for each type of primitive geometry. These methods define the criteria the TGrafSearch uses to determine if a hit has occurred. They retum a result, EFindResult, which has one of two values, kDoneSearching, which indicates that the search can be stopped or kContinueSearching, which in~ic~t~ that the search 30 must continue. Two other routines, PushGraphic and PopGraphic are defined in TGrafSearch and both routines are used to regulate the behavior of the MGraphic as a whole. PushGraphic is a method which is used both to start the search within aspecific MGraphic and to implement hierarchical MGraphics (to be discussed infra).
PopGraphic retums the search status for the entire MGraphic. For example, if the35 application should search all MGraphics in the database, then PopGraphic is set to always return kContinueSearching.
21447~0 ~VO 95/04g62 PCT/US94/00005 A further example demonstrates the use of the second factor defined by TGrafSearch regarding the extent of the search to be performed. The code that follows is an example of both the routines used within MGraphics and those used to regulate the behavior of the MGraphic as a whole. The first TGrafSearch subclass, 5 TIntersectsGrafSearch, finds first the item which intersect a rectangle, TGRect, while the second subclass, TContainsGrafSearch, finds all of the items which are completely contained within a rectangle, TGRect.
The pseudo code for TIntersectsGrafSearch is as follows:
class TIntersectsGrafSearch: public TGrafSearch {
TIntersectsGrafSearch( const TGRect& bounds ) fBoundsRect = bounds;
initialize list of intersecting MGraphics to empty EFindResult Find( const TGRect& const TGrafMatrix&, const TGrafBundle& ) / / As soon as an intersection is found, return "done", because the rest of the / / MGraphic need not be searched.
if (fBoundsRect.Intersects( r )) if fGraphic != NIL, add fGraphic to list of intersecting objects fGraphic = NIL; / / So it isn't added twice return kDoneSearching;
else return kContineSearching;
// Other geometric primitives are defined similarly void PushGraphic( MGraphic * graphic ) fGraphic = graphic;
EFindResult PopGraphic() // Pop Graphic stack & Return kContineSearching so the client will search all MGraphics return kContineSearching;
21~73~
WO 9~/04962 PCT/US94/00005 The pseudo code for TContainsGrafSearch is as follows:
class TContainsGrafSearch: public TGrafSearch {
TContainsGrafSearch ( const TGRect& bounds ) fBoundsRect = bounds;
0 initialize list of contained MGraphics to empty EFindResult Find( const TGRect& r, const TGrafBundle& ) if (! fGraphic) return kDoneSearching; // Graphic is not contained // Stop the search if a geometry outside fBoundsRect is found, since / / to qualify everything must be contained within it.
if (fBoundsRect.Contains( r )) return kContineSearching;
{else fGraphic = NIL / / Flag graphic as not contained return kDoneSearching;
/ / Other geometric primitives are defined similarly void PushGraphic( MGraphic * graphic ) {
fGraphic = graphic;
EFindResult PopGraphic() if fGraphic != NL, add fGraphic to list of contained objects fGraphic = NIL; / / So it isn't added twice // Return kContineSearching so the client will search all MGraphics return kContineSearching;
}
The framework also provides mechanisms to overcome the problems associated with hit testing of hierarchical data, the use of an MGraphic in multiple instances in an object. Figure 5 shows a bicycle, with multiple instances of the 214~7~0 ~VO 95/04962 PCT/US94/00005 wheel MGraphic. This type of data presents a problem because the return of only a pointer to a wheel will not uniquely identify the particular wheel on which the user has actuated (i.e. "clicked") the pointer. Therefore, it is necessary to distinguish between multiple instances of the same MGraphic. The framework accomplishes this by recording the path to the particular instance of the MGraphic which is desired. Figure 6 illustrates how a path is used to identify the selected wheel on the bicycle. For example, to hit the rear wheel (object D), the path would be A, B, D.
The framework implements the hit testing of hierarchical MGraphics using the PushGraphic and PopGraphic methods of the TGrafSearch class. These methods take as parameters the MGraphic pointer, the bundle and the matrix for the particular group. If a hit occurs, PushGraphic can record the accumulated path which is a collection of transforms and pointers to groups. The following pseudocode illustrates a find routine for a TGroup, a group of MGraphics.
TGraphicGroup::Find( const TGrafSearch& h ) {
h.PushGraphic( *this, fMatrix, GetBundle() );
for (each child node &&
(child->Find( TGrafSearch ) == TGrafSearch::kContinueSearching ) h.PopGraphic();
}
In addition to the subclasses of TGrafSearch which define the hit criteria, the extent of the search and the action to be taken for a hit, TGrafSearch can have subclasses which store information regarding the geometrically important features of the hit object. The information can be used by the application in a variety of 25 ways, for example in defining "snap to" behavior.
Figure 7 is a flowchart illustrating the detailed logic of a hit (picking) operation in accordance with a preferred embodiment. Processing commences at terminal 700 and immediately passes to function block 710 to obtain the next graphic. Then, a test is performed at decision block 720 to determine if the graphic is 30 nil. If so, then hit data is obtained from the grafsearch object as shown in function block 750, the command associated with the graphic hit/pick is executed as shown in function block 760, and processing is completed at terminal 770. If the graphic tests negative at decision block 720, then at function block 730, a function call to the graphic search routine is invoked as shown in function block 730 and detailed in35 Figure 8. Value is set as a result of the function call and a test is performed at decision block 740 to determine if searching should continue based on value. If searching should not continue, then processing passes to function block 750 and hit 214473~
-1~
data is obtained from the grafsearch object, then, the command associated with the graphic hit/pick is executed as show~ in function block 760, and processing is completed at terminal 770.
Figure 8 is a flowchart illustrating the detailed logic for a graphic find operation in accordance with a preferred embodiment. Processing commences at function block 800, where the graphic is pushed onto a stack. Then, at function block 810, geometries of the search are defined to grafsearch, a function call to locate the graphic is made at function block 820, and detailed in Figure 9; and a test is performed at decision block 830 to determine if the value returned from the function call indicates that the graphic was located. If so, then processing is resumed by passing control via label 850 to Figure 7, label 788. If not, then value is set equal to the value of the graphic on the stack, and control is passed via label 850 to Figure 7, label 788.
Figure 9 is a flowchart illustrating the detailed logic for a graphic search operation in accordance with a preferred embodiment. Processing commences at function block 900 where hit detection is performed. Then, at decision block 910, a test is performed to determine if a graphic was hit. If not, then control is returned to label 888 of Figure 8. If a graphic was hit, then another test is performed at decision block 920 to determine if the search should continue. If so, then value is set equal to a value indicative of continue searching. If not, then value is set equal to a value indicative of done searching. In either case, control is returned from the function to the calling routine. Figure 10 and 11 illustrate various two dimensional (2D) objects in accordance with a preferred embodiment. 3D surfaces are shown atlabel 1000, 3D curves are presented at 1010, 3D line and polyline are presented at 1020 and a 3D box is presented at 1030. In Figure 11, an example of a 2D font 1100 and a graphic area 1110 are illustrated.
While the invention has been described in terms of a single preferred embodiment, those skilled in the art will recognize that the invention can be practiced with modification within the spirit and scope of the appended claims.
Claims (33)
1. An object based framework, comprising:
(a) means for defining a search protocol for a geometric type;
(b) means for detecting a graphic object;
(c) means for automatically generating, based on a comparison of the search protocol defined by the search protocol defining means and a detection of the graphic object by the detecting means, a result; and (d) means for producing an output in accordance with the result.
(a) means for defining a search protocol for a geometric type;
(b) means for detecting a graphic object;
(c) means for automatically generating, based on a comparison of the search protocol defined by the search protocol defining means and a detection of the graphic object by the detecting means, a result; and (d) means for producing an output in accordance with the result.
2. An object based framework as recited in claim 1, including means for modifying an image of the graphic object.
3. An object based framework as recited in claim 1, including means for calculating a value based on whether the graphic object satisfies the search protocol.
4. An object based framework as recited in claim 1, including means for selecting the graphic object for processing.
5. An object based framework as recited in claim 1, including means for defining a search protocol based on geometric attributes of an object.
6. An object based framework as recited in claim 5, wherein the geometric attributes are a point.
7. An object based framework as recited in claim 5, wherein the geometric attributes are a line.
8. An object based framework as recited in claim 5, wherein the geometric attributes are a rectangle.
9. An object based framework as recited in claim 5, wherein the geometric attributes are a cube.
10. An object based framework as recited in claim 5, wherein the geometric attributes are a sphere.
11. An object based framework as recited in claim 5, wherein the geometric attributes are a plurality of geometric figures.
12. An object based framework as recited in claim 1, including means for tuning the search to optimize precision.
13. An object based framework as recited in claim 1, including means for adjusting the search to detect relationships between a plurality of geometric figures.
14. An object based framework as recited in claim 1, including means for tuning the search to optimize speed.
15. An object based framework as recited in claim 13, including means for detecting a hit when a first geometric figure and a second geometric figure are within a predefined distance.
16. An object based framework as recited in claim 13, including means for detecting a hit when a first geometric figure is located behind a second geometric figure.
17. An object based framework as recited in claim 1, including means for dynamically forming a new search based on the search policy.
18. A method for manipulating graphic objects, the method comprising the steps of:
(a) defining a search protocol for a geometric type;
(b) detecting a graphic object;
(c) automatically generating, based on a comparison of the search protocol defining and a detection of the graphic object, a result; and (d) producing an output in accordance with the result.
(a) defining a search protocol for a geometric type;
(b) detecting a graphic object;
(c) automatically generating, based on a comparison of the search protocol defining and a detection of the graphic object, a result; and (d) producing an output in accordance with the result.
19. A method as recited in claim 18, wherein the output producing step includes modifying an image of the graphic object.
20. A method as recited in claim 18, wherein the output producing step includes calculating a value based on whether the graphic object satisfies the search protocol.
21. A method as recited in claim 18, wherein the output producing step includes the step of selecting the graphic object for processing.
22. A method as recited in claim 18, including the step of defining a search protocol based on geometric attributes of an object.
23. A method as recited in claim 22, wherein the geometric attributes are a point.
24. A method as recited in claim 22, wherein the geometric attributes are a line.
25. A method as recited in claim 22, wherein the geometric attributes are a rectangle.
26. A method as recited in claim 22, wherein the geometric attributes are a cube.
27. A method as recited in claim 22, wherein the geometric attributes are a sphere.
28. A method as recited in claim 22, wherein the geometric attributes are a plurality of geometric figures.
29. A method as recited in claim 22, including the step of tuning the search to optimize speed or precision.
30. A method as recited in claim 22, including the step of adjusting the search to detect relationships between a plurality of geometric figures.
31. A method as recited in claim 30, including the step of detecting a hit when a first geometric figure and a second geometric figure are within a predefined distance.
32. A method as recited in claim 30, including the step of detecting a hit when a first geometric figure is located behind a second geometric figure.
33. A method as recited in claim 22, including the step of dynamically forming a new search based on the search policy.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/102,079 US5479589A (en) | 1993-08-04 | 1993-08-04 | Object-oriented system for selecting a graphic image on a display |
| US102,079 | 1993-08-04 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2144730A1 true CA2144730A1 (en) | 1995-02-16 |
Family
ID=22288022
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002144730A Abandoned CA2144730A1 (en) | 1993-08-04 | 1994-01-03 | Object-oriented graphic picking system |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US5479589A (en) |
| EP (1) | EP0664022B1 (en) |
| JP (1) | JPH08503801A (en) |
| AU (1) | AU7090594A (en) |
| CA (1) | CA2144730A1 (en) |
| DE (1) | DE69404438T2 (en) |
| WO (1) | WO1995004962A1 (en) |
Families Citing this family (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5519818A (en) * | 1994-09-19 | 1996-05-21 | Taligent, Inc. | Object-oriented graphic picking system |
| GB2311151B (en) * | 1996-02-29 | 2000-11-15 | Jba Holdings Plc | An object browser and manipulation system |
| US5987245A (en) | 1996-07-01 | 1999-11-16 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture (#12) for a client-server state machine framework |
| US6304893B1 (en) | 1996-07-01 | 2001-10-16 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server event driven message framework in an interprise computing framework system |
| US6434598B1 (en) | 1996-07-01 | 2002-08-13 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server graphical user interface (#9) framework in an interprise computing framework system |
| US6266709B1 (en) | 1996-07-01 | 2001-07-24 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server failure reporting process |
| US5999972A (en) | 1996-07-01 | 1999-12-07 | Sun Microsystems, Inc. | System, method and article of manufacture for a distributed computer system framework |
| US5848246A (en) | 1996-07-01 | 1998-12-08 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server session manager in an interprise computing framework system |
| US6272555B1 (en) | 1996-07-01 | 2001-08-07 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server-centric interprise computing framework system |
| US6038590A (en) | 1996-07-01 | 2000-03-14 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server state machine in an interprise computing framework system |
| US5897670A (en) * | 1996-07-12 | 1999-04-27 | Sun Microsystems, Inc. | Method and system for efficient organization of selectable elements on a graphical user interface |
| US6275225B1 (en) | 1997-10-24 | 2001-08-14 | Sun Microsystems, Inc. | Method, apparatus, system and computer program product for a user-configurable graphical user interface |
| US6377288B1 (en) * | 1998-01-12 | 2002-04-23 | Xerox Corporation | Domain objects having computed attribute values for use in a freeform graphics system |
| US6018346A (en) * | 1998-01-12 | 2000-01-25 | Xerox Corporation | Freeform graphics system having meeting objects for supporting meeting objectives |
| US6509912B1 (en) * | 1998-01-12 | 2003-01-21 | Xerox Corporation | Domain objects for use in a freeform graphics system |
Family Cites Families (24)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4815029A (en) * | 1985-09-23 | 1989-03-21 | International Business Machines Corp. | In-line dynamic editor for mixed object documents |
| US4821220A (en) * | 1986-07-25 | 1989-04-11 | Tektronix, Inc. | System for animating program operation and displaying time-based relationships |
| US4885717A (en) * | 1986-09-25 | 1989-12-05 | Tektronix, Inc. | System for graphically representing operation of object-oriented programs |
| US4905162A (en) * | 1987-03-30 | 1990-02-27 | Digital Equipment Corporation | Evaluation system for determining analogy and symmetric comparison among objects in model-based computation systems |
| US4891630A (en) * | 1988-04-22 | 1990-01-02 | Friedman Mark B | Computer vision system with improved object orientation technique |
| US4953080A (en) * | 1988-04-25 | 1990-08-28 | Hewlett-Packard Company | Object management facility for maintaining data in a computer system |
| EP0347162A3 (en) * | 1988-06-14 | 1990-09-12 | Tektronix, Inc. | Apparatus and methods for controlling data flow processes by generated instruction sequences |
| US5041992A (en) * | 1988-10-24 | 1991-08-20 | University Of Pittsburgh | Interactive method of developing software interfaces |
| US5133075A (en) * | 1988-12-19 | 1992-07-21 | Hewlett-Packard Company | Method of monitoring changes in attribute values of object in an object-oriented database |
| US5050090A (en) * | 1989-03-30 | 1991-09-17 | R. J. Reynolds Tobacco Company | Object placement method and apparatus |
| US5060276A (en) * | 1989-05-31 | 1991-10-22 | At&T Bell Laboratories | Technique for object orientation detection using a feed-forward neural network |
| US5125091A (en) * | 1989-06-08 | 1992-06-23 | Hazox Corporation | Object oriented control of real-time processing |
| US5125039A (en) * | 1989-06-16 | 1992-06-23 | Hawkins Jeffrey C | Object recognition system |
| US5181162A (en) * | 1989-12-06 | 1993-01-19 | Eastman Kodak Company | Document management and production system |
| US5093914A (en) * | 1989-12-15 | 1992-03-03 | At&T Bell Laboratories | Method of controlling the execution of object-oriented programs |
| US5075848A (en) * | 1989-12-22 | 1991-12-24 | Intel Corporation | Object lifetime control in an object-oriented memory protection mechanism |
| US5321829A (en) * | 1990-07-20 | 1994-06-14 | Icom, Inc. | Graphical interfaces for monitoring ladder logic programs |
| US5299307A (en) * | 1990-08-17 | 1994-03-29 | Claris Corporation | Controls for drawing images on computer displays |
| JP2811501B2 (en) * | 1990-08-30 | 1998-10-15 | インターナショナル・ビジネス・マシーンズ・コーポレーション | Cursor movement control method and apparatus |
| US5151987A (en) * | 1990-10-23 | 1992-09-29 | International Business Machines Corporation | Recovery objects in an object oriented computing environment |
| US5119475A (en) * | 1991-03-13 | 1992-06-02 | Schlumberger Technology Corporation | Object-oriented framework for menu definition |
| US5375177A (en) * | 1991-09-27 | 1994-12-20 | E. I. Du Pont De Nemours And Company | Method of identifying and characterizing a valid object by color |
| CA2077324C (en) * | 1991-10-07 | 1997-06-24 | Michael R. Campanelli | Image editing system and method having improved automatic object selection |
| US5386568A (en) * | 1992-12-01 | 1995-01-31 | Yamaha Corporation | Apparatus and method for linking software modules |
-
1993
- 1993-08-04 US US08/102,079 patent/US5479589A/en not_active Expired - Lifetime
-
1994
- 1994-01-03 AU AU70905/94A patent/AU7090594A/en not_active Abandoned
- 1994-01-03 JP JP7506385A patent/JPH08503801A/en active Pending
- 1994-01-03 DE DE69404438T patent/DE69404438T2/en not_active Expired - Lifetime
- 1994-01-03 EP EP94919965A patent/EP0664022B1/en not_active Expired - Lifetime
- 1994-01-03 CA CA002144730A patent/CA2144730A1/en not_active Abandoned
- 1994-01-03 WO PCT/US1994/000005 patent/WO1995004962A1/en active IP Right Grant
Also Published As
| Publication number | Publication date |
|---|---|
| AU7090594A (en) | 1995-02-28 |
| WO1995004962A1 (en) | 1995-02-16 |
| DE69404438D1 (en) | 1997-09-04 |
| JPH08503801A (en) | 1996-04-23 |
| US5479589A (en) | 1995-12-26 |
| DE69404438T2 (en) | 1998-02-19 |
| EP0664022B1 (en) | 1997-07-23 |
| EP0664022A1 (en) | 1995-07-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5519818A (en) | Object-oriented graphic picking system | |
| US5710896A (en) | Object-oriented graphic system with extensible damage repair and drawing constraints | |
| EP0664028B1 (en) | Object-oriented system locator system | |
| US6281896B1 (en) | Data processor controlled interface with multiple tree of elements views expandable into individual detail views | |
| US5621434A (en) | Cursor manipulation system and method | |
| US5396626A (en) | Object-oriented locator system | |
| JP3798015B2 (en) | Place object system | |
| US6151024A (en) | Data processor controlled display interface with tree hierarchy of elements view expandable into multiple detailed views | |
| EP0494032B1 (en) | Icon object interface system and method | |
| EP0713594B1 (en) | Object-oriented rendering system | |
| US5912666A (en) | Object-oriented global cursor tool | |
| US5479589A (en) | Object-oriented system for selecting a graphic image on a display | |
| JPH08511118A (en) | Container object system | |
| WO1995008147A1 (en) | Object-oriented audio record/playback system | |
| US5634057A (en) | Place object display system having place objects selected in response to a user identifier | |
| US6111579A (en) | Data processor controlled display system with a tree hierarchy of elements view having virtual nodes | |
| Paterno' et al. | A Semantics‐based Approach for the Design and Implementation of Interaction Objects | |
| US5790132A (en) | Image rendering system with extensible mechanism for providing visual user feedback when an image graphic is selected | |
| US6581203B1 (en) | Technique for visually creating and adding members to a class | |
| CA2154451C (en) | Object-oriented cursor tool | |
| Sendler | CAD & Office Integration: OLE for Design and Modeling. A New Technology for CA Software | |
| Mitchell et al. | DRIVE: An environment for the organised construction of user interfaces to data. |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Discontinued |