DE69519904T2

DE69519904T2 - Verfahren und Vorrichtung zur Bereitstellung einer zusammenhängenden Navigation in historischen Daten

Info

Publication number: DE69519904T2
Application number: DE69519904T
Authority: DE
Inventors: William J Johnson
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1994-08-19
Filing date: 1995-08-04
Publication date: 2001-06-21
Anticipated expiration: 2015-08-05
Also published as: US5621880A; EP0698843B1; EP0698843A1; JP3463288B2; DE69519904D1; JPH0876961A

Description

Technisches Gebiet der Erfindung

Die vorliegende Erfindung betrifft im allgemeinen Datenverarbeitungssysteme, und insbesondere ein Verfahren und ein Gerät zum Vorsehen einer automatischen Navigation in einer Mehrprogrammbetriebfensterumgebung zu einem Fenster, das ein vom Anwender zu irgendeiner Zeit in der Vergangenheit spezifiziertes Suchkriterium enthält.

Der Erfindung zugrundeliegender allgemeiner Stand der Technik

Herkömmliche Datenverarbeitungssysteme können Möglichkeiten vorsehen zum Navigieren zwischen Mehrfachfenstern, die in einer Mehrprogrammbetriebfensterumgebung angezeigt werden. Das augenblicklich von einem Anwender zum Anzeigen im Vordergrund und für aktive Eingabe ausgewählte Fenster ist bekannt als Fenster mit Scharfeinstellung. Der Anwender kann den Brennpunkt verändern durch Anwenden eines impliziten Fokusmodells oder eines expliziten Fokusmodells.
Soweit anwendbar wird der Ausdruck "Fenster" in der vorliegenden Beschreibung im weitesten Sinne angewandt. Das beinhaltet ein Vollbildschirmsitzungsfenster oder ein dimensioniertes Feldfenster.
In einem impliziten Brennpunktmodell, wie von der OSF/MotifTM Windowing Environment der Open Software Foundation, Inc. vorgesehen, wird der Brennpunkt automatisch auf das Fenster verändert, auf dem der von der Maus gesteuerte Cursor oder Zeiger steht. Wenn der Anwender den Cursor auf einen Teil des Fensters verschiebt, der teilweise verborgen ist, blendet sich das Fenster automatisch in den Brennpunkt ein, so daß dann das ganze Fenster sichtbar wird.
In einem expliziten Brennpunktmodell, wie es von der OS/2TM Presentation Manager Fensterumgebung der International Business Machines Corp. vorgesehen ist, wird der Brennpunkt vom Anwender nur auf einen expliziten Befehl des Anwenders hin verändert. Wenn der Anwender den Brennpunkt verändern will, dann bewegt der Anwender den Zeiger auf einen Teil eines Fensters, das teilweise verborgen ist, und dann klickt der Anwender die Maus an, damit sich das Fenster in den Brennpunkt einblendet, so daß dann das ganze Fenster sichtbar wird. Als Alternative kann der Anwender nach einigen expliziten Brennpunktmodellen in der Lage sein, explizite Befehle von einer Tastatur aus als Befehl NEXT WINDOW oder als Befehl PREVIOUS WINDOW zu geben. Ein Befehl NEXT WINDOW verschiebt den Brennpunkt auf ein Fenster, das als erstes nach dem augenblicklichen Fenster in den Brennpunkt kommt. Ein Befehl PREVIOUS WINDOW verschiebt den Brennpunkt auf ein Fenster, das eins vor dem derzeit gezeigten Fenster im Brennpunkt war. Diese Befehle ermöglichen es dem Anwender durch eine Fenster-Warteschlange zu fahren, die in einer Reihe angeordnet ist, inder die verschiedenen Fenster vorher im Brennpunkt standen.
Hier ist anzumerken, daß aufgrund dieser beiden Brennpunktmodelle der Anwender den Brennpunkt nur aufgrund entweder des Orts eines Zeigers auf der Anzeige oder des Platzes eines Fensters in einer Fensterwarteschlange verändern kann (die Fensterwarteschlange wird häufig als systemaktive Objekttabelle bezeichnet). Wenn jedoch ein Anwender den Brennpunkt aufgrund des Inhalts eines Fensters verändern will, bieten ihm herkömmliche Systeme dazu keine Möglichkeit. Wenn der Anwender den Brennpunkt auf ein Fenster schieben will, das eine spezifische Information enthält, versagen die herkömmlichen Systeme beim Verschieben des Brennpunkts auf das gewünschte Fenster. Der Anwender muß den Brennpunkt manuell auf andere Fenster schieben und diese Fenster visuell durchsuchen, um das Fenster mit der spezifischen Information zu finden.
EP-A-0 583 207 mit dem Titel "Method of and Apparatus for Providing Contextual Navigation Mechanism" offenbart eine Methode zur Vorsehen einer automatischen Navigation in einer Mehrprogrammbetriebfensterumgebung zu einem Fenster, das ein von Anwender spezifiziertes Suchkriterium enthält. Ein Anwender kann ein Suchkriterium spezifizieren, und ein Fenster, das dieses Kriterium zum Zeitpunkt der Suche enthält, wird automatisch auf den Brennpunkt eingestellt.
Wenn ein Anwender den Brennpunkt auf ein Fenster einstellen will, das eine spezifische Information zu einem bestimmten Zeitpunkt in der Vergangenheit enthielt, dann sind herkömmliche Systeme nicht in der Lage, den Brennpunkt auf andere Fenster zu verschieben. Der Anwender muß den Brennpunkt manuell auf das andere Fenster einstellen und muß sich auf das menschliche Gedächtnis verlassen, welches Fenster das gesuchte Kriterium enthalten hatte, das zum Zeitpunkt der Suche nicht mehr im Fenster steht.
Der Stand der Technik sieht also kein Verfahren bzw. Gerät zum Durchführen einer automatischen Navigation in einer Mehrprogrammbetriebfensterumgebung auf ein Fenster vor, das irgendwann in der Vergangenheit ein von Anwender spezifiziertes Suchkriterium enthielt. Es ist daher erwünscht, automatisch zu einem Fenster navigieren zu können, das ein Suchkriterium enthielt, das zur Zeit der Suche nicht mehr im Fenster steht.
In dieser Hinsicht besteht Bedarf nach einem Verfahren bzw. einem Gerät, das in einer Mehrprogrammbetriebfensterumgebung ein automatisches Navigationsverfahren zu einem Fenster vorsieht, das in der Vergangenheit ein vom Anwender spezifiziertes Suchkriterium enthalten hatte.

Zusammenfassung der Erfindung

Die hier geoffenbarte Erfindung umfaßt ein Verfahren, ein System und ein Rechnerprogrammprodukt zum Vorsehen einer automatischen Navigation in einer Mehrprogrammbetriebfensterumgebung zu einem Fenster, das ein vom Anwender spezifiziertes Suchkriterium irgendwann in der Vergangenheit enthielt. Das hier beschriebene Verfahren und Gerät eliminiert oder reduziert im wesentlichen die Schwierigkeiten beim Versuch, zu einem Fenster zu navigieren, das dieses Suchkriterium enthalten hatte, durch Vorsehen einer automatischen Navigation zu einem Fenster, das ein vom Anwender spezifiziertes Suchkriterium irgendwann in der Vergangenheit enthalten hatte.
Gemäß einem Aspekt der vorliegenden Erfindung ist eine automatische Navigation zu einem Fenster vorgesehen, das ein von einem Anwender spezifiziertes Suchkriterium beinhaltet. Das Suchkriterium kann zu beliebiger Zeit im Fenster sichtbar gewesen sein solange das Fenster aktiviert war. Das Suchkriterium muß nicht notwendigerweise zum Zeitpunkt der Durchführung der Suche sichtbar sein. Das Fenster kann teilweise verborgen sein, ganz verborgen sein oder als Bildsymbol vorliegen. Das Fenster kann sich als Fenster über den ganzen Bildschirm erstrecken oder ein dimensioniertes Bildschirmformat sein. Ein Anwender kann eine Anzahl Applikationsprogramme aufrufen, die Bildschirmformate und sonstige Objekte auf einen Desktop in Brennpunkt setzen.
Irgendwann im Ablauf der Desktop-Wechselwirkung erinnert sich der Anwender an Daten auf einem Bildschirmformat, die von Interesse sind. Leider gibt es so viele Objekte auf einem Desktop, daß das Bildschirmformat, der die interessierenden Daten enthielt, durch andere Bildschirmformate und Objekte überdeckt ist, die später auf dem Desktop abgelegt wurden. Der Anwender muß dann mit einer Maus oder über die Tastatur eine ermüdende Suche durchführen, um die Desktop-Objekte so umzuordnen, daß das gewünschte Bildschirmformat wieder sichtbar ist. Möglicherweise ist dann das Suchkriterium im gesuchten Fenster nicht mehr sichtbar. Dann ist der Anwender gezwungen, auf sein Gedächtnis zurückzugreifen, in welchem Fenster das gesuchte Kriterium enthalten war.
Ein weiterer Aspekt der vorliegenden Erfindung ist, wenn eine Suche eine Reihe Objekte ergibt, die ein anwenderspezifiziertes Suchkriterium enthalten, dann ist eine Anwenderschnittstelle vorgesehen, um eine Auswahl und Anzeige im Brennpunkt der bei der Suche gefundenen Objekte zu ermöglichen.
Die vorliegende Erfindung hat den Vorteil, daß sie dem Anwender ermöglicht, ein Applikationsprogramm auf einem Desktop zu finden, ohne die ermüdende Objektumordnung auf dem Desktop vornehmen zu müssen, ohne das Suchen durch Ausprobieren und nach seinem Gedächtnis, wobei sich erinnern muß, welches Objekt grade diese bestimmten Daten enthielt.
Ferner hat die vorliegende Erfindung den Vorteil, daß ein Anwender in die Lage versetzt wird, ein Applikationsprogramm auf einem Desktop auf der Grundlage eines vom Anwender spezifizierten Suchkriteriums ausfindig zu machen.
Die vorliegende Erfindung hat ferner den Vorteil, Objekte auf einem Desktop zu suchen, die irgendwann in der Vergangenheit die gesuchten Kriterien enthalten haben. Die Objekte müssen zum Zeitpunkt der Durchführung der Suche die Kriterien nicht mehr enthalten.
Die vorliegende Erfindung hat ferner den Vorteil, zu ermöglichen, daß ein Applikationsprogramm, das durch eine Suche aufgrund eines anwenderspezifizierten Suchkriteriums gefunden wurde, in den Brennpunkt eingeblendet wird.
Die vorliegende Erfindung hat ferner den Vorteil, zu ermöglichen, daß ein Applikationsprogramm in einem voll verborgenen Fenster durch ein anwenderspezifiziertes Suchkriterium gefunden und in den Brennpunkt eingeblendet wird.
Die vorliegende Erfindung hat ferner den Vorteil, zu ermöglichen, daß ein Applikationsprogramm in einem teilweise verborgenen Fenster durch ein anwenderspezifiziertes Suchkriterium gefunden und in den Brennpunkt eingeblendet wird.
Die vorliegende Erfindung hat ferner den Vorteil, daß ein Applikationsprogramm in einem minimierten bzw. als Bildsymbol dargestellten Fenster durch ein anwenderspezifiziertes Suchkriterium gefunden und in den Brennpunkt eingeblendet wird.
Die vorliegende Erfindung hat ferner den Vorteil, zu ermöglichen, daß in einer Vollbildschirmsitzung ein Applikationsprogramm auf der Grundlage eines anwenderspezifizierten Suchkriteriums gefunden und in den Brennpunkt eingeblendet wird.

Kurze Beschreibung der Zeichnungen

Zwecks vollständigen Verständnisses der vorliegenden Erfindung und deren Vorteile wird nun Bezug genommen auf die detaillierte Beschreibung anhand der beiliegenden Zeichnungen, in diesen ist
Fig. 1 ein Blockschaltbild eines Datenverarbeitungssystems, das bei der Durchführung der Methode der vorliegenden Erfindung benutzt wird und Teil der Vorrichtung der vorliegenden Erfindung bildet;
Fig. 2 und Fig. 3 zeigen ein verborgenes Fenster in einer bevorzugten Ausführungsform gemäß der vorliegenden Erfindung;
Fig. 4, Fig. 5a und Fig. 5b zeigen ein als Bildsymbol dargestelltes Fenster und eine Vollbildschirmsitzung in einer bevorzugten Ausführungsform gemäß der vorliegenden Erfindung;
Fig. 6 ist ein Blockschaltbild, das eine bevorzugte Ausführungsform gemäß der vorliegenden Erfindung zeigt;
Fig. 7 ist ein Flußdiagramm, das die Operationen zeigt, die bei der Ausführung des Aspekts der Schaffung des Anwenderschnittstellenobjekts (z. B. Fenster) gemäß der vorliegenden Erfindung bevorzugt werden;
Fig. 8 ist ein Flußdiagramm, das die Operationen zeigt, die bei der Ausführung des Aspekts der Erfassung der historischen Daten gemäß der vorliegenden Erfindung bevorzugt werden;
Fig. 9 ist ein Flußdiagramm, das die Operationen zeigt, die bei der Ausführung des Aspekts der Beendigung des Anwenderschnittstellenobjekts (z. B. Fenster) gemäß der vorliegenden Erfindung bevorzugt werden;
Fig. 10 ist ein Flußdiagramm, das die Operationen zeigt, die bei der Ausführung der Suchaspekte gemäß der vorliegenden Erfindung bevorzugt werden;
Fig. 11 ist ein Flußdiagramm als Fortsetzung von Fig. 10, das die Operationen zeigt, die bei der Ausführung des Aspekts der automatischen Fokussierung gemäß der vorliegenden Erfindung bevorzugt werden; und
Fig. 12 ist ein Flußdiagramm, das die Operationen zeigt, die bei der Ausführung des Aspekts der Verwaltung der Mehrfachergebnisliste gemäß der vorliegenden Erfindung bevorzugt werden.

Detaillierte Beschreibung der Erfindung

Nehmen wir zunächst Bezug auf Fig. 1; dort wird in der Form eines Blockschaltbilds ein Datenverarbeitungssystem 500 gemäß der vorliegenden Erfindung gezeigt. Das Datenverarbeitungssystem 500 umfaßt einen Prozessor 502, der eine Zentraleinheit (CPU - Central Processing Unit) 504 und einen Speicher 506 beinhaltet. Zusätzlicher Speicherraum in der Form eines Festplattenspeichers 508 und eine Diskettenvorrichtung (Floppy Disk) 510 sind mit dem Prozessor 502 verbunden. Die Diskettenvorrichtung 510 nimmt eine Diskette 512 auf, auf der ein Computerprogrammcode oder eine Datenverarbeitungssystemprogrammimplementierung abgespeichert ist, die die vorliegende Erfindung im Datenverarbeitungssystem 500 implementiert. Das Datenverarbeitungssystem 500 kann Anwenderschnittstellen-Hardware beinhalten, einschließlich einer Maus 514 und einer Tastatur 516, um Eingaben an den Prozessor 502 zu ermöglichen, und eine Anzeige 518, um die Daten für den Anwender sichtbar zu machen. Das Datenverarbeitungssystem 500 kann auch einen Kommunikationsport 520 zum Kommunizieren mit einem Netzwerk oder mit anderen Datenverarbeitungssystemen aufweisen. Das Datenverarbeitungssystem 500 kann auch Analogsignalvorrichtungen, einschließlich einer Analogsignal- Eingabevorrichtung 522 zum Eingeben analoger Signale in das Datenverarbeitungssystem 500, und eine Analogsignal- Ausgangsvorrichtung 524 zum Reproduzieren analoger Signale beinhalten. In der bevorzugten Ausführungsform umfaßt das Verarbeitungssystem 500 einen IBMTM PS/2TM Personalcomputer mit einem Betriebsystem wie z. B. OS/2TM.
Nehmen wir jetzt Bezug auf Fig. 2; hier ist ein Computer- Anzeigebildschirm-Desktop 31 dargestellt, in dem das Bildschirmformat B, 32, irgendwann in der Vergangenheit interessante textliche Informationen beinhaltete, aber das Bildschirmformat 32 ist durch andere Bildschirmformate 33 gegen Sicht verdeckt. Die vorliegende Erfindung ermöglicht es dem Anwender, eine Suchkette zu spezifizieren, die in einen Suchdienst eingegeben wird, um die Kette mit dem Text auf Bildschirmformat B, 32, zu vergleichen und das Bildschirmformat automatisch in den Brennpunkt an die Oberfläche zu bringen. Fig. 3 illustriert Desktop 31, nachdem das Bildschirmformat B, 32, durch Vergleich mit dem Suchkriterium gefunden wurde. Dieses Beispiel ist besonders demonstrativ, wenn das Bildschirmformat 32 ganz außer Sicht war, wobei es für den Anwender keineswegs leicht ist, zu wissen, daß dieses existiert und es keinen direkten Weg zum Anwählen gibt. Weiter ist die Fähigkeit vorgesehen, Suchkriterien zu spezifizieren, die nicht unbedingt zum Zeitpunkt der Durchführung der Suche im Bildschirmformat B, 32, vorhanden sind. Bildschirmformat 32, das automatisch in den Brennpunkt kommt, wie in Fig. 3 gezeigt wird, kann das gesuchte Kriterium irgendwann enthalten haben, wenn das Bildschirmformat aktiviert war. Die Tatsache, daß das gesuchte Kriterium irgendwann in der Vergangenheit wenigstens einmal in dem Bildschirmformat vorgekommen war, genügt, um das Bildschirmformat automatisch in den Brennpunkt zu rücken. Das gesuchte Kriterium muß dabei nicht notwendigerweise bei der Durchführung der Suche vorhanden sein.
Ein weiterer Aspekt der vorliegenden Erfindung ist die automatische Navigation zu einer Vollschirmsitzung, die ein vom Anwender spezifiziertes Suchkriterium enthält. Fig. 4 zeigt einen OS/2 Desktop 34 mit Bildsymbolen einschließlich Vollschirmsitzungen für OS/2, 35, DOS, 36, Kommunikations- Manager 37 und LAN-Requester 38.
Fig. 4 zeigt auch einige Bildschirmformate, die den Darstellungs-Manager-Anwendersystemen zugeordnet sind. Man stelle sich vor, was geschehen würde, wenn sich der Anwender erinnern könnte, er habe den Tätigkeitsbericht eines Untergebenen in einen Vollschirm getippt, aber nicht mehr wüßte, in welchen Vollschirm dieser geschrieben wurde. Der Anwender müßte manuell jede OS/2- und DOS-Sitzung, Trial-anderror, durchsuchen, um herauszufinden, in welche Sitzung der Bericht getippt wurde. Die vorliegende Erfindung ermöglicht es dem Anwender, daß er ein Suchkriterium spezifiziert, wie z. B. die Datenkette "PROGRESS". Die vorliegende Erfindung würde dann Desktop-Sitzungen und Objekte durchsuchen, bis sie das Auftreten der Datenkette "PROGRESS" entdeckt. Fig. 5A zeigt, daß eine der OS/2 Vollschirmsitzungen 35 die Textkette enthält, und das System stellt automatisch auf diese Vollschirmsitzung um. Hier ist anzumerken, daß die OS/2 Vollschirmsitzung vor der Übertragung als Bildsymbol dargestellt war. Nehmen wir jetzt Bezug auf Fig. 5B; dort wird ein Vollschirmzustand gezeigt, der manchmal nach dem Vollschirmzustand gemäß der Fig. 5A auftritt. Fig. 5B hätte also als Ergebnis der Suche auftreten können, weil "PROGRESS" irgendwann in der Vergangenheit innerhalb des Vollschirmsitzungsfensters hätte aufgetreten sein können. Es ist nicht wichtig, daß das Kriterium zum Zeitpunkt der Durchführung der Suche nicht vorhanden ist.
Als nächstes befassen wir uns mit Fig. 6; hier wird eine bevorzugte Ausführungsform der Programmimplementierung des Datenverarbeitungssystems der vorliegenden Erfindung gezeigt. Das System beinhaltet einen Suchdienst 41, der ein Programm des Typs 'abschließen und resident bleiben' ist, das das Erfassen eines Befehls zum Durchführen einer Suche erwartet. Eine Hotkey-Sequenz 42, ein gesprochener Befehl 43 usw. kann zum Aktivieren des Dienstes 41 benutzt werden. Bei Erfassen einer Suchanforderung kann dem Anwender eine grafische Benutzeroberfläche (GUI - Graphical User Interface) 44 zum Eingeben der Suchkriterien gezeigt werden (oder auch ein gesprochener Befehl könnte die Daten direkt eingeben, nach denen gesucht werden soll). Nach Eingeben der Suchkriterien ruft der Suchdienst 41 einen Datenketten-Suchmanager 45 zum Suchen der Datenablaufaufzeichnungspuffer auf, die den aktiven Bildschirmgruppen 46 im System zugeordnet sind. Der jeder aktiven Bildschirmgruppe 46 zugeordnete Datenablaufaufzeichnungspuffer wird nach den Suchkriterien befragt. Der Datenketten-Suchmanager 45 ruft auch einen Darstellungsmanager-Suchmanager 47 auf, um in den Systemanwenderschnittstellenkern einzuklinken, um Datenablaufaufzeichnungspuffer, die Fenstern und anderen Objekten 48 zugeordnet sind und die nicht in Systembildschirmgruppen erfaßt sind, zu suchen. Der Darstellungsmanager-Suchmanager 47 ist ein Darstellungsmanager- Schnittstellenmanager für einen eine OS/2-Maschine steuernden Darstellungsmanager, umfaßt jedoch jeden Window- und Bildsymbol-Manager für jedes beliebige System. Nachdem eine Liste erzeugter Sitzungen und Fenster erstellt wurde und vom Datenkettensuchmanager 45 an den Suchdienst 41 überstellt wurde, verwaltet der Suchdienst 41 die Anwendersteuerung zum Transponieren auf ein Vorkommen in der Liste, und um dem Anwender die gegenseitige Zusammenarbeit zu ermöglichen, um auf die nächste Sitzung oder das nächste Fenster entsprechend der Suche in der Liste überzuwechseln. Das Transponieren auf ein Applikationsfenster, Sitzung usw. geschieht genau so, als ob eine Maus oder ein bestimmter Tastenanschlag die Übertragung bewirkt hätte.
Nehmen wir jetzt Bezug auf die Fig. 7 bis 12; hier werden Flußdiagramme gezeigt, die bevorzugte Operationen bei der Ausführung der vorliegenden Erfindung darstellen. In den Flußdiagrammen werden die herkömmlichen grafischen Zeichen - eine Raute für eine Untersuchung oder Entscheidung, und ein Rechteck für einen Prozeß oder eine Funktion - benutzt. Diese Konventionen sind dem Fachmann zur Genüge bekannt und die Flußdiagramme reichen aus, daß jeder Fachmann den Code in jeder geeigneten Computerprogrammiersprache schreiben kann.
Nehmen wir Bezug auf Fig. 7; nach dem Anlaufen des zugrundeliegenden Datenverarbeitungssystems erfaßt Block 10 die Erstellung eines Anwenderoberflächenobjekts. Diese Erstellung kann das Ergebnis der Ausführung des automatischen Datenverarbeitungssystems oder eine Reaktion auf eine Anwenderanwahl sein. Block 10 geht dann über auf Block 20, wo eine Eingabe zu einer aktivierten Objekttabelle hinzugefügt wird. Die aktivierte Objekttabelle kann in einem Darstellungsmanager inhärent sein oder kann auch zusammen mit einem Darstellungsmanager gesondert programmiert sein. Nachdem eine Eingabe in die Tabelle gemacht wurde, bleibt die Verarbeitung stehen. In einer Mehrprogrammbetriebsumgebung kann das Flußdiagramm der Fig. 7 gleichzeitig für eine Vielzahl geschaffener Objekte arbeiten. Eine bevorzugte Ausführungsform einer Eingabe in die aktive Objekttabelle ist:
OBJECT HANDLE - Systembehandlung für ein bestimmtes Objekt
HISTORICAL DATA BUFFER - Zeiger auf die Vergangenheit der dem Objekt zugeordneten Daten
HISTORICAL DATA BUFFER OFFSET - Jetzige Distanzadresse innerhalb des Ablaufaufzeichnungspuffers für die Plazierung der nächsten Daten.
Die Objekthandhabung wird von einem Darstellungs-Manager aufrechterhalten. Zum Beispiel wird die OS/2 Darstellungs- Manager-Funktionsaufrufen zugeordnete Behandlung (z. B. Rücksprung vom WinCreateStdWindow()) in den Aktivobjekt- Tabelleneintrag gespeichert. Der Datenablaufaufzeichnungspuffer enthält Bereiche zum Speichern und Beibehalten der Vergangenheit von Daten, die einem bestimmten Fenster zugeordnet sind. Der Datenablaufaufzeichnungspuffer kann als Datenbehandler oder als Speicherzeiger ausgeführt sein. Die Größe des Datenablaufaufzeichnungspuffers ist konfigurierbar und ist angenommenerweise so groß, daß er mindestens eines der größten Datenstücke unterbringen kann, das von einem Anwenderschnittstellenobjekt gespeichert wird. Die bevorzugte Ausführungsform der vorliegenden Erfindung verwaltet eine Umlauftechnik im Datenablaufaufzeichnungspuffer. Der Datenablaufaufzeichnungspuffer-Offset bezieht sich immer auf das nächste verfügbare Byte im Datenablaufaufzeichnungspuffer, um mit dem Datenablegen anzufangen. Wenn die Daten nicht in den restlichen Datenablaufaufzeichnungspuffer passen, wird der Offset des Datenablaufaufzeichnungspuffers auf das erste Byte im Datenablaufaufzeichnungspuffer gesetzt. Diese Technik stellt sicher, daß die neuesten Daten zu einem Anwenderschnittstellenobjekt gespeichert werden und die ältesten Daten mit den neusten Daten überschrieben werden.
Nehmen wir jetzt Bezug auf Fig. 8; nach dem Anlaufen des zugrundeliegenden Datenverarbeitungssystems erfaßt Block 30, daß ein Anwenderschnittstellenobjekt mit Daten verändert wurde. Die Verarbeitung geht dann auf Block 40 über, wo der zugeordnete Aktivobjekttabelleneintrag des Objekts abgerufen wird. Block 40 geht auf den Entscheidungsblock 50 über, wo eine Abschätzung getroffen wird, ob die veränderten Daten in den Datenablaufaufzeichnungspuffer passen oder nicht. Wenn dort genug Raum ist, um die Daten in ihrer Gesamtheit aufzunehmen, geht die Verarbeitung auf Block 60 über, wo die Daten und ein Schlußzeichen in den Datenablaufaufzeichnungspuffer gesetzt werden, und dann zu Block 80, wo der Offset des Datenablaufaufzeichnungspuffers für Einträge in die aktive Objekttabelle entsprechend auf Stand gebracht wird. Dann stoppt die Verarbeitung. Wenn in Block 50 nicht genug Platz im Datenablaufaufzeichnungspuffer übrig war, um die veränderten Daten in ihrer Gesamtheit zu speichern, dann geht die Verarbeitung auf Block 70 über, wo der Offset des Datenablaufaufzeichnungspuffers für den Eintrag der aktiven Objekttabelle auf das erste Byte im Datenablaufaufzeichnungspuffer gesetzt wird. Dann geht die Verarbeitung mit Block 60 weiter zur Verarbeitung wie vorstehend beschrieben. In einer Mehrprogrammbetriebssystemumgebung kann das Flußdiagramm Fig. 8 gleichzeitig eine Vielzahl geänderter Objekte abarbeiten.
Es ist wichtig, sich über die Verschiedenheit der Ausführungsformen im klaren zu sein, die bei "Objekt wird mit Daten verändert" in Block 30 auftreten können (siehe auch Block 50 und Block 60), weil die gespeicherten Daten die Daten sind, die benutzt werden, um den Suchkriterien zu genügen. Die in einem bestimmten Datenablaufaufzeichnungspuffer enthaltenen Daten sind die Daten, die benutzt werden, um einer Suche zu genügen. Eine bevorzugte Ausführungsform zum Speichern der veränderten Daten ist das Abspeichern lediglich der Daten, die ein Anwender in ein Objekt eingibt. Somit würde Fig. 8 ablaufen beim Erfassen einer Eingabetastensequenz oder Maustastenbetätigung und dabei Anzeigen, daß der Anwender Daten in ein Fenster oder Fensterfeld eingegeben hat. Das heißt, nur die vom Anwender eingegebenen historischen Daten, wie z. B. Befehle, müssen durchsucht werden. Und doch kann eine andere Ausführungsform jede Datenveränderung in ein Anwenderschnittstellenobjekt entdecken und die der Änderung zugeordneten Daten speichern für den Zweck, später zu suchen.
Nehmen wir jetzt Bezug auf Fig. 9; Block 90 erfaßt, daß ein Anwenderschnittstellenobjekt vom Datenverarbeitungssystem beendet wird. Dann geht die Verarbeitung mit Block 100 weiter, wo die dem Objekt zugeordnete aktive Objekttabelleneingabe gelöscht wird. Der Datenablaufaufzeichnungspuffer wird auf geeignete Weise vor der Durchführung des Löschens freigegeben(oder für Dateibehandlungs-Ausführungsformen gereinigt). Die Verarbeitung geht auf Block 102 über, wo der gleiche Eintrag bzw. ein Hinweis auf ihn aus der aktiven Hit- Liste entfernt wird (die Hit-Liste ist in Einzelheiten in Fig. 10 beschrieben, deren Beschreibung noch folgt). Damit bleibt die Verarbeitung stehen. In einer Mehrprogrammbetriebsumgebung kann die Fig. 9 gleichzeitig für eine Vielzahl von Objekten ablaufen. Ein Objekt gilt als aktiv während der Zeit, in der es einen zugeordneten Eintrag in die Aktivobjekttabelle enthält.
Nehmen wir jetzt Bezug auf Fig. 10; hier wird die Suchfolge beschrieben. Block 110 wird ausgeführt als das Ergebnis der Anforderung einer Suche durch einen Anwender. Eine Suche kann jederzeit angefordert werden, insbesondere in einem Mehrprogrammbetriebssystem. Der Anwender kann die Suche anfordern durch Drücken einer Hot-Key-Taste auf der Tastatur, durch Anwahl eines repräsentativen Bildsymbols mit Hilfe einer Maus, oder durch einen sonstigen Aufruf, wie z. B. durch eine gesprochene Befehlsaktivierung. Nach Aufruf durch den Anwender ermöglicht es der Prozeßblock 120, daß der Anwender ein Suchkriterium spezifiziert. Das Suchkriterium ist eine Schriftzeichenkette, die in einer oder in mehreren Datenablaufaufzeichnungspuffern der Objekte auf dem Desktop enthalten sein kann. Nach erfolgreicher Eingabe der Suchkriterien durch den Anwender erlaubt es Block 130, daß der Anwender die Suche aufruft. Eine Vielzahl von Anwenderschnittstellen wie Tastatur, Stimmensteuerung, Mausaktivierung oder dergl. kann auch zur Eingabe der Suchkriterien benutzt werden. Dann setzt Prozeßblock 140 eine globale Variable HIT LIST COUNT auf Null. Die globale Variable HIT LIST COUNT entspricht der Anzahl der Objekte, die als den Datenablaufaufzeichnungspuffern zugeordnet gefunden wurden, die die Suchkriterien enthalten. Anschließend greift der Prozeßblock 150 auf die Aktivobjekttabelle zu. Die Aktivobjekttabelle stellt eine Liste von aktiven Applikationsprogrammobjekten dar, die augenblicklich auf dem Desktop gezeigt werden. Zum Beispiel entspricht im OS/2 Darstellungs-Manager die Aktivdesktoptabelle einer Windowsystemobjektliste, die durch Benutzen der Befehle WinBeginEnumWinows und WinGetNextWindow erzeugt werden. Dann holt der Prozeßblock 160 das nächste Objekt, das in der Aktivobjekttabelle gespeichert ist. Bei dessen erster Ausführung holt der Prozeßblock 160 das erste in der Aktivobjekttabelle gespeicherte Objekt. Anschließend bestimmt der Entscheidungsblock 170, ob es noch weitere Objekte gibt, die in der Aktivobjekttabelle gesucht werden müssen. Wenn noch mehr Objekte in der Aktivobjekttabelle gesucht werden müssen, dann sucht der Block 180 die zugeordneten Datenablaufaufzeichnungspuffer nach dem Vorkommen solcher Suchkriterien durch. Prozeßblock 180 benutzt einen Schriftzeichenkettenvergleich, ob der augenblicklich beendete Datenteil im Datenablaufaufzeichnungspuffer Schriftzeichendaten enthält. Der Prozeßblock 180 benutzt optische Schriftzeichenerkennung in Kombination mit dem Schriftzeichenkettenvergleich, ob der augenblicklich beendete Datenteil im Datenablaufaufzeichnungspuffer Pixel-Bilddaten enthält. Wenn im Entscheidungsblock 190 das Kriterium gefunden wird, dann wird das Objekt zu einer Hit-Liste in Block 200 addiert. Danach erhöht Block 210 die globale Variable HIT LIST COUNT, um die Übereinstimmung zu kennzeichnen, und die Verarbeitung springt zurück zu Block 160 zum Verarbeiten wie vorstehend beschrieben.
Die Flußdiagramm-Verbinder 1000 zeigen den Prozeßfluß von Block 210 (bzw. Block 190) zu Block 160. Die Hit-Liste enthält alle gefundenen Kandidaten, die einen Datenablaufaufzeichnungspuffer haben, der die Suchkriterien enthält. Die Hit-Liste kann eine Liste von Einträgen sein, die mit der aktiven Objekttabelle identisch ist. Eine bevorzugte Ausführungsform der Hit-Liste der vorliegenden Erfindung kann eine Liste der Referenzen sein, wie Zeiger oder Aufzählungen, die sich auf tatsächliche Einträge in der Aktivobjekttabelle beziehen, und dabei die Duplizierung der gleichen Daten an mehr als einer Stelle verhindert. Wird in Block 190 keine Übereinstimmung bei der Suche gefunden, springt die Verarbeitung zurück zu Block 160 zur Verarbeitung wie vorstehend beschrieben. Gehen wir wieder zurück zum Entscheidungsblock 170; wenn es keine weiteren Objekte gibt, für die Suchkriterien entdeckt werden können, geht die Verarbeitung auf Block 220 über. Block 160, Block 170, Block 180, Block 190, Block 200 und Block 210 definieren eine iterative Verarbeitungsschleife, die jedes Aktivobjekt aus der Aktivobjekttabelle bearbeitet. Die Schleife endet, wenn der Fluß vom Entscheidungsblock 170 auf Block 220 übergeht. Block 220 greift auf die globale Variable HIT LIST COUNT zu. Dann vergleicht sie der Block 230 mit Null, und bestimmt auf diese Weise, ob Übereinstimmungen gefunden wurden. Wenn eine oder mehr Übereinstimmungen gefunden wurden (d. h., HIT LIST COUNT > 0), dann fährt die Verarbeitung mit Block 240 fort, wo die globale Variable LAST ACTIVATED ENTRY auf den ersten Treffer in der Hit-Liste (d. i. Treffen) initialisiert wird. Dann fließt die Verarbeitung zu Block 300 im Flußdiagramm in Fig. 11, wie durch die Flußdiagrammverbinder 2000 in Fig. 10 und Fig. 11 angezeigt wird. Wenn, wieder unter Bezugnahme auf den Block 230, keine Übereinstimmungen gefunden werden (d. i. HIT LIST COUNT = 0), dann fließt der Verarbeitungsfluß zu Block 250, wo der Anwender durch eine Meldung NOT FOUND davon unterrichtet wird. Anschließend stoppt die Verarbeitung, und der Anwender ist frei, eine andere Suche auszuführen.
Von Block 240 geht der Arbeitsfluß über auf Fig. 11, Block 300, wie bereits beschrieben. Nehmen wir jetzt Bezug auf Fig. 11; Block 300 greift auf die globale Variable LAST ACTIVATED ENTRY zu, um festzustellen, welches Objekt in der Hit-Liste automatisch in den Brennpunkt gebracht werden muß (z. B., wenn LAST ACTIVATED ENTRY gleich 1 ist, dann greift der Prozeßblock 300 auf das erste Objekt in der Hit-Liste zu), und dann bestimmt der Entscheidungsblock 310, welcher Objekttyp in den Brennpunkt gebracht werden muß. Wenn im Entscheidungsblock 310 das in Block 300 erhaltene Objekt 300 eine Vollschirmsitzung ist, dann geht Block 310 über zu Block 320, der den Anwender auf die Vollschirmsitzung umstellt und das Verarbeiten stoppt. Wenn im Entscheidungsblock 310 das Objekt ein Bildschirmformat ist (d. h. keine Vollschirmsitzung), dann fließt die Verarbeitung zum Entscheidungsblock 330. Wenn in Block 330 die Suche vom Anwender aus einer Vollschirmsitzung aufgerufen wurde, dann fließt die Bearbeitung auf Block 340 über, der den Anwender auf den Desktop umschaltet. Block 340 geht dann zu Block 350 über, wo das richtige Bildschirmformat in den Brennpunkt gebracht wird, und die Verarbeitung stoppt. Nehmen wir jetzt Bezug auf den Entscheidungsblock 330; wenn die Suche vom Desktop aus aufgerufen wurde (d. i. keine Vollschirmsitzung), dann fließt die Verarbeitung von Block 330 zu Block 350, der das richtige Bildschirmformat in den Brennpunkt bringt, wie bereits beschrieben. Block 350 stoppt dann die Verarbeitung. Hier muß angemerkt werden, daß Fig. 11 das richtige Objekt in der Hit-Liste gemäß der augenblicklichen Einstellung der globalen Variablen LAST ACTIVATED ENTRY in den Brennpunkt bringt. Das ermöglicht, daß Fig. 11 unabhängig gemäß der globalen Variablen LAST ACTIVATED ENTRY weiterarbeitet.
Nehmen wir jetzt Bezug auf Fig. 12 und beziehen wir uns auf Prozeßblock 400; der Prozeßblock 400 illustriert einen zweiten vom Anwender aufgerufenen Eingangspunkt für die vorliegende Erfindung. Zusätzlich zum Vorsehen eines ersten vom Anwender aufgerufenen Eingabepunkts beim Aufrufen einer Suche, wie durch den Prozeßblock 110 in Fig. 10 gezeigt wird, sieht das Programm auch einen zweiten vom Anwender aufgerufenen Eintrittspunkt vor, wenn der Anwender das Programm zum Anzeigen des nächsten Objekts in der Hit-Liste aufruft. Nach dem Anlaufen des Programms erwartet Block 400 den Aufruf durch einen Anwender. Der Anwender kann aufrufen durch Anschlagen einer zweiten Hot- Key-Taste auf der Tastatur, durch Auswählen eines zweiten repräsentativen Bildsymbols über eine Maus, oder durch einen anderen, zweiten geeigneten Eingabeaufruf. Nach dem Aufrufen durch den Anwender greift der Prozeßblock 410 auf die globale Variable HIT LIST COUNT zu. Anschließend bestimmt der Entscheidungsblock 420, ob die globale Variable HIT LIST COUNT größer als Null ist. Wenn die globale Variable HIT LIST COUNT nicht größer als Null ist, gibt der Prozeßblock 460 eine Meldung an den Anwender, daß es keine Ergebnisse der aktiven Suche gibt. Diese Meldung ist vorgesehen, wenn keine Objekte in der Hit-Liste stehen, und der Anwender die Anzeige der nächsten Objekte in der Hit-Liste verlangt. Dann bleibt das Programm stehen. Kehren wir jetzt wieder zum Entscheidungsblock 420 zurück; wenn die globale Variable HIT LIST COUNT größer als Null ist, dann greift der Prozeßblock 430 auf die globale Variable LAST ACTIVATED ENTRY zu. Dann bestimmt der Entscheidungsblock 430, ob die globale Variable LAST ACTIVATED ENTRY gleich der globalen Variablen HIT LIST COUNT ist. Wenn die globale Variable LAST ACTIVATED ENTRY nicht gleich der globalen Variablen HIT LIST COUNT ist, dann inkrementiert der Prozeßblock 450 die globale Variable LAST ACTIVATED ENTRY um 1. Dann läuft das Programm bei dem Prozeßblock 300 in Fig. 11 weiter, um das nächste Objekt in der Hit-Liste anzuzeigen. Dieser Bearbeitungspfad ist illustriert durch die Flußdiagramm- Verbinder 2000 in den Fig. 12 und 11. Kehren wir jetzt zurück zum Entscheidungsblock 440; wenn die globale Variable LAST ACTIVATED ENTRY gleich der globalen Variablen HIT LIST COUNT ist, dann setzt der Prozeßblock 470 die globale Variable LAST ACTIVATED ENTRY gleich 1. Das behandelt die Situation, daß das letzte angezeigte Objekt auch das letzte Objekt in der Hit-Liste ist, und das Programm zurück zum ersten Programm in der Hit-Liste gehen muß, um das nächste Objekt anzuzeigen. Anschließend fährt das Programm fort mit Prozeßblock 300, um das nächste Objekt in der Hit-Liste anzuzeigen. Dieser Prozeßpfad wird durch die Flußdiagramm- Verbinder 2000 in den Fig. 12 und 11 angezeigt.
Dem Fachmann ist bewußt, daß der exklusive Zugriff auf die Aktivobjekttabelle und die Hit-Liste auf geeignete Weise innerhalb der asynchronen Auführungsprogrammteile, die durch Fig. 7, Fig. 8, Fig. 9, Fig. 10 und Fig. 11 dargestellt werden, implementiert werden muß. Vorzugsweise wird Semaphor-Steuerung benutzt, um sicherzustellen, daß zu einem bestimmten Zeitpunkt höchstens ein Ausführungsprogrammteil auf die Aktivobjekttabelle oder Hit-Liste zugreift. Ein Zugriffs- Exklusivitätspfad wird erreicht durch Arbeitseinheiten an strategischen Code-Punkten. Zum Beispiel, ist Block 20 in Fig. 7 eine Arbeitseinheit gegen das Betriebsmittel Aktivobjekttabelle, in Fig. 8 ist Block 40, Block 50, Block 60, Block 70 und Block 80 eine Arbeitseinheit gegen die Aktivobjekttabelle. In Fig. 9 ist Block 100 und Block 102 eine Arbeitseinheit gegen die Aktivobjekttabelle und die Hit-Liste. Der Fachmann erkennt ähnliche Stellen in Fig. 10 und Fig. 12.
Zwar wurde die vorliegende Erfindung insbesondere unter Bezugnahme auf eine bevorzugte Ausführungsform gezeigt und beschrieben, der Fachmann erkennt jedoch, daß verschiedene Abänderungen in Form und Einzelheiten vorgenommen werden können, ohne von Umfang und Wesensart der Erfindung abzuweichen.

Claims

1. Ein Verfahren zum Vorsehen einer automatischen Navigation in einer Mehrprogramm-Fensterumgebung zu einem Objekt (32), das zu einer beliebigen Zeit ein von einem Anwender spezifiziertes Suchkriterium (120) enthielt, wobei das Verfahren die folgenden Schritte umfaßt:

Eingabe einer Suchkette;

Suchen (41; 190) nach der Suchkette (45) in historischen Daten (46; 48), die einer Vielzahl von Objekten (32, 33; 35, 36, 37, 38) zugeordnet ist, die in der Mehrprogrammbetrieb-Fensterumgebung angezeigt werden kann; und

Anzeigen des Objekts (32; 35) mit zugeordneten historischen Daten im Vordergrund (340), die die Suchkette (45) enthalten.

2. Das Verfahren gemäß Anspruch 1, in dem der Schritt der Anzeige des Objekts im Vordergrund mit den zugeordneten historischen Daten, die die Suchkette (45) enthalten, ferner die folgenden Schritte aufweist:

Abspeichern einer Identifikation (20; 200) einer Vielzahl von Objekten (32, 33; 35, 36, 37, 38) mit zugeordneten historischen Daten, die die Suchkette enthalten; und

Anzeigen eines dieser Vielzahl Objekte (32, 33; 35, 36, 37, 38) mit zugeordneten historischen Daten im Vordergrund (340), die die Suchkette enthalten, wobei eines dieser Vielzahl Objekte von einem Anwender ausgewählt wird (400).

3. Das Verfahren gemäß Anspruch 1, in dem das Objekt eine Vollschirmsitzung (35, 36) ist.

4. Das Verfahren gemäß Anspruch 1, in dem das Objekt (32) ein verborgenes Fenster ist.

5. Das Verfahren gemäß Anspruch 1, in dem das Objekt (35) ein Fenster in Bildsymbol-Form ist.

6. Das Verfahren gemäß Anspruch 1, in dem die historischen Daten Daten sind, die vom Anwender in das Objekt (35) eingegeben wurden.

7. Das Verfahren gemäß Anspruch 1, in dem die historischen Daten Daten sind, die auf dem Objekt (35) angezeigt werden.

8. Ein System, das Mittel umfaßt, die so ausgelegt sind, daß sie alle Schritte des Verfahrens gemäß einem beliebigen der vorstehenden Ansprüche ausführen.

9. Ein Rechnerprogrammprodukt, das in den inneren Speicher eines digitalen Rechners geladen werden kann, enthaltend Software-Code-Teile zum Durchführen aller Schritte gemäß jedem beliebigen der vorstehenden Verfahrensansprüche, wenn sie auf einem digitalen Rechner laufen.