DE69404438T2

DE69404438T2 - Objektorientiertes graphisches auswahlsystem

Info

Publication number: DE69404438T2
Application number: DE69404438T
Authority: DE
Inventors: Rajiv Jain; John Peterson; Robert Seidl
Original assignee: Taligent Inc
Current assignee: Object Technology Licensing Corp
Priority date: 1993-08-04
Filing date: 1994-01-03
Publication date: 1998-02-19
Anticipated expiration: 2014-01-04
Also published as: US5479589A; EP0664022A1; JPH08503801A; AU7090594A; EP0664022B1; CA2144730A1; WO1995004962A1; DE69404438D1

Description

Die vorliegende Erfindung betrifft im allgemeinen einen Mechanismus zur "Treffer"-Erkennung und insbesondere einen Treffererkennungsmechanismus in einer objektorientierten Programmierumgebung (OOP). Die vorliegende Erfindung ist ein Rahmenwerksystem, welches es einem Programmierer oder einem Anwendungsentwickler ermöglicht, die Suchkriterien für Graphikobjekte so anzupassen, daß eine Anwendung Objekte identifizieren kann, an denen eine bestimmte Maßnahme auszuführen ist. Die Erfindung wird im Rahmen einer bevorzugten Ausführungsform offenbart, die eine weitverbreitete objektorientierte Programmiersprache, C++, verwendet, aber die Prinzipien sind auch auf andere Computerprogrammiersprachen, und zwar sowohl objektorientierte als auch prozedurale, anwendbar.

Beschreibung des Standes der Technik

Objektorientiertes Programmieren (OOP) ist die bevorzugte Umgebung für das Erstellen benutzerfreundlicher, intelligenter Computersoftware. Schlüsselelemente von OOP sind Dateneinkapselung, Vererbung und Polymorphismus. Diese Elemente können verwendet werden, um eine graphische Benutzerschnitte (GUI) zu erstellen, die typischerweise gekennzeichnet ist durch eine Fensterumgebung mit Bildsymbolen, Mauscursor und Menüs Wenngleich diese drei Schlüsselelemente den OOP-Sprachen gemeinsam sind, implementieren die meisten OOP-Sprachen die drei Schlüsselelemente unterschiedlich.
Beispiele für OOP-Sprachen sind Smalltalk, Object Pascal und C++. Smalltalk ist eigentlich mehr als eine Sprache: es könnte präziser als eine Programmierumgebung bezeichnet werden. Smalltalk wurde in der Learning Research-Gruppe im Palo Alto-Forschungszentrum (PARC) von Xerox in den frühen 70er-Jahren entwickelt. In Smalltalk wird eine Mitteilung zu einem Objekt gesandt, um das Objekt selbst zu bestimmen. Mitteilungen führen ähnliche Aufgaben aus wie Funktionsaufrufe in herkömmlichen Programmiersprachen. Der Programmierer muß sich nicht mit dem Datentyp beschäftigen; statt dessen muß sich der Programmierer nur um die Erstellung einer richtigen Mitteilungsreihenfolge kümmern und die richtige Mitteilung verwenden. Object Pascal ist jene Sprache, die für Apples Macintosh-Computer verwendet wird. Apple entwickelte Object Pascal in Zusammenarbeit mit Niklaus Wirth, dem Designer von Pascal. C++ wurde von Bjarne Stroustrup in den AT&T Bell-Laboratorien im Jahr 1983 als Erweiterung von C entwickelt. Das Schlüsselkonzept von C++ ist die Klasse, welche ein anwenderdefinierter Typ ist. Klassen bieten objektorientierte Programmierfunktionen. C++-Module sind kompatibel mit C-Modulen und können frei verknüpft werden, so daß bestehende C- Bibliotheken für C++-Programme verwendet werden können. Die am häufigsten verwendeten objektbasierten und objektorientierten Programmiersprachen leiten ihr Erbe von Simula ab, das in den 60er-Jahren dieses Jahrhunderts von O-J. Dahl, B. Myhrhaug und K. Nygard aus Norwegen entwickelt wurde. Weitere Informationen bezüglich OOP können in Object Oriented Design with Applications von Grady Booch, The Benjimin/Cummings Publishing Co., Inc., Redwood City, Calif. (1991), erhalten werden.
Seit langem gibt es in diesem Fachbereich den Bedarf nach einer Möglichkeit, die einen Entwickler einer Anwendung in die Lage versetzt, geometrische Objekte zu erkennen, maßgeschneiderte Suchkriterien für jedes einzelne geometrische Objekt festzulegen und die Leistung einer Maßnahme basierend auf den Ergebnissen der Suche anzugeben. Bis heute wurde kein solches System entwickelt, das diesen Bedürfnissen entspricht.
EP-A 0 536 894 offenbart ein Bildverarbeitungssystem, bei welchem Farbdaten für Pixel eines an einem zur Bearbeitung an einem Bildschirm darzustellenden Bildes gespeichert werden. Dieses System umfaßt einen Bildeditor und ein automatisches Objektauswahlmittel zur Suche von Bildpixeln zur Identifizierung eines zu bearbeitenden Objektes. Der Farbinhalt eines jeden Bildpixels in einem Bildfenster wird definiert durch einen Bildpixelpuffer in Kombination mit einer Nachschlagefarbregisterbank. Zu diesem Zweck speichert der Bildpixelpuffer einen Indexwert für jeden einzelnen Bildpixel, der zu einem Farbnachschlageregister zeigt, welches die R-, G- und B-Werte entsprechend der Farbe des Pixels enthält. Es wird eine Maus verwendet, um eine interaktive Bearbeitungskontrolle für das System zu bieten. Während der Klicken-und-Ziehen-Mausoperation werden Pfaddaten gesammelt, und vorherbestimmte statistische Bildfarbdaten werden vom gepufferten Bild als eine Funktion der Pfaddaten geladen. Wenn die Maustaste losgelassen wird, wird ein Objektfarbensuchmodell von einer statistischen Analyse der geladenen Bilddaten erzeugt. Das Modell kann ein oder mehrere Farbauswahlkriterien enthalten, die verwendet werden, um die Suche nach dem zu bearbeitenden Objekt durchzuführen. Dieses System wird an die automatische Identifizierung von Farbobjekten angepaßt, während die Verarbeitung von geometrischen Daten durch optionale Selektoren durchgeführt wird, die von einem Pixelauswahlfenster zur Verfügung gestellt werden. Demgemäß löst dieses System nicht die oben genannten Probleme.

ZUSAMMENFASSUNG DER ERFINDUNG

Es ist daher eine Aufgabe der vorliegenden Erfindung, ein objektorientiertes Rahmenwerk zur Bestimmung von Trefferkriterien für geometrische Typen zu schaffen. Die Kriterien können vom Anwendungsentwickler entsprechend angepaßt werden und die Anforderungen für einen Treffer (Aufnahme) oder eine erfolgreiche Suche, das Ausmaß der durchzuführenden Suche und die Maßnahme bei einem erfolgreichen Treffer (Aufnahme) oder einer erfolgreichen Suche festlegen.
Die Erfindung wird in Anspruch 1 und 19 gekennzeichnet. Die anderen Ansprüche definieren vorteilhafte Entwicklungen der Erfindung.
Gemäß der Erfindung wird ein System zur Festlegung von Treffer- oder Suchkriterien für geometrische Typen geschaffen. Das System verwendet diese Kriterien, um auf direkte Weise Graphikobjekte zu manipulieren, die dem geometrischen Typ entsprechen. Der Entwickler einer Anwendung kann auch spezifische Trefferkriterien für zweidimensionale (2D) und dreidimensionale (3D) Graphikobjekte festlegen, die erzeugt wurden.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Die zuvor genannten und andere Aufgaben, Aspekte und Vorteile können besser aus der folgenden detaillierten Beschreibung einer bevorzugten Ausführungsform der Erfindung unter Bezugnahme auf die Zeichnungen verstanden werden, in denen:
Figur 1 ein Blockdiagramm eines Personalcomputersystems der in der Praxis der vorliegenden Erfindung verwendeten Art ist;
Figur 2 einen Bildschirmausdruck einer Anzeige gemäß einer bevorzugten Ausführungsform zeigt;
Figur 3 eine Darstellung verschiedener MGraphics und deren Geometrien gemäß einer bevorzugten Ausführungsform ist;
Figur 4 die Kombination von primitiven Geometrien zeigt, um einfache und komplexe Unterklassen von MGraphic gemäß einer bevorzugten Ausführungsform zu erzeugen;
Figur 5 ein Beispiel eines Graphikobjektes, nämlich ein Rad, mit vielen Ausführungen desselben MGraphic, ein Rad gemäß einer bevorzugten Ausführungsform zeigt;
Figur 6 die Verwendung eines Pfades zur Aufzeichnung der richtigen Ausführung für ein hierarchisches Objekt gemäß einer bevorzugten Ausführungsform darstellt;
Figur 7 ein Flußdiagramm ist, welches die detaillierte Logik einer Treffer-(Aufnahme)-Operation gemäß einer bevorzugten Ausführungsform zeigt;
Figur 8 ein Flußdiagramm ist, welches die detaillierte Logik einer Graphikfindenoperation gemäß einer bevorzugten Ausführungsform zeigt;
Figur 9 ein Flußdiagramm ist, welches die detaillierte Logik einer Graphiksuchoperation gemäß einer bevorzugten Ausführungsform zeigt; und
Figur 10 und 11 verschiedene dreidimensionale (3D) Objekte gemäß einer bevorzugten Ausführungsform zeigen.

DETAILLIERTE BESCHREIBUNG EINER BEVORZUGTEN AUSFÜHRUNGSFORM DER ERFINDUNG

Die Erfindung wird vorzugsweise im Zusammenhang mit einem Betriebssystem angewandt, das sich auf einem Personalcomputer, wie zum Beispiel einem IBM PS/2 oder einem Apple Macintosh Computer, befindet. Eine repräsentative Hardwareumgebung wird in Figur 1 dargestellt, welche eine typische Hardware-Konfiguration einer Workstation gemäß der vorliegenden Erfindung darstellt und eine zentrale Recheneinheit 10, wie zum Beispiel einen herkömmlichen Mikroprozessor, und eine Anzahl anderer Einheiten umfaßt, die über einen Systembus 12 miteinander verbunden sind. Die in Figur 1 dargestellte Workstation umfaßt einen Direktzugriffsspeicher (RAM) 14, einen Nur-Lese-Speicher (ROM) 16, einen E/A-Adapter 10 zum Anschluß von Peripheriegeräten, wie zum Beispiel Platteneinheiten 21 am Bus, einen Benutzerschnittstellenadapter 22 zum Anschluß einer Tastatur 24, einer Maus 26, eines Lautsprechers 28, eines Mikrophons 32 und/oder anderer Benutzerschnittstellengeräte, wie zum Beispiel eines Tast-Bildschirms (nicht dargestellt) am Bus, einen Kommunikationsadapter 34 zum Anschluß der Workstation an einem datenverarbeitenden Netzwerk und einen Anzeigenadapter 36 für den Anschluß des Busses an ein Anzeigegerät 30. Auf der Workstation befindet sich ein Betriebssystem, wie zum Beispiel das Apple System/7 -Betriebs system.
In einer bevorzugten Ausführungsform wird die Erfindung in der C++-Programmiersprache mit Hilfe objektorientierter Programmiertechniken implementiert. Wie den Fachleuten dieses Bereiches bekannt ist, handelt es sich bei Objektorientierten Programmier- (OOP) Objekten um Software- Einheiten, welche Datenstrukturen und Operationen an den Daten umfassen. Gemeinsam machen diese Elemente die Objekte fähig, nahezu alle Echtwelt-Einheiten in bezug auf ihre Merkmale, repräsentiert durch ihre Datenelemente, und ihr Verhalten, repräsentiert durch ihre Datenmanipulationsfunktionen, zu modellieren. Auf diese Weise können Objekte konkrete Dinge wie Personen und Computer modellieren, und sie können abstrakte Begriffe wie Zahlen oder geometrische Begriffe modellieren. Die Vorteile der Objekttechnologie ergeben sich aus drei grundlegenden Prinzipien: Einkapselung, Polymorphismus und Vererbung.
Die interne Struktur ihrer Daten sowie die Algorithmen, welche ihren Funktionen zugrunde liegen, werden von den Objekten versteckt oder eingekapselt. Anstatt diese Implementierungseinzelheiten offenzulegen, präsentieren Objekte Schnittstellen, welche ihre Abstraktionen ohne jegliche sonstige unwesentliche Informationen darstellen. Polymorphismus geht bei der Einkapselung einen Schritt weiter. Die Idee dahinter ist: viele Formen, eine Schnittstelle. Eine Software-Komponente kann eine Anforderung an eine andere Komponente stellen, ohne genau zu wissen, um welche Komponente es sich dabei eigentlich handelt. Die Komponente, welche die Anforderung empfängt, interpretiert diese und bestimmt gemäß ihrer Variablen und Daten, wie die Anforderung auszuführen ist. Das dritte Prinzip ist die Vererbung, welche es Entwicklern ermöglicht, bereits bestehende Konstruktionen und Codes wiederzuverwenden. Durch diese Fähigkeit müssen Entwickler eine Software nicht jedesmal von Beginn an entwickeln. Statt dessen können Entwickler durch Vererbung Unterklassen ableiten, welche Verhalten erben, die der Entwickler an die entsprechenden Anforderungen anpassen kann.
Ein Ansatz des Standes der Technik besteht darin, Objekte und Klassenbibliotheken in einer Verfahrensumgebung zu schichten. Viele am Markt befindlichen Anwendungsrahmenwerke verwenden diesen Konstruktionsansatz. Bei dieser Konstruktion gibt es eine oder mehrere Objektschichten ganz oben auf einem monolithischen Betriebssystem. Während dieser Ansatz alle Prinzipien der Einkapselung, der Polymorphie und der Vererbung auf die Objektschicht anwendet und eine wesentliche Verbesserung gegenüber Verfahrensprogrammiertechniken darstellt, gibt es bei diesem Ansatz doch auch Einschränkungen. Diese Schwierigkeiten entstehen dadurch, weil es für einen Entwickler zwar einfach ist, die eigenen Objekte wiederzuverwenden, weil es für ihn aber schwierig ist, Objekte von anderen Systemen zu verwenden, und ein Entwickler immer noch in die internen Nicht-Objekt- Schichten mit prozeduralen Betriebssystem-Aufrufen hineinreichen muß.
Ein weiterer Aspekt des objektorientierten Programmierens ist ein Rahmenwerkansatz für Anwendungsentwicklung. Eine der besten Definitionen von Rahmenwerken stammt von Ralph E. Johnson von der Universität von Illinois und Vincent F. Russo von Purdue. In ihrem Papier aus dem Jahr 1991 mit dem Titel Reusing Object-Oriented Designs, Universität von Illinois, tech report UIUCDCS91-1696, bieten sie folgende Definition an: "Eine abstrakte Klasse ist eine Konstruktion einer Reihe von Objekten, welche zusammenarbeiten, um eine Reihe von Verantwortlichkeiten auszuführen. Somit ist ein Rahmenwerk eine Reihe von Objektklassen, welche zusammenarbeiten, um festgelegte Reihen von Berechnungsverantwortlichkeiten auszuführen." Vom Standpunkt des Programmierens sind Rahmenwerke im wesentlichen Gruppen miteinander verbundener Objektklassen, die eine zuvor erzeugte Struktur einer Arbeitsanwendung schaffen. So könnte zum Beispiel ein Benutzerschnittstellenrahmenwerk die Unterstützung und das "Standard"-Verhalten des Zeichnens von Fenstern, Rollbalken, Menüs usw. bieten. Da Rahmenwerke auf Objekttechnologie basieren, kann dieses Verhalten geerbt und außer Kraft gesetzt werden, damit Entwickler das Rahmenwerk erweitern und maßgeschneiderte Lösungen in einem bestimmten Bereich ihrer Fachkenntnisse erzeugen können. Dies ist ein wichtiger Vorteil gegenüber dem traditionellen Programmieren, da der Programmierer nicht den ursprünglichen Code verändert, sondern eher die Software erweitert. Darüber hinaus arbeiten sich Entwickler nicht blind durch Schichten von Codes hindurch, weil das Rahmenwerk eine architekturbezogene Führung und Modellierung bietet, gleichzeitig jedoch die Entwickler befreit, damit diese spezifische Maßnahmen im Hinblick auf den Problembereich ergreifen können.
Von einer geschäftlichen Perspektive her betrachtet können Rahmenwerke als eine Möglichkeit gesehen werden, Fachkenntnisse in einem bestimmten Wissensbereich einzukapseln oder zu verkörpern. Unternehmensentwicklungsorganisationen, unabhängige Software-Händler und Systemintegratoren haben sich Fachkenntnisse in bestimmten Bereichen wie zum Beispiel in der Herstellung, Buchhaltung oder Währungstransaktionen erarbeitet. Dieses Fachwissen ist in ihrem Code enthalten. Rahmenwerke ermöglichen es Organisationen, die gemeinsamen Merkmale dieses Fachwissens durch Aufnahme in den Code der Organisation aufzunehmen und zu sammeln. Erstens erhalten Entwickler dadurch die Möglichkeit, eine Anwendung zu erstellen oder zu erweitern, welche dieses Fachwissen verwendet; somit wird das Problem einmal gelöst, und die Geschäftsregeln und das Design werden verstärkt und konsistent angewendet. Ebenso verfügen die Rahmenwerke und das hinter den Rahmenwerken enthaltene Fachwissen eine Bedeutung von strategischem Wert für jene Organisationen, die sich in vertikalen Märkten Fachwissen erworben haben, wie zum Beispiel bei der Herstellung, in der Buchhaltung oder in der Biotechnologie, wodurch sie nun über einen Verteilungsmechanismus für die Verpackung, den Wiederverkauf und die Ausnutzung ihres Fachwissens und zur Förderung des Fortschrittes und der Verteilung der Technologie verfügen.
Historisch gesehen haben sich die Rahmenwerke erst in jüngster Zeit als ein Hauptströmungskonzept auf Computerplattformen entwickelt. Diese Migration wurde durch die Verfügbarkeit objektorientierter Sprachen wie zum Beispiel C++ unterstützt. Traditionellerweise wurde C++ am häufigsten auf UNIX-Systemen und den Workstations von Forschern verwendet und kaum auf Computern in kommerziellen Umgebungen. Sprachen wie C++ und andere objektorientierte Sprachen, wie zum Beispiel Smalltalk und andere, haben einer Reihe von Universitäts- und Forschungsprojekten geholfen, die Vorläufer der heutigen kommerziellen Rahmenwerke und Klassenbibliotheken zu schaffen. Einige Beispiele dafür wären Interviews von der Stanford-Universität, der Andrew- Befehlssatz von der Carnegie-Mellon Universität und das ET++-Rahmenwerk von der Zürich-Universität.
Es gibt viele Arten von Rahmenwerken, abhängig vom Niveau des Systems und der Art des Problems, das gelöst werden soll. Die Arten der Rahmenwerke reichen von Anwendungsrahmenwerken, die bei der Entwicklung von Anwenderschnittstellen helfen, bis hin zu Rahmenwerken niedrigerer Ebene, welche grundlegende Systemsoftwaredienste wie zum Beispiel Kommunikation, Drucken, Dateiablagesystemunterstützung, Graphik usw. bieten. Kommerzielle Beispiele von Anwendungsrahmenwerken sind MacApp (Apple), Bedrock (Symantec), OWL (Borland), NextStep App Kit (NEXT) und Smalltalk-80 MVC (ParcPlace).
Das Programmieren mit Rahmenwerken erfordert von den Entwicklern, die an andere Systemarten gewöhnt sind, eine neue Art des Denkens. Tatsächlich handelt es sich hierbei nicht mehr um das "Programmieren" im herkömmlichen Sinn. In älteren Betriebssystemen, wie zum Beispiel in DOS oder UNIX, schafft das eigene Programm des Entwicklers die gesamte Struktur. Das Betriebssystem bietet Dienstleistungen durch Systemaufrufe - das Programm des Entwicklers führt diese Aufrufe durch, wenn es die Dienstleistung benötigt, und die Kontrolle kehrt wieder zurück, nachdem die Dienstleistung zur Verfügung gestellt wurde. Die Programmstruktur basiert auf dem Fluß der Kontrolle, der im Code enthalten ist, den der Entwickler schreibt.
Wenn Rahmenwerke verwendet werden, ist dies genau umgekehrt. Der Entwickler ist nicht mehr für den Fluß der Kontrolle verantwortlich. Der Entwickler muß auf die Tendenz verzichten, die Programmieraufgaben in bezug auf den Fluß der Ausführung verstehen zu wollen. Statt dessen muß sich das Denken auf die Verantwortlichkeiten der Objekte richten, welche sich auf das Rahmenwerk verlassen müssen, um zu bestimmen, wann die Tasks ausgeführt werden sollten. Vom Entwickler geschriebene Routinen werden von einem Code aktiviert, den der Entwickler nicht geschrieben hat und den der Entwickler niemals sieht. Dieser Flipflop-Vorgang im Kontrollfluß kann eine wesentliche psychologische Barriere für Entwickler darstellen, die nur über Erfahrungen im prozeduralen Programmieren verfügen. Wenn dies jedoch einmal begriffen wird, erfordert das Rahmenwerk-Programmieren wesentlich weniger Aufwand als andere Arten des Programmierens.
Ähnlich wie ein Anwendungsrahmenwerk dem Entwickler vorgefertigte Funktionalität bietet, übertragen Systemrahmenwerke, wie zum Beispiel jenes, das in einer bevorzugten Ausführungsform enthalten ist, dasselbe Konzept, indem sie Dienstleistungen auf Systemebene bieten, welche Entwickler, wie zum Beispiel Systemprogrammierer, verwenden, um Unterklassen zu bilden bzw. außer Kraft zu setzen, um maßgeschneiderte Lösungen zu schaffen. Stellen Sie sich zum Beispiel ein Multimedia-Rahmenwerk vor, welches die Grundlage für die Unterstützung von neuen und unterschiedlichen Geräten wie zum Beispiel Audio, Video, MIDI, Animationen usw. bieten sollte. Der Entwickler, der eine neue Art von Gerät unterstützen sollte, müßte einen Gerätetreiber schreiben. Um dies mit einem Rahmenwerk durchzuführen, muß der Entwickler nur die Eigenschaften und das Verhalten unterstützen, welches dem neuen Gerät eigentümlich ist.
Der Entwickler bietet in diesem Fall eine Implementierung für bestimmte Mitgliederfunktionen, die vom Multimedia-Rahmenwerk aufgerufen werden. Ein unmittelbarer Vorteil für den Entwickler ist die Tatsache, daß der genensche Code, der für die einzelnen Gerätekategorien benötigt wird, bereits vom Multimedia-Rahmenwerk zur Verfügung gestellt wird. Dies bedeutet, daß der Entwickler des Gerätetreibers weniger Code schreiben, testen und weniger Fehler beseitigen muß. Ein weiteres Beispiel für die Anwendung des Systemrahmenwerkes wären getrennte E/A-Rahmenwerke für SCSI-Geräte, NuBus-Karten und graphische Geräte. Weil es in diesem Zusammenhang eine vererbte Funktionalität gibt, bietet jedes einzelne Rahmenwerk Unterstützung für allgemeine Funktionalitäten, die in seiner Gerätekategone enthalten sind. Andere Entwickler könnten dann von diesen konsistenten Schnittstellen zu allen Arten von Geräten Gebrauch machen.
Eine bevorzugte Ausführungsform übernimmt das Konzept der Rahmenwerke und wendet dieses im ganzen System an. Für den kommerziellen oder firmeninternen Entwickler, den Systemintegrator oder OEM bedeutet dies, daß all die Vorteile, die für ein Rahmenwerk wie zum Beispiel MaCapp dargestellt wurden, nicht nur auf die Anwendungsebene für solche Dinge wie Text und Anwenderschnittstellen übertragen werden können, sondern auch auf die Systemebene, für Dienstleistungen wie zum Beispiel Graphiken, Multimedia, Dateisysteme, E/A, Testdurchführung usw. Die Anwendungserstellung in der Architektur einer bevorzugten Ausführungsform ist im wesentlichen gleich wie das Schreiben bereichsspezifischer Puzzleteilchen, die dem Rahmenwerkprotokoll unterstellt sind. Auf diese Weise ändert sich das gesamte Konzept des Programmierens. Anstelle des Schreibens einer Codezeile nach der anderen, welche mehrfache API- Hierarchien aufrufen, wird Software nunmehr entwickelt, indem Klassen von bereits bestehenden Rahmenwerken innerhalb dieser Umgebung abgeleitet werden, und indem danach je nach Bedarf neues Verhalten hinzugefügt und/oder vererbtes Verhalten außer Kraft gesetzt wird.
Somit wird die Anwendung des Entwicklers zu einer Sammlung von Code, der geschrieben und von allen anderen Rahmenwerkanwendungen gleichermaßen benutzt wird. Dies stellt ein sehr mächtiges Konzept dar, weil Entwickler dadurch in der Lage sind, auf der Arbeit der anderen aufzubauen. Dies gibt dem Entwickler auch die Flexibilität, ein Programm je nach Bedarf mehr oder weniger maßzuschneidern. Manche Rahmenwerke werden genau so verwendet werden, wie sie sind. In manchen Fällen wird das Ausmaß der maßgeschneiderten Anpassung minimal sein, so daß das Puzzleteilchen, das der Entwickler einfügt, ein kleines ist. In anderen Fällen kann der Entwickler sehr großzügige Veränderungen durchführen und etwas völlig Neues schaffen. Im Hinblick auf OOP ist Figur 2 eine Darstellung einer Anzeige jener Art, die von einem objektorientierten Betriebssystem erzeugt wird. Sie umfaßt einen Befehlsbalken 200, einen ausgewählten Menüpunkt 210, ein Textanzeigefenster 220 und ein darüberliegendes Grafikanzeigefenster 230. Eine Auswahl eines bestimmten Grafikobjektes, ein Kreis innerhalb des Grafikfensters 240, wird mittels der quadratischen Punkte 250 dargestellt, welche das Objekt umgeben.
Für ein richtiges Verständnis der Natur der Erfindung ist es wichtig, das Konzept eines "Rahmenwerkes" und die Beziehung eines Rahmenwerks zu "Objekten" und "Objektorientierter Programmierung" zu verstehen. "MacApp: An Application Framework" von Kurt A. Schmucker, veröffentlicht vom Byte-Magazin im August 1906, ist ein früher Artikel, der ein Rahmenwerk und die darin enthaltenen grundlegenden Konzepte beschreibt. Eine wichtige Eigenschaft von Objekten ist ihre Fähigkeit, Daten und Verfahren einzukapseln, für welche das Objekt verantwortlich ist. Das heißt, ein generischer Befehl kann an ein Objekt ausgegeben werden, ohne daß irgend ein anderes Objekt die internen Details kennen muß, wie das Objekt den Befehl ausführen wird. Durch dieselbe Zeichenfolge besteht keine Notwendigkeit einer globalen Kompatibilität von Befehlen, Daten, Dateinamen und ähnlichem, und somit können Objekt frei miteinander assoziiert werden. Ein Rahmenwerk ist grundsätzlich eine generische Anwendung, welche eine Assoziierung von Objektklassen umfaßt, mit denen andere Objekte je nach Bedarf assoziiert sein können, um eine spezifischere Anwendung zu bilden. Das Rahmenwerk als eine Assozuerung von Objektklassen mit funktionellen Beziehungen zwischen darin definierten Objektklassen kann jeden gewünschten Grad an allgemeiner oder spezifischer Funktionalität bieten und die richtige Funktionalität zusätzlicher Objekte zur Verfügung stellen, die mit dem Rahmenwerk assoziiert sein können.
Ein Rahmenwerk kann daher als System betrachtet werden, welches ein impliziertes Netzwerk an Pflichten zwischen Objekten schafft, für die Vererbung zwischen Objektklassen sorgt (z.B. Daten und Verfahren von Superklassen in höheren Hierarchieebenen von Objektklassen) und für den Aufruf von Bibliotheken als Reaktion auf Ereignisse sorgt. Ein als Rahmenwerk ausgebildetes System kann auch durch das Hinzufügen von Objekten maßgeschneidert werden, welche spezifischere Funktionen ausführen und welche auch vom Rahmenwerk zur Verfügung gestellte Funktionen überschreiben können. Maschinenspezifische und gerätespezifische Objekte in verschiedenen Klassen und Unterklassen des Rahmenwerks ermöglichen es dem Rahmenwerk selbst, maschinen- und geräteunabhängig und allgemein anwendbar zu sein. Des weiteren ist ein bestimmtes Rahmenwerk gekennzeichnet durch die Beziehungen, welche es zwischen Objekten und Objektklassen hinsichtlich der Pflichtenaufteilung und der damit erzielten Vererbung und Funktionalität erstellt. Ein Rahmenwerk selbst dient auch als Vorlage für die Entwicklung spezifischer Anwendungen, in denen Anpassung und funktionelles Überschreiben als spezifische Objekte darin geschaffen werden können.
Die vorliegende Erfindung, ein Treffererkennungsrahmenwerk, schafft einen Mechanismus, um dem Anwendungsentwickler die Flexibilität zu bieten, das Verhalten sowohl für primitive als auch maßgeschneiderte geometrische Typen festzulegen. Die Treffererkennung ermöglicht es einer Anwendung, Graphikobjekte durch Definition eines Verhaltens für jeden einzelnen geometrischen Typ direkt zu manipulieren. Der Entwickler kann Kriterien festlegen, die besagen, wodurch ein Treffer bestimmt, die das Ausmaß der Suche nach einem Treffer festlegen sowie die Maßnahme, die im Falle eines Treffers auszuführen ist. Das Rahmenwerk bietet ein Standard-Suchprotokoll für die primitiven geometrischen Typen. Diese Standard-Suchprotokolle können jedoch überschrieben und vom Benutzer angepaßt werden.
MGraphic ist eine Dienstprogrammklasse für Anwendungen. Es enthält geometriebezogene Daten einschließlich geometrische Objekte, Attribute (in einem Bündel) und Hierarchien. Figur 3 zeigt verschiedene MGraphics und deren entsprechende Geometrien. Diese primitiven geometrischen Typen können vom Anwender kombiniert werden, um einfache und komplexe Unterklassen von MGraphic zu erzeugen, wie sie in Figur 4 dargestellt sind. Das Trefferobjektrahmenwerk ermöglicht es, angepaßt Trefferkriterien für jede beliebige MGraphic-Unterklasse festzulegen. Kriterien können für jede primitive und selbstdefinierte geometrische Klasse definiert werden. Die MGraphic-Unterklasse ruft dann die entsprechende Methode für die geometrischen Typen, die sie enthalten, auf.
TGrafSearch & TGrafSearch3D sind die wichtigsten Objekte, welche die Definitionen der Kriterien für die Treffererkennung und die bei einem Treffer auszuführenden Maßnahmen enthalten. Diese Informationen werden von der MGraphic::Find-Methode verwendet, um die Treffererkennung durchzuführen. Wenn die Anwendung eine Treffererkennung an einer Gruppe von MGraphics durchführen möchte, erzeugt die Anwendung eine Unterklasse von TGrafSearch, ein Objekt, welches festlegt: (1) was für jeden einzelnen primitiven geometrischen Typ einen "Treffer" ausmacht; (2) den Umfang der Suche, d.h. finde einen oder alle, welche den Kriterien entsprechen; und (3) die Maßnahme, die bei einem erfolgreichen Treffer auszuführen ist. Die bei Auftreten eines erfolgreichen Treffers auszuführende Maßnahme ist anwendungsspezifisch, könnte aber das Löschen, Auswählen oder Kopieren des ausgewählten Objektes umfassen.
Der erste Faktor von TGrafSearch, die Trefferkriterien, wird von den Find-Methoden festgelegt. Die Find-Methoden nehmen die Transformationsmatrix der primitiven Geometrien und das Bündel von Attributen als Parameter, und die Methoden können je nach Bedarf von der Anwendung festgelegt werden. Einige Beispiele für Find-Methoden umfassen das Testen eines Punktes im Vergleich mit der umgrenzenden Box der Geometrie oder das Bestimmen, ob eine Geometrie vollständig von einem Vieleck umschlossen ist, und ob sein Bündel einen bestimmten Doppelpunkt besitzt.
Der zweite Typ der in TGrafSearch enthaltenen Informationen definiert das Ausmaß der Suche nach geometrischen Objekten, welche den Trefferkriterien entsprechen. Eine Anwendung möchte zum Beispiel alle Graphikobjekte finden, die den Suchkriterien entsprechen, oder sie möchte nur das erste Vorkommen finden, welches den Suchkriterien entspricht. Zum Beispiel möchte eine Anwendung alle Kreise finden, die sich innerhalb eines Rechtecks befinden, oder sie möchte die erste Linie finden, die einen Kreis schneidet.
Das dritte Element des TGrafSearch-Trefferobjektrahmenwerks ist die Definition der gewünschten Maßnahme, die ausgeführt werden soll, wenn die Suchkriterien erfüllt sind. Beispiele für solche gewünschte Maßnahmen umfassen das Sammeln von MGraphics, welche die Suchkriterien für die Verarbeitungsleistung einer anwendungsspezifischen Maßnahme erfüllen, oder das Erzeugen eines Wertes, der die Ergebnisse der Suche zusammenfaßt.
Als ein Beispiel dafür, wie Trefferobjekte verwendet werden, zeigt der untenstehende Code TMySearch, das eine anwendungsdefinierte Maßnahme am ersten MGraphic durchführt, der die Kriterien des Schneidens mit einem Kreis, definiert um den Cursor, erfüllt.
TGrafSearch definiert viele Routinen der Form
für jeden Typ der primitiven Geometrie. Diese Methoden definieren die Kriterien, die TGrafSearch verwendet, um zu bestimmen, ob es zu einem Treffer gekommen ist. Sie geben ein Ergebnis, EFindResult, zurück, welches eines von zwei Werten aufweisen kann, nämlich kDoneSearching, welches anzeigt, daß die Suche gestoppt werden kann, oder kContinue-Searching, welches anzeigt, daß die Suche fortgesetzt werden muß. Zwei andere Routinen, PushGraphic und PopGraphic, sind in TGrafSearch definiert, und beide Routinen werden dazu verwendet, um das Verhalten von MGraphic insgesamt zu regeln. PushGraphic ist eine Methode, die sowohl zum Starten der Suche innerhalb eines spezifischen MGraphic als auch zum Implementieren hierarchischer MGraphics (infra zu diskutieren) verwendet wird. PopGraphic gibt den Suchstatus für den gesamten MGraphic zurück. Wenn zum Beispiel die Anwendung alle MGraphics in der Datenbank durchsuchen soll, dann wird PopGraphic so eingestellt, daß er immer kContinueSearching zurückgibt.
Ein weiteres Beispiel zeigt die Verwendung des zweiten Faktors, der von TGrafSearch hinsichtlich des Umfangs der durchzuführenden Suche definiert wird. Der folgende Code ist ein Beispiel jener Routinen, die sowohl innerhalb der MGraphics verwendet werden, als auch jener, die zum Regeln des Verhaltens von MGraphic als gesamtes verwendet werden. Die erste TGrafSearch-Unterklasse, TIntersectsGraf-Search, findet zuerst den Gegenstand, der ein Rechteck, TGRect, schneidet, während die zweite Unterklasse, TContainsGrafSearch, alle jene Gegenstände findet, die vollständig innerhalb eines Rechtecks, TGRect, enthalten sind.
Der Pseudocode für TInterSectsGrafSearch lautet wie folgt:
Der Pseudocode für TContainsgrafSearch lautet wie folgt:
Das Rahmenwerk bietet auch Mechanismen, um die Probleme zu lösen, die mit der Trefferüberprüfung hierarchischer Daten einhergehen, der Verwendung einer MGraphic in mehreren Ausführungen in einem Objekt. Figur 5 zeigt ein Fahrrad mit mehreren Ausführungen des Rades MGraphic. Diese Art von Daten wirft Probleme auf, weil die Rückgabe von nur einem Zeiger auf ein Rad nicht auf einzigartige Weise das bestimmte Rad identifiziert, an dem der Anwender der Zeiger betätigt (d.h. "geklickt") hat. Daher ist es notwendig, zwischen mehreren Ausführungen desselben MGraphic zu unterscheiden. Das Rahmenwerk tut dies durch Aufzeichnung des Pfades zur bestimmten Ausführung des gewünschten MGraphic. Figur 6 zeigt, wie ein Pfad verwendet wird, um das ausgewählte Rad am Fahrrad zu identifizieren. Um zum Beispiel das hintere Rad (Objekt D) zu treffen, würde der Pfad lauten: A, B, D.
Das Rahmenwerk implementiert die Trefferprüfung hierarchischer MGraphics unter Verwendung der PushGraphic- und PopGraphic-Methoden der MGrafSearch-Klasse. Diese Methoden verwenden als Parameter den MGraphic-Zeiger, das Bündel und die Matrix für die bestimmte Gruppe. Wenn ein Treffer auftritt, kann PushGraphic den angesammelten Pfad, der eine Sammlung von Umwandlungen und Zeigern zu Gruppen ist, aufzeichnen. Der folgende Pseudocode illustriert eine Find-Routine für eine TGroup, eine Gruppe von MGraphics.
Zusätzlich zu den Unterklassen von TGrafSearch, welche die Trefferkriterien, das Ausmaß der Suche und die für einen Treffer auszuführenden Maßnahmen festlegt, kann TGrafSearch Unterklassen besitzen, in denen Informationen bezüglich der geometrisch wichtigen Merkmale des Trefferobjektes gespeichert sind. Die Informationen können von der Anwendung auf viele verschiedene Arten verwendet werden, zum Beispiel für das Definieren eines "Zuschnapp"-Verhaltens.
Figur 7 ist ein Flußdiagramm, welches die detaillierte Logik einer Treffer-(Aufnahme)-Operation gemäß einer bevorzugten Ausführungsform zeigt. Die Verarbeitung beginnt beim Punkt 700 und geht sofort zum Funktionsblock 710 weiter, um die nächste Graphik zu erhalten. Danach wird ein Test am Entscheidungsblock 720 durchgeführt, um zu bestimmen, ob die Graphik null ist. Wenn dies der Fall ist, werden die Trefferdaten vom GrafSearch-Objekt erlangt, wie dies im Funktionsblock 750 dargestellt ist, der mit dem graphischen Treffer/Aufnahme im Zusammenhang stehende Befehl wird, wie im Funktionsblock 760 gezeigt, ausgeführt, und die Verarbeitung wird am Punkt 770 abgeschlossen. Wenn der Graphiktest am Entscheidungsblock 720 negativ verläuft, wird am Funktionsblock 730 ein Funktionsaufruf an die Graphiksuchroutine ausgeführt, wie dies im Funktionsblock 730 gezeigt und in Figur 8 genau dargestellt ist. Der Wert wird als Ergebnis des Funktionsaufrufes eingestellt, und ein Test wird am Entscheidungsblock 740 durchgeführt, um zu bestimmen, ob die Suche auf der Grundlage des Wertes fortgeführt werden soll. Wenn die Suche nicht fortgeführt werden soll, geht die Verarbeitung zum Funktionsblock 750 weiter, und Trefferdaten werden vom GrafSearch-Objekt erhalten; danach wird der mit dem graphischen Treffer/Aufnahme zusammenhängende Befehl wie im Funktionsblock 760 gezeigt ausgeführt, und die Verarbeitung wird die Verarbeitung wird am Punkt 770 abgeschlossen.
Figur 8 ist ein Flußdiagramm, welches die detaillierte Logik einer Graphikfindenoperation gemäß einer bevorzugten Ausführungsform zeigt. Die Verarbeitung beginnt am Funktionsblock 800, wo die Graphik auf einen Stapel geschoben wird. Danach werden am Funktionsblock 810 Geometrien der Suche für GrafSearch definiert, ein Funktionsaufruf zur Auffindung der Graphik wird am Funktionsblock 820 durchgeführt, und detailliert in Figur 9 gezeigt; und ein Test wird am Entscheidungsblock 830 durchgeführt, um zu bestimmen, ob der Wert, der vom Funktionsaufruf zurückgegeben wurde, anzeigt, daß die Graphik gefunden wurde. Wenn ja, wird die Verarbeitung durch Weitergabe der Kontrolle über den Punkt 850 zu Figur 7, Punkt 788, wieder aufgenommen. Wenn nicht, wird der Wert gleich dem Wert der Graphik auf dem Stapel gesetzt, und die Kontrolle wird über den Punkt 850 zu Figur 7, Punkt 788, weitergegeben.
Figur 9 ist ein Flußdiagramm, welches die detaillierte Logik einer Graphiksuchoperation gemäß einer bevorzugten Ausführungsform zeigt. Die Verarbeitung beginnt am Funktionsblock 900, wo die Treffererkennung durchgeführt wird. Danach wird am Entscheidungsblock 910 ein Test durchgeführt, um zu bestimmen, ob die Graphik getroffen wurde. Wenn nicht, wird die Kontrolle zum Punkt 888 von Figur zurückgegeben. Wenn eine Graphik getroffen wurde, wird ein weiterer Test am Entscheidungsblock 920 durchgeführt, um zu bestimmen, ob die Suche fortgesetzt werden sollte. Wenn ja, wird der Wert gleich einem Wert gesetzt, der für eine fortgesetzte Suche steht. Wenn nicht, wird der Wert gleich einem Wert gesetzt, der für eine abgeschlossene Suche steht. In beiden Fällen wird die Kontrolle von der Funktion zur aufrufenden Routine zurückgegeben. Figur 10 und 11 zeigen verschiedene zweidimensionale (2D) Objekte gemäß einer bevorzugten Ausführungsform 3D-Oberflächen werden am Punkt 1000 gezeigt, 3D-Kurven werden bei 1010 dargestellt, 3D- Linien und Polylinien werden bei 1020 dargestellt, und eine 3D-Box wird bei 1030 dargestellt. In Figur 11 wird ein Beispiel eines 2D-Zeichensatzes 1100 und eines Graphikbereiches 1110 dargestellt.
Wenngleich die Erfindung im Hinblick auf eine einzelne bevorzugte Ausführungsform beschrieben wurde, werden Fachleute dieses Gebietes erkennen, daß die Erfindung mit Modifizierungen innerhalb des Umfanges der angehängten Ansprüche angewandt werden kann.

Claims

1. Eine Einrichtung zum Auswählen eines graphischen Bildes, das auf einer Graphik-Anzeige angezeigt wird, mit einem Betriebssystem, einem durch das Betriebssystem gesteuerten Datenprozessor, einem durch besagten Prozessor gesteuertes Anzeigegerät zur Anzeige einer Vielzahl von Pixeln zur Darstellung eines graphischen Bildes, wobei jedes der besagten Pixel Pixel-Daten aufweist für eine Steuerung des besagten Anzeigeräts zur Anzeige einer Darstellungsform für jedes der besagten Vielzahl von Pixeln, und mit Speichermitteln, die eine Vielzahl von Speicherplätzen aufweisen zur Speicherung der besagten Pixel-Daten, und mit Mitteln zum Auswählen von Objekten, die zur Durchführung von Bildverarbeitungsoperationen an besagten Objekten angezeigt werden ;

gekennzeichnet durch:

a) ein objektorientiertes Betriebssystem und Mittel zum Erzeugen einer Vielzahl von Objekten in besagtem objektorientierten Betriebssystem, von denen jedes eines oder mehrere geometrische Attribute eines graphischen Bildes, Übereinstimmungskriterien und eine Methode für eine Operation enthält, die ausgeführt wird, wenn eine Übereinstimmung auftritt, besagte Objekte definieren ein Suchprotokol;

b) Mittel zum Erkennen eines graphischen Bildes, das mit besagten einem oder mehreren geometrischen Attributen übereinstimmt und besagte Übereinstimmungskriterien erfüllt, unter Verwendung einer geometrischen Transformationsmatrix, die eine Datenstruktur im besagten Objekt darstellt, welche einen geometrischen Typ enthält, der entsprechend den Anforderungen einer Anwendung definiert ist, und besagte eines oder mehrere geometrische Attribute darstellt zur Bestimmung, ob besagte Übereinstimmungskriterien erfüllt sind; und

c) Mittel zum Erzeugen einer Ausgabe, die auf besagter Operation beruht, die ausgeführt wird, wenn eine Übereinstimmung auftritt.

2. Eine Einrichtung nach Anspruch 1, enthaltend Mittel zum Ändern einer Abbildung des besagten graphischen Bildes.

3. Eine Einrichtung nach Anspruch 1, enthaltend Mittel zum Berechnen eines Wertes in Abhängigkeit davon, ob besagtes graphisches Objekt das Suchprotokol erfüllt.

4. Eine Einrichtung nach Anspruch 1, enthaltend Mittel zum Auswählen des besagten graphischen Objekts zur Verarbeitung.

5. Eine Einrichtung nach Anspruch 1, enthaltend Mittel zum Definieren eines Suchprotokols, das auf geometrischen Attributen eines Objektes beruht.

6. Eine Einrichtung nach Anspruch 5, worin besagte geometrische Attribute einen Punkt definieren.

7. Eine Einrichtung nach Anspruch 5, worin besagte geometrische Attribute eine Linie definieren.

8. Eine Einrichtung nach Anspruch 5, worin besagte geometrische Attribute ein Rechteck definieren.

9. Eine Einrichtung nach Anspruch 1, worin besagte übereinstimmungskriterien logische Kombinationen von besagten geometrischen Attributen enthalten.

10. Eine Einrichtung nach Anspruch 5, worin besagte geometrische Attribute eine Kugel definieren.

11. Eine Einrichtung nach Anspruch 5, worin besagte Übereinstimmungskriterien hierarchische Beziehungen von besagten geometrischen Attributen enthalten.

12. Eine Einrichtung nach Anspruch 5, enthaltend Mittel zum Abstimmen besagter Suche zur Optimierung der Genauigkeit.

13. Eine Einrichtung nach Anspruch 1, enthaltend Mittel zum Einstellen besagter Suche zur Feststellung von Beziehungen zwischen einer Vielzahl von geometrischen Figuren.

14. Eine Einrichtung nach Anspruch 1, enthaltend Mittel zum Abstimmen der Suche zum Optimieren der Geschwindigkeit.

15. Eine Einrichtung nach Anspruch 13, enthaltend Mittel zur Feststellung eines Treffers, wenn eine erste geometrische Figur und eine zweite geometrische Figur innerhalb eines vorgegebenen Abstandes liegen.

16. Eine Einrichtung nach Anspruch 13, enthaltend Mittel zur Feststellung eines Treffers, wenn eine erste geometrische Figur hinter einer zweiten geometrischen Figur liegt.

17. Eine Einrichtung nach Anspruch 1, enthaltend Mittel zur dynamischen Aufsetzung einer neuen Suchoperation, die auf besagter Suchstrategie beruht.

18. Eine Einrichtung nach Anspruch 1, die eine Positionsanzeigevorrichtung benutzt zur Bezeichnung von Koordinaten auf besagtem Anzeigegerät, und die Speichermittel benutzt mit einer Vielzahl von Speicherplätzen zur Speicherung der besagten Pixel-Daten, enthaltend Mittel zum Erkennen eines graphischen Bildes, das mit einem oder mehreren der geometrischen Attribute übereinstimmt und besagte Übereinstimmungskriterien erfüllt unter Benutzung von besagter Position auf dem Anzeigegerät, von besagter geometrischer Transformationsmatrix und von besagten einem oder mehreren geometrischen Attributen zur Bestimmung, ob besagtes Übereinstimmungskriterien nahe der besagten Position erfüllt ist.

19. Ein computer-implementiertes Verfahren zum Auswählen eines graphischen Bildes, das auf einer Graphik-Anzeige angezeigt wird, unter Verwendung von einem Betriebssystem, einem durch das Betriebssystem gesteuerten Datenprozessor, einem durch besagten Prozessor gesteuerten Anzeigegerät zur Anzeige einer Vielzahl von Pixeln, die ein graphisches Bild darstellen, wobei jedes der besagten Pixel Pixel-Daten aufweist für eine Steuerung des besagten Anzeigeräts zur Anzeige einer Darstellungsform für jedes der besagten Vielzahl von Pixeln, und unter Verwendung von Speichermitteln, die eine Vielzahl von Speicherplätzen aufweisen zur Speicherung der besagten Pixel-Daten, und von Mitteln zum Auswählen von Objekten, die zur Durchführung von Bildverarbeitungsoperationen an besagten Objekten angezeigt werden;

gekennzeichnet durch:

a) Definieren eines Suchprotokols für einen geometrischen Typ unter Verwendung einer Vielzahl von Objekten, die in einem objektorientierten Betriebssystem organisiert sind, jedes der besagten Objekte enthält eines oder mehrere geometrische Attribute eines graphischen Bildes, Übereinstimmungskriterien und eine Operation, die ausgeführt wird, wenn eine Übereinstimmung auftritt;

b) Erkennen eines graphischen Bildes, das mit besagten einem oder mehreren geometrischen Attributen übereinstimmt und besagte Übereinstimmungskriterien erfüllt, unter Verwendung von einer geometrischen Transformationsmatrix, die eine Datenstruktur im besagten Objekt darstellt, die einen geometrischen Typ definiert entsprechend den Anforderungen einer Anwendung, und von besagten einem oder mehreren geometrischen Attributen zur Bestimmung, ob besagtes Übereinstimmungskriterium erfüllt ist; und

c) Erzeugen einer Ausgabe, die auf besagter Operation beruht, welche ausgeführt wird, wenn eine Übereinstimmung auftritt.

20. Ein Verfahren nach Anspruch 19, worin besagter Schritt zum Erzeugen einer Ausgabe die Änderung einer Abbildung des besagten graphischen Bildes umfaßt.

21. Ein Verfahren nach Anspruch 19, worin besagter Schritt zum Erzeugen einer Ausgabe eine Berechnung eines Wertes enthält in Abhängigkeit davon, ob besagtes graphisches Objekt das Suchprotokol erfüllt.

22. Ein Verfahren nach Anspruch 19, worin besagter Schritt zum Erzeugen einer Ausgabe den besagten Schritt der Auswahl des besagten graphischen Objekts zur Verarbeitung umfaßt.

23. Ein Verfahren nach Anspruch 19, enthaltend besagten Schritt der Definition eines Suchprotokols, das auf geometrischen Attributen eines Bildes beruht.

24. Ein Verfahren nach Anspruch 19, das eine Positionsanzeigevorrichtung benutzt zur Bezeichnung von Koordinaten auf besagtem Anzeigegerät, mit einer Vielzahl von Objekten, die in einem objektorientierten Betriebssystem organisiert sind, weiter enthaltend die Schritte:

Verwenden der besagten Positionsanzeigevorrichtung zur Bezeichnung einer Start-Suche-Koordinate auf besagtem Anzeigegerät;

Erkennen eines graphischen Bildes, das sich nahe der Start-Suche-Koordinate auf besagtem Anzeigegerät befindet und mit einem oder mehreren der geometrischen Attribute übereinstimmt und besagte Übereinstimmungskriterien erfüllt, unter Benutzung von besagter geometrischer Transformationsmatrix und von besagten einem oder mehreren geometrischen Attributen zur Bestimmung, ob besagte Übereinstimmungskriterien erfüllt sind.