WO2002054282A1 - Steuerungsmethode für die anordnung von graphischen elementen - Google Patents

Steuerungsmethode für die anordnung von graphischen elementen Download PDF

Info

Publication number
WO2002054282A1
WO2002054282A1 PCT/DE2001/004883 DE0104883W WO02054282A1 WO 2002054282 A1 WO2002054282 A1 WO 2002054282A1 DE 0104883 W DE0104883 W DE 0104883W WO 02054282 A1 WO02054282 A1 WO 02054282A1
Authority
WO
WIPO (PCT)
Prior art keywords
objects
database query
assigned
class
layout manager
Prior art date
Application number
PCT/DE2001/004883
Other languages
English (en)
French (fr)
Inventor
Wolfgang Müller
Andreas Dangberg
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to US10/451,986 priority Critical patent/US8073846B2/en
Publication of WO2002054282A1 publication Critical patent/WO2002054282A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/451—Execution arrangements for user interfaces
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/242—Query formulation
    • G06F16/2428—Query predicate definition using graphical user interfaces, including menus and forms

Definitions

  • the invention relates to the control of user interfaces with graphical elements ('graphical user interface', GUI).
  • a number of tools are available for the creation of programs with a graphical user interface, which facilitate the creation of such programs.
  • Inprise originally Borland
  • the user places objects of the graphical user interface on a work surface and assigns them properties.
  • the classes of these objects are called components in Delphi.
  • the location of the objects is noted on the surface of the compiler system and stored in resource files. This means that the objects are given their position. It is indeed possible to change the situation during the term; however, this requires the specification of pixel coordinates and is therefore correspondingly complex.
  • 5,802,514 shows a system for displaying database contents, which generates a form-oriented display.
  • US Pat. No. 6,104,393 shows a system for integrating procedural and object-oriented user interfaces, in which the form representation is also selected.
  • Other tools developed in the UNIX environment are the programming language JAVA and the Tcl / Tk system. Subsystems called 'layout managers' are used in both. In this environment, the displayed graphic objects are also referred to as 'widgets' in order to distinguish them clearly from the objects of the programming language.
  • a layout manager arranges programming language objects to which a graphical representation is assigned on a surface when it is displayed or changed in size or otherwise.
  • the graphic objects are made known to the layout manager object, and parameters can be used to influence the position without the need for absolute pixel positions. If the number of objects is predetermined, ie fixed during programming, this procedure can be used well. However, if the objects are generated dynamically and are not predetermined, each case requires a separate solution specific to that case.
  • the method should make the visual representation of database queries simple and be suitable for integration into a visual program generator user interface.
  • the invention solves this problem by first creating the widgets as objects and then when the objects are transferred to a layout manager, a set of rules determines the parameters of the objects and their position. This Rules are set up in a table and then either processed interpretively or translated into corresponding program code.
  • the table consists of two parts: a condition and an action. In each case, a pair of objects is checked for the condition and, if the action applies, is made known to the relevant layout manager. This is explained in detail below using an example. It then turns out that it is simply possible to add rules for the reaction to user actions.
  • the method is preferably used in generator systems for the generation of database-querying applications, graphic objects being generated for each line of the result tables and these being arranged on the graphic surface using the method mentioned.
  • FIG. 1 and 2 show two class definitions in Java, which represent an example of the invention, and FIG. 3 shows the result obtained during execution.
  • the invention is described below using a simplified example.
  • the programming language JAVA is used, in the example version 1.1.6.
  • the line numbers prefixed in Fig. 1 and Fig. 2 do not belong to the program text, but are only for reference.
  • the example concerns a telephone chain in which a subscriber calls one or more other subscribers.
  • a tabular data structure is used, which is shown in more detail below and in which the name of a subscriber is linked to his own telephone number and the telephone number of the person from whom he is to be called.
  • FIG. 1 shows the 'layouter' class, which fills a screen area with graphic objects and the execution of which gives a result, as shown in FIG. 3.
  • the graphic objects are all from a class 'aPanel', which is shown in FIG. 2.
  • This class 'aPanel' only consists of the constructor in lines 85 to 92 and three access functions in lines 93 to 95.
  • the 'aPanel' constructor is derived from the 'Panel' class and also defines three variables. In the variables 'myNumber' and 'hisNumber' on lines 82 and 83 two strings, in the example telephone numbers, are stored. Another 'panel' is used, which is nested in the panel of the 'aPanel' class. According to line 85, the structure has three parameters, namely 'who', 'myTel' and ⁇ calledFrom '. These parameters correspond to the columns in the table defining the data.
  • Lines 86 and 87 store the second and third parameters in one variable each. These can be queried using the functions 'getCallee' and 'getNumber' in lines 94 and 95.
  • a 'BorderLayout' is defined as the layout manager.
  • a layout manager arranges a number of graphic objects within an area, here a 'panel', by first specifying the relative position of the objects and later these objects by the layout manager be positioned.
  • Layout managers are an integral part of the surface programming by the 'JAVA AWT' and are therefore described in a large number of publications. They are also available in a similar form in the 'Tcl / TK' programming environment and can therefore be assumed as basic knowledge and viewed as generally known. As a rule, a nested hierarchy of specific layout managers is used and this is also referred to collectively as the layout manager.
  • a 'BorderLayout' allows you to add graphic objects to the 'Panel' and to specify whether they are to be arranged at the top, as 'NORTH', or in the middle, as 'CENTER'. Accordingly, a 'Button' object is arranged in line 89 at the top of the panel of the 'aPanel' object being instantiated.
  • the object 'Button' was chosen for this example because it usually has a frame and can therefore be easily distinguished in the panel. The event control possible with a button is not used in this example.
  • the label of the 'button' contains the name and your own telephone number, as given by the first and second parameters of the constructor.
  • the panel created in line 84 is assigned another layout manager, namely a 'grid layout'.
  • this panel is announced to the layout manager 'Border layout' as the center ('CENTER').
  • This subordinate 'Panel' called 'subPanel' is not yet filled; the invention uses a method described below for this purpose.
  • the 'aPanel' class an area is created in which there is a header with a name and telephone number shown as a 'button', below which there is a subordinate panel in which the objects for the people to be called are to be displayed.
  • the tree structure described in the table would be replicated in order to then ascend the objects from the leaves of the tree to generate so that the layout of the leaves of each node is already completed and can then be integrated into the layout of the next higher node.
  • the invention initially leaves the linkage of the objects open and uses its own method, which is shown below.
  • the class 'Layouter' contains a static function 'main' in lines 51 to 58, which allows it to be called as 'application'.
  • a 'Vector' names 'theData' is created which will contain the data to be displayed.
  • a vector aggregates a number of objects.
  • a number of objects of the class 'aPanel' is instantiated by calling the function 'createData' and stored in the vector 'theData'. This function is representative of the fact that an unspecified number of graphic objects is generated, the arrangement of which is the subject of the invention.
  • a database query for example of a relational database, is used, in which a three-column table is determined for the example and an object of the 'aPanel' class is generated for each row, to which the column values are given as parameters.
  • a database query for example of a relational database
  • a three-column table is determined for the example and an object of the 'aPanel' class is generated for each row, to which the column values are given as parameters.
  • the multitude of techniques available to those skilled in the art for obtaining such amounts of data is represented by the 'createData' function.
  • the example is also particularly simple in that only one table and only one class of objects are used. If the objects, which are not individually predetermined as a rule by number and type, are created in line 54, an instance of the 'Layouter' class.
  • the 'constraint' functions check whether the dependent 'arrCode' function is to be used.
  • the own number of the one ('xx') is compared with the number of the caller ('yy') for equality. If the numbers are the same, 'xx' must be arranged as to be called by 'yy'.
  • the function 'arrangel' does this by calling the class function 'intoPanel', by which the object 'yy' is entered in the subpanel 'subPanel' of the object 'xx'. The same technique is used so that the origin of the telephone chain is entered in the 'frame' of the comprehensive object 'mywin'.
  • Lines 36 and 37 in connection with the function definitions of the called functions represent the code generation for the following table:
  • the first two columns list objects 01 and 02, which are used as parameters in the other columns.
  • the third column lists a condition that, when fulfilled, the action of the fourth column is carried out.
  • the table was converted into code in lines 17 to 40.
  • the table can be presented as a table and processed interpretively.
  • This representation is equivalent to a form in which the condition is an AND operation of two preconditions, which define the class of the parameters, and the actual condition.
  • the latter form is better suited for optimizations.
  • Such an optimization consists of creating a separate vector for each class, in which the objects of the class are aggregated. The pair-forming loop in which the condition is checked then only needs to list the objects of the respective vector. Otherwise, the optimization mentioned above, in which line 37 is shifted before line 34, automatically arises.
  • the table is predefined, i.e. does not depend on the database content if the data is obtained from a database.
  • the invention is preferably used in generator systems for applications by means of which database contents are to be visualized.
  • the user first creates the database queries, for example in the
  • a class is assigned to a row of a result table; and an object of the class is then instantiated for each line at runtime.
  • An object is then created in the generator system for each class and prototypically on the shown graphical interface so that the operator can enter the link of the objects.
  • the entered links are stored in a table as shown above until the generator system generates the application and then preferably implemented in instructions in the associated programming language, so that code similar to that in FIGS. 1 and 2 is produced.
  • two or more objects will be created prototypically in order to be able to represent relationships with each other.
  • Pairs of objects are formed, checked for a condition and, if necessary, supplied with an action.
  • the parent container (the layout object) could just as well be viewed as a global variable and therefore the second row of the table should not be applied to pairs of objects, but only to all objects once. This is to be regarded as the preferred form.
  • An application of tripein or more- Dimensional n-tuples always make sense if a layout manager allows appropriate assignments.
  • the objects were defined as a 'button' for the sake of simplicity, so that the representation of the tree structure appears rather rough and awkward.
  • the objects can also be represented as graphic symbols and thus allow a much denser packing.
  • An object can also contain a pictogram that is selected depending on the data. It is also conceivable that several objects of different classes can be created from one line. In these cases in particular, it makes sense for the table shown above to select the class in the first two columns, making both the condition and the action dependent on the class of the object.
  • the invention makes it possible to generate one or more objects from each row of the result table. Their graphic arrangement is then defined prototypically, and the arrangement of the objects is ultimately only determined during runtime. The same methodology can be used for behavior on events.

Abstract

Methode zur Steuerung der Anordnung graphischer Elemente, deren Plazierung durch eine Layout-Manger-Komponente bewirkt wird, wobei die Elemente nach einer vorbestimmten Verfahren in Tupeln aufgezählt werden und für jedes Tupel eine boolsche Bedingung ausgewertet wird und bei Zutreffen der boolschen Bedinungung ein zugeordnete Anweisung ausgeführt wird, die Steuerungsanweisungen für die Layout-Manager-Komponente umfaßt. Die Methode wird bevorzugt in Generatorsystemen für die Erzeugung von Datenbanken abfragenden Anwendungen eingesetzt, wobei für jede Zeile der Ergebnistabellen graphische Objekte erzeugt werden und diese durch die genannte Methode auf der graphischen Oberfläche angeordnet werden.

Description

Steuerungsmethode für die Anordnung von graphischen Elementen
Die Erfindung betrifft die Steuerung von Benutzeroberflächen mit graphischen Elementen ('graphical user interface ' , GUI).
Für die Erstellung von Programmen mit graphischer Oberfläche sind eine Reihe von Werkzeugen verfügbar, die die Erstellung solcher Programme erleichtern.
Ein Beispiel ist das Compiler-System 'Delphi' der Firma
Inprise (vormals Borland) . In diesem System plaziert der Benutzer Objekte der graphischen Oberfläche auf einer Arbeitsoberfläche und weist ihnen Eigenschaften zu. Die Klassen dieser Objekte werden in Delphi als Komponenten bezeichnet. Die Lage der Objekte wird von der Oberfläche des Compilersystems notiert und in Resource-Files abgelegt. Damit sind die Objekte von ihrer Lage vorgegeben. Es ist zwar durchaus möglich, die Lage während der Laufzeit zu verändern; dies erfordert jedoch die Angabe von Pixel-Koordinaten und ist demgemäß entsprechend aufwendig.
Eine solche dynamische Anpassung wird beispielsweise benötigt, wenn Datenbankabfragen dargestellt werden müssen, deren Umfang erst zur Laufzeit nach der Datenbankabfrage bekannt ist . Zu diesem Zweck sind in Delphi besondere Kompo- nenten vorgesehen, die beispielsweise eine tabellarische Darstellung aller ermittelten Daten erlauben. Zwar sind die Eigenschaften der Darstellung parametrisierbar; natürlicherweise aber nur im Rahmen der vorgesehenen Darstellung. Diese vorgesehenen Darstellungen sind textueller Art und entspre- chen Formularen und tabellarischen Darstellungen. Wird eine andere, insbesondere die Beziehungen der Daten untereinander visuell deutlich machende Darstellung gewünscht, muß entweder eine neue spezifische Komponente erstellt werden oder die gesamte graphische Gestaltung speziell programmiert werden. Beides erfordert in erheblichem Umfang Detailkenntnisse und ist dem Einsteiger in ein solches System zunächst verschlossen und daher auch für den Expterten zeitaufwendig. In der Patentschrift US 5,802,514 ist ein System zur Darstellung von Datenbankinhalten dargestellt, das eine formular-orientierte Darstellung erzeugt. In der Patentschrift US 6,104,393 wird ein System zur Integration prozeduraler und objekt-orientierter Benutzerschnittstellen gezeigt, bei dem gleichfalls die formularmäßige Darstellung gewählt ist . Andere, im UNIX Umfeld entstandene Werkzeuge sind die Programmiersprache JAVA und das Tcl/Tk System. In beiden werden als 'layout manager' bezeichnete Teilsysteme verwendet . In diesem Umfeld werden die angezeigten graphischen Objekte auch als 'widgets' bezeichnet, um sie deutlich von den Objekten der Programmiersprache zu unterscheiden. Ein Layout-Manager ordnet Objekte der Programmiersprache, denen eine graphische Repräsentation zugeordnet ist, auf einer Oberfläche an, wenn diese angezeigt wird oder in der Größe oder sonstwie verändert wurde. Die graphischen Objekte werden dem Layout-Manager-Objekt bekanntgemacht, wobei über Parameter Einfluß auf die Position genommen werden kann, ohne daß dabei absolute Pixelpositionen notwendig sind. Ist die Anzahl der Objekte vorbestimmt, d.h. während der Programmierung fest vorgegeben, ist dieses Vorgehen gut anwendbar. Werden die Objekte jedoch dynamisch generiert und sind nicht vorbestimmt, dann erfordert jeder Fall eine eigene Lösung spezifisch für diese Fall.
Es ist die Aufgabe der vorliegenden Erfindung, eine Methode •anzugeben, mit der die Anordnung von Widgets mit Hilfe von Layout-Managern einfach und zuverlässig gesteuert werden kann, ohne das Programmierung im Detail erforderlich ist. Die Methode soll insbesondere die visuelle Darstellung von Datenbankabfragen einfach machen und zur Integration in eine visuelle Programmgenerator-Oberfläche geeignet sein. Die Erfindung löst diese Aufgabe dadurch, daß zunächst die Widgets als Objekte angelegt werden und sodann bei der Übergabe der Objekte an einen Layout-Manager ein Satz von Regeln die Parameter der Objekte und ihre Position bestimmt. Diese Regeln werden in einer Tabelle aufgestellt und dann entweder interpretativ abgearbeitet oder in entsprechenden Programmcode übersetzt.
Dabei besteht die Tabelle abstrakt aus zwei Teilen: Einer Bedingung und einer Aktion. Jeweils ein Paar von Objekten wird bezüglich der Bedingung überprüft und im Fall eines Zutreffens gemäß der Aktion dem bezogenen Layout-Manager bekanntgemacht . Dies wird weiter unten an einem Bespiel ausführlich erläutert. Es ergibt sich dann, daß es einfach möglich ist, Regeln für die Reaktion auf Benutzeraktionen hinzuzufügen.
Es handelt sich also um eine Methode für die Steuerung der Anordnung graphischer Elemente, deren Plazierung durch eine Layout-Manger-Komponente bewirkt wird, wobei die Elemente nach einer vorbestimmten Verfahren in Tupeln aufgezählt werden und für jedes Tupel eine boolsche Bedingung ausgewertet wird und bei Zutreffen der boolschen Bedinungung ein zugeordnete Anweisung ausgeführt wird, die Steuerungs- anweisungen für die Layout-Manager-Komponente umfaßt. Die
Methode wird bevorzugt in Generatorsystemen für die Erzeugung von Datenbanken abfragenden Anwendungen eingesetzt, wobei für jede Zeile der Ergebnistabellen graphische Objekte erzeugt werden und diese durch die genannte Methode auf der graphischen Oberfläche angeordnet werden.
Es zeigen
Fig. 1 und Fig. 2 zwei Klassendefinitionen in Java, die ein Beispiel für die Erfindung darstellen, und Fig. 3 das bei der Ausführung entstehende Ergebnis.
Die Erfindung wird im folgenden an Hand eines vereinfachten Beispiels beschrieben. Dabei wird die Programmiersprache JAVA verwendet, im Beispiel die Version 1.1.6. Die in Fig. 1 und Fig. 2 vorangestellten Zeilennummern gehören nicht zum Programmtext, sondern dienen nur der Bezugnahme. Das Beispiel betrifft eine Telefonkette, in der ein Teilnehmer jeweils einen oder mehrere andere Teilnehmer anruft. Dazu wird eine tabellarische Datenstruktur verwendet, die weiter unten genauer dargestellt wird und in der der Name eines Teilnehmers mit seiner eigenen Telefonnummer und der Telefonnummer desjenigen verknüpft wird, von dem er angerufen werden soll.
In Fig. 1 ist die Klasse 'Layouter' dargestellt, die einen Bildschirmbereich mit graphischen Objekten füllt und deren Ausführung ein Ergebnis gibt, wie es in Fig. 3 dargestellt ist. Die graphischen Objekte sind in diesem Beispiel alle von einer Klasse 'aPanel', die in Fig. 2 aufgeführt ist. Diese Klasse 'aPanel' besteht hier lediglich aus dem Kon- struktor in Zeile 85 bis 92 und drei Zugriffsfunktionen in Zeile 93 bis 95.
Der Konstruktor von 'aPanel' ist von der Klasse 'Panel' abgeleitet und definiert ferner drei Variablen. In den Variablen 'myNumber' und 'hisNumber' in Zeile 82 und 83 werden zwei Zeichenketten, in dem Beispiel Telefonnummern, gespeichert. Ferner wird ein weiteres 'Panel' verwendet, das in das Panel der Klasse 'aPanel' verschachtelt ist. Der Konstruktur hat ausweislich Zeile 85 drei Parameter, nämlich 'who', 'myTel' und ■ calledFrom' . Diese Parameter ent- sprechen den Spalten der die Daten definierenden Tabelle.
Benutzt wird der Konstruktor in den Zeilen 42 bis 49 von Fig. 1, in denen acht Instanziierungen von 'aPanel' erzeugt werden. In den Zeilen 86 und 87 werden der zweite und dritte Para- meter in jeweils einer Variablen abgelegt. Diese sind durch die Funktionen 'getCallee' und 'getNumber' in Zeile 94 und 95 abfragbar .
In Zeile 88 wird als Layout-Manger ein 'BorderLayout ' festgelegt. Ein Layout-Manager arrangiert eine Anzahl von graphischen Objekten innerhalb eines Bereichs, hier eines 'Panel', indem zunächst die relative Lage der Objekte angegeben wird und später diese Objekte von dem Layout-Manger positioniert werden. Layout-Manager sind fester Bestandteil der Oberflächenprogrammierung durch das 'JAVA AWT' und daher in einer Vielzahl von Publikationen beschrieben. Sie sind in ähnlicher Form auch in der Programmierumgebung 'Tcl/TK' vorhanden und in können daher als Grundkenntnisse vorausgesetzt und als allgemein bekannt angesehen werden. In der Regel wird eine geschachtelte Hierarchie von spezifischen Layout-Managern verwendet und diese auch insgesamt als Layout-Manager bezeichnet. Ein 'BorderLayout' erlaubt es, graphische Objekte dem 'Panel' hinzuzufügen und dabei anzugeben, ob sie oben, als 'NORTH', oder in der Mitte, als 'CENTER' bezeichnet, anzuordnen sind. Demgemäß wird in Zeile 89 ein Objekt 'Button' oben in dem Panel des in Instanzierung befindlichen Objekts 'aPanel' angeordnet. Es wurde das Objekt 'Button' für dieses Beispiel gewählt, weil ein solcher üblicherweise eine Umrahmung hat und damit gut in dem Panel unterscheidbar ist . Die mit einem Button mögliche Ereignissteuerung wird in diesem Beispiel nicht verwendet. Die Beschriftung des 'Button' enthält den Namen und die eigene Telefonnummer, wie sie durch den ersten und zweiten Parameter des Konstruktors gegeben sind. Sodann wird in Zeile 90 dem in Zeile 84 erzeugten Panel ein anderer Layout-Manger, nämlich ein 'GridLayout ' , zugeordnet. In Zeile 91 wird dieses Panel dem Layout-Manger 'Border- Layout' als Zentrum ('CENTER') bekanntgegeben. Gefüllt wird dieses untergeordnetes 'Panel' namens ' subPanel ' noch nicht; die Erfindung benutzt hierzu eine weiter unten beschriebene Methode . Mit der Klasse 'aPanel' wird also ein Bereich erzeugt, in dem eine als 'Button' dargestellte Kopfzeile mit Name und Telefonnummer vorhanden ist, unterhalb derer ein untergeordnetes Panel gegeben ist, in dem die Objekte für die anzurufenden Personen darzustellen sind.
Es sei an dieser Stelle darauf hingewiesen, daß bei Program- mierung nach dem Stand der Technik zunächst die durch die
Tabelle beschriebene Baumstruktur nachgebildet werden würde, um sodann die Objekte von den Blättern des Baumes aufsteigend zu erzeugen, so daß das Layout der Blätter eines jeden Knotens bereits fertiggestellt ist und sodann in das Layout des nächsthöheren Knotens integriert werden kann. Die Erfindung läßt die Verknüpfung der Objekte zunächst offen und verwendet eine eigene Methode, die weiter unten dargestellt wird.
Wenden wir uns nun der Klasse 'Layouter' zu, die den Zeilen
10 bis 59 in Fig. 1 dargestellt ist.
Die Klasse 'Layouter' enthält eine statische Funktion 'main' in Zeile 51 bis 58, die damit einen Aufruf als 'application' zuläßt. In Zeile 52 wird ein 'Vector' names 'theData' erzeugt, der die anzuzeigenden Daten enthalten wird. Ein Vektor aggregiert eine Anzahl von Objekten. In Zeile 53 wird durch Aufruf der Funktion 'createData' eine Anzahl von Objekten der Klasse 'aPanel' instanziert und in dem Vektor 'theData' gespeichert. Diese Funktion steht hier stellvertretend dafür, daß eine nicht vorbestimmte Anzahl von graphischen Objekten erzeugt wird, deren Anordnung Inhalt der Erfindung ist. In der Regel wird hierzu eine Datenbank- Abfrage beispielsweise einer relationalen Datenbank verwendet werden, in der für das Beispiel eine dreispaltige Tabelle ermittelt wird und für jede Zeile ein Objekt der Klasse 'aPanel' erzeugt wird, dem die Spaltenwerte als Parameter mitgegeben werden. Die Vielzahl der dem Fachmann zugänglichen Techniken zur Gewinnung solcher Datenmengen wird hier der Übersichtlichkeit halber durch die Funktion 'createData' repräsentiert . Das Beispiel ist auch insofern besonders einfach, als nur eine Tabelle und nur eine Klasse von Objekten verwendet wird. Sind die, in der Regel nach Anzahl und Art nicht einzeln vorbestimmten, Objekte erzeugt, dann wird in Zeile 54 eine eine Instanz der Klasse 'Layouter' erzeugt. Diese ist aus der Klasse 'Frame' abgeleitet und stellt damit einen (rechteckigen) Rahmen dar, in dem die Objekte durch die Erfindung angeordnet werden sollen. Dies erfolgt in Zeile 55 durch den Aufruf der Funktion 'doArrange', die weiter unten genauer dargestellt wird. Die Instanziierung in Zeile 54 hat den Konstruktor in Zeile 14 bis 16 aufgerufen, der lediglich als Layout-Manger ein 'BorderLayout' festlegt. Dieses ist der Standard-Layout-Manager und hier nur expliziert, um die Struktur deutlicher zu machen. Nachdem die noch zu beschreibende Funktion 'doArrange' die Anordnung der Objekte festgelegt hat, wird in Zeile 56 durch die aus der Klasse geerbte Funktion 'pack' die spezifizierte Anordnung durch die Layout-Manger arrangiert und durch Zeile 57 sichtbar gemacht, so daß das Ergebnis nach Fig. 3 sichtbar wird. Nicht aufgeführt sind in dem Beispiel alle Elemente zur Interaktion, insbesondere eine Ereignisbehandlung zum Beenden der gestarteten Applikation.
In der Funktion 'doArrange' in den Zeilen 29 bis 40 werden nun durch zwei verschachtelte Schleifen alle Paare von in dem Vektor 'theData' enthaltenen Objekten gebildet. Der Einfachheit halber werden hierzu die beiden Variablen 'xx' und 'yy' verwendet, die bereits von dem Typ der in dem Beispiel einzigen Klasse 'aPanel' sind. Kern der Funktion 'doArrange' sind die Zeilen 36 und 37, in denen für jedes Paar ' (xx,yy) ' zunächst eine boolsche Funktion 'constraintl ' (Zeile 17-19) bzw. 'constraint2 ' (Zeile 23-25) aufgerufen wird. Liefern diese Funktionen 'true', wird die Funktion 'arrangel' (Zeile 20-22) bzw. 'arrange2' (Zeile 26-28) aufgerufen. Dabei prüfen die 'constraint ' -Funktionen, ob die abhängige 'arränge' -Funktion anzuwenden ist. Im Beispiel wird in 'contstraintl' die eigene Nummer des einen ('xx') mit Nummer des Anrufenden ('yy') auf Gleichheit verglichen. Sind die Nummern gleich, dann muß 'xx' als von 'yy' anzurufen ange- ordnet werden. Dies erledigt die Funktion 'arrangel' durch Aufruf der Klassenfunktion 'intoPanel', durch die das Objekt 'yy' in dem Unterpanel 'subPanel' des Objekts 'xx' eingetragen wird. Damit der Ursprung der Telefonkette in das 'Frame' des umfassenden Objekts 'mywin' eingetragen wird, wird die gleiche Technik verwendet. Hier besteht die durch ' constraint2 ' formulierte Bedingung darin, daß alle Teil- nehmer, die von niemandem angerufen werden, durch 'arrange2' dorthin eingetragen werden. In dem Beispiel ist das nur ein Teilnehmer bzw. Objekt. In dem Bespiel wird die robuste Funktionalität der JAVA AWT ausgenutzt, weil 'arrange2' mehr- fach mit identischen Parametern aufgerufen wird. In einer optimierten Version würde die Zeile 37 hinter die Zeile 33 verschoben werden.
Die Zeilen 36 und 37 in Verbindung mit den Funktions- definitionen der aufgerufenen Funktionen stellen die Codegenerierung für folgende Tabelle dar:
Figure imgf000010_0001
In den ersten beide Spalten werden die Objekte 01 und 02 aufgeführt, die in den weiteren Spalten als Parameter verwendet werden. In der dritten Spalte wird eine Bedingung aufgeführt, bei deren Erfülltsein die Aktion der vierten Spalte ausgeführt wird. In dem Beispiel wurde die Tabelle in Code in den Zeilen 17 bis 40 umgesetzt. Alternativ kann die Tabelle als Tabelle dargestellt werden und interpretativ abgearbeitet werden.
Im praktischen Einsatz der Erfindung werden fast immer mehr als zwei Klassen von Objekten darzustellen sein. In diesem Fall wird in den ersten beiden Spalten auch die Klasse des Objekts aufgeführt. Für unser Beispiel würde die Tabelle dann so lauten:
Figure imgf000010_0002
Diese Darstellung ist äquivalent einer Form, in der die Bedingung eine UND-Verknüpfung von zwei Vorbedingungen, die die Klasse der Parameter festlegen, und der eigentlichen Bedingung darstellen. Die letztere Form ist jedoch besser für Optimierungen geeignet. Eine solche Optimierung besteht darin, für jede Klasse einen eigenen Vektor anzulegen, in dem die Objekte der Klasse aggregiert werden. Die paarbildende Schleife, in der die Bedingung geprüft wird, braucht dann nur die Objekte des jeweiligen Vektors aufzuzählen. Im übrigen ergibt sich die oben angesprochene Optimierung, bei der Zeile 37 vor Zeile 34 verschoben ist, automatisch von selbst.
Im Gegensatz zu den Objekten ist die Tabelle vordefiniert, d.h. nicht von den Datenbankinhalten abhängig, wenn die Daten aus einer Datenbank gewonnen werden.
Bevorzugt wird die Erfindung in GeneratorSystemen für Anwendungen eingesetzt, mittels derer Datenbankinhalte visuali- siert werden sollen. In einem solchen System erstellt der An- wender zunächst die Datenbankabfragen, zum Beispiel in der
Form von SELECT-Anweisungen einer relationalen Datenbank. Das System ermittelt die Anzahl und die Art der Spalten durch eine Strukturabfrage . In den bislang bekannten Systemen wie dem oben genannten Delphi werden nunmehr graphische Objekte zugeordnet. Diese können dem gesamten Abfrageergebnis zugeordnet sein, meist in Form einer tablellarisch-textuellen Darstellung. Sie können auch einer Zeile zugeordnet sein, die über einen (sichtbaren oder unsichtbaren) Navigator bestimmt wird. Dabei steht jedes Graphik-Objekt in dem Generatorsystem für eine zur Laufzeit anzulegende Instanziierung der zugehörigen Klasse; die Anzahl der Instanziierungen ist also zur Erstellungszeit vorbestimmt.
Bei der Benutzung der Erfindung hingegen wird im einfachsten Fall einer Zeile einer Ergebnistabelle eine Klasse zugeord- net; und zur Laufzeit wird sodann für jede Zeile ein Objekt der Klasse instanziiert . In dem Generatorsystem wird sodann für jede Klasse ein Objekt angelegt und prototypisch auf der graphischen Oberfläche gezeigt, so daß der Bediener die Verknüpfung der Objekte eingeben kann. Die eingegebenen Verknüpfungen werden in einer Tabelle wie oben dargestellt abgelegt, bis das Generatorsystem die Anwendung erzeugt und dann bevorzugt in Anweisungen der zugehörigen Programmiersprache umgesetzt, so daß Code ähnlich dem in Fig. 1 und Fig. 2 entsteht. Häufig werden dabei zwei oder mehr Objekte prototypisch angelegt werden, um Bezüge untereinander darstellen zu können. Dies wäre in dem obigen Beispiel eine mögliche Möglichkeit der Darstellung gewesen, in dem ein Objekt der Klasse ' aPanel ' zunächst mit der Kopfzeile versehen wird, sodann der Rest durch ein Panel ausgefüllt wird und in dieses Panel ein weiteres Objekt der Klasse 'aPanel' eingefügt wird. Dieser Vorgang wird von dem GeneratorSystem erkannt und es wird nach der Bedingung gefragt, unter der diese Plazierung erfolgen soll. Die Aktion selber ist durch die 'drag-and-drop' Operation in dem Generatorsystem selbst bereits festgelegt, falls keine Mehrdeutigkeit für die verwendeten Spalten besteht. Hierzu ist anzumerken, daß in tatsächlichen Anwendungen die Methode bevorzugt für Verknüpfungen von Tabellen angewendet wird, die in der Terminologie der Datenbanken häufig als Referenz ('foreign key') bezeichnet werden. Die obige Tabelle würde die zweite Spalte als Schlüssel und die dritte als Referenz auf dieselbe Tabelle darstellen. In diesen Fällen sind die möglichen
Beziehungen der Objekte bereits über die Datenbankstruktur vordefiniert.
In dem Beispiel und in den meisten Anwendungsfällen werden
Paare von Objekten gebildet, auf eine Bedingung hin überprüft und gegebenenfalls einer Aktion zugeführt. Es ist aber durchaus möglich, nur einzelne Objekte oder Tripel oder andere n- Tupel zu bilden. Im obigen Beispiel könnte genausogut der übergeordnete Behälter (das Layouter-Objekt) als globale Variable angesehen werden und demnach die zweite Zeile der Tabelle nicht auf Paare von Objekten, sondern nur auf alle Objekte einmal anzuwenden sein. Dies ist als bevorzugte Ausprägung anzusehen. Eine Anwendung von Tripein oder mehr- dimensionalen n-Tupeln ist immer dann sinnvoll, wenn ein Layout-Manager entsprechende Zuordnungen zuläßt. In dem Beispiel waren die Objekte der Einfachheit halber als 'Button' definiert, so daß die Darstellung der Baumstruktur eher grob und unbeholfen erscheint. Selbstverständlich können die Objekte auch als graphische Symbole dargestellt werden und damit eine wesentlich dichtere Packung zulassen. Auch kann ein Objekt ein Piktogramm enthalten, das datenabhängig ausgewählt wird. Zudem ist es denkbar, daß aus einer Zeile mehrere Objekte unterschiedlicher Klassen erzeugt werden. Gerade in diesen Fällen ist es sinnvoll, daß die oben gezeigte Tabelle in den ersten beiden Spalten die Klasse auswählt und so sowohl die Bedingung als auch die Aktion von der Klasse des Objekts abhängig macht.
In einer Weiterbildung der Erfindung wird nicht nur die Anordnung der graphischen Objekte durch eine bevorzugt in Programmcode übersetzte Tabelle definiert. Vielmehr werden auch die Aktionen des Benutzers, insbesondere solche durch Ziehen und Loslassen ('drag-and-drop'), spezifiziert. In den bekannten Generatorsystemen sind die graphischen Objekte vorbestimmt, so daß der Benutzer der Systeme die Aktionen als Methoden programmiert, die den entsprechenden Ereignissen zugeordnet sind. Dies ist bei der Anwendung der vorliegenden Erfindung weder möglich noch notwendig.
Allerdings ist auch hier eine Lösung über eine Regel-Aktion- Tabelle gegeben. Eine solche Tabelle könnte lauten:
Drag Drop Aktion aPanel :x aPanel :y y. setCallee (x. getNu ber () )
Damit wird erreicht, daß bei jedem Objekt 'x', welches auf das Objekt 'y' gezogen und dort losgelassen wird, die Nummer von 'x' als neue Nummer des Anrufenden in der Varablen 'hisNumber' (Zeile 83) abgelegt wird. Fast immer wird es notwendig sein, durch eine 'redraw' Nachricht einen Neuaufbau der Anzeige zu veranlassen. Ob die Aktion nun als Methode der 'drop' -Klasse oder sogleich als Datenbankbefehl 'UPDATE...' spezifiziert wird, ist dem Fachmann bei der Gestaltung eines entsprechenden Generatorsystems überlassen. Auch ist eine Erweiterung möglich, bei der die Tabelle nicht nur die Typen, sondern auch die Art des Ereignisses aufführt:
Figure imgf000014_0001
Durch die Erfindung ist es möglich, aus jeder Zeile der Ergebnistabelle ein oder mehrere Objekte zu erzeugen. Deren graphische Anordnung wird dann prototypisch festgelegt, und die Anordnung der Objekte wird letztlich erst während der Laufzeit festgelegt. Die gleiche Methodik ist für das Ver- halten bei Ereignissen anwendbar.

Claims

Patentansprüche
1. Methode zur Steuerung der Anordnung graphischer Elemente, deren Plazierung durch eine Layout-Manager-Komponente bewirkt wird, dadurch gekennzeichnet, daß die Elemente nach einem vorbestimmten Verfahren in Tupeln aufgezählt werden, und daß für jedes Tupel eine bedingte Aktion ausgeführt wird, die Steuerungsanweisungen für die Layout-Manager-Komponente umfaßt .
2. Methode nach Anspruch 1, wobei die bedingte Aktion zerlegt ist in die Auswertung einer boolsche Bedingung und eine zugeordnete Anweisung, die bei Zutreffen der boolschen Bedingung ausgeführt wird.
3. Methode nach Anspruch 2 , wobei vor der Auswertung der boolschen Bedingung überprüft wird, ob die Komponenten der Tupel der bedingten Aktion vorab zugeordneten Klassen entsprechen.
4. Methode nach einem der Ansprüche 1 bis 3 , wobei die graphischen Elemente durch eine Datenbankabfrage erzeugt werden, indem zu jeder Zeile einer Ergebnistabelle der
Datenbankabfrage mindestens ein Objekt erzeugt wird, mit dem ein Element der graphischen Oberfläche verknüpft ist .
5. Methode nach einem der Ansprüche 1 bis 3, wobei den Tupeln zweite boolsche Bedingungen zugeordnet werden, die das Auftreten von Ereignissen für die jeweils angezeigten Elemente betreffen, und diesen Aktionen zugeordnet sind, die eine Veränderung der Daten der Objekte bewirken.
6. Methode nach Anspruch 5, wobei die graphischen Elemente durch eine Datenbankabfrage erzeugt werden, indem zu jeder Zeile einer Ergebnistabelle der Datenbankabfrage mindestens ein Objekt erzeugt wird, mit dem ein Element der graphischen Oberfläche verknüpft ist.
7. Methode nach Anspruch 6, wobei die Veränderung der Daten eine die Datenbank veränderndes Kommando umfaßt .
8. Methode nach einem der vorhergehenden Ansprüche, wobei die Bedingungen und die Steuerungsanweisungen in einer Tabelle gespeichert sind.
9. Methode nach Anspruch 8, wobei die Tabelle in Anweisungen einer Programmiersprache umgesetzt wird.
10. Methode, bei der das Ergebnis einer Datenbankabfrage auf einer graphischen Oberfläche dargestellt wird, wobei das
Ergebnis der Datenbankabfrage aus mindestens einer Tabelle besteht und zu jeder Zeile der Tabelle mindestens ein Objekt einer objektorientierten Programmiersprache instanziiert wird und jedem dieser Objekte ein Element der graphischen Oberfläche zugeordnet ist.
PCT/DE2001/004883 2000-12-31 2001-12-21 Steuerungsmethode für die anordnung von graphischen elementen WO2002054282A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/451,986 US8073846B2 (en) 2000-12-31 2001-12-21 Control method for disposing graphical elements

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10065323.5 2000-12-31
DE10065323A DE10065323C2 (de) 2000-12-31 2000-12-31 Verfahren zur Steuerung der Anordnung von graphischen Elementen

Publications (1)

Publication Number Publication Date
WO2002054282A1 true WO2002054282A1 (de) 2002-07-11

Family

ID=7669208

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2001/004883 WO2002054282A1 (de) 2000-12-31 2001-12-21 Steuerungsmethode für die anordnung von graphischen elementen

Country Status (3)

Country Link
US (1) US8073846B2 (de)
DE (1) DE10065323C2 (de)
WO (1) WO2002054282A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007304666A (ja) * 2006-05-08 2007-11-22 Sony Computer Entertainment Inc 情報出力システム及び情報出力方法
US8195719B2 (en) * 2010-06-11 2012-06-05 Kenneth Ellis Nichol Lampinen Graphical objects bonding society system and method of operation

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5335320A (en) * 1990-10-22 1994-08-02 Fuji Xerox Co., Ltd. Graphical user interface editing system
US5487141A (en) * 1994-01-21 1996-01-23 Borland International, Inc. Development system with methods for visual inheritance and improved object reusability
US5509116A (en) * 1990-03-30 1996-04-16 International Business Machines Corporation Graphical user interface management system

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2694105B1 (fr) * 1992-07-22 1994-11-25 Bull Sa Utilisation d'un langage à interprète embarqué pour la réalisation d'un outil interactif de définition d'interface utilisateurs.
US5544355A (en) * 1993-06-14 1996-08-06 Hewlett-Packard Company Method and apparatus for query optimization in a relational database system having foreign functions
US5669006A (en) * 1995-02-23 1997-09-16 International Business Machines Corporation Method for automatically obtaining spatial layout for multimedia presentations
US5873106A (en) * 1995-09-18 1999-02-16 Oracle Corporation Geometry management for displaying objects on a computer
US5802514A (en) 1996-04-09 1998-09-01 Vision Software Tools, Inc. Automated client/server development tool using drag-and-drop metaphor
US6104393A (en) 1998-06-11 2000-08-15 International Business Machines Corporation Integration of procedural and object-oriented user interfaces
US6559860B1 (en) * 1998-09-29 2003-05-06 Rockwell Software Inc. Method and apparatus for joining and manipulating graphical objects in a graphical user interface
US6938041B1 (en) * 1999-04-30 2005-08-30 Sybase, Inc. Java-based data access object
US6880126B1 (en) * 1999-08-03 2005-04-12 International Business Machines Corporation Controlling presentation of a GUI, using view controllers created by an application mediator, by identifying a destination to access a target to retrieve data
KR200167671Y1 (ko) * 1999-08-17 2000-02-15 김희성 테니스 라켓용 엘보스톱
US7181686B1 (en) * 1999-10-29 2007-02-20 International Business Machines Corporation Selecting screens in a GUI using events generated by a set of view controllers
US6353448B1 (en) * 2000-05-16 2002-03-05 Ez Online Network, Inc. Graphic user interface display method
US6919890B2 (en) * 2000-09-28 2005-07-19 Curl Corporation Grid and table layout using elastics
AU2002233991A1 (en) * 2000-12-06 2002-06-18 American Express Travel Related Services Company, Inc. Layout generator system and method

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5509116A (en) * 1990-03-30 1996-04-16 International Business Machines Corporation Graphical user interface management system
US5335320A (en) * 1990-10-22 1994-08-02 Fuji Xerox Co., Ltd. Graphical user interface editing system
US5487141A (en) * 1994-01-21 1996-01-23 Borland International, Inc. Development system with methods for visual inheritance and improved object reusability

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
AIKEN A ET AL: "Tioga-2: a direct manipulation database visualization environment", DATA ENGINEERING, 1996. PROCEEDINGS OF THE TWELFTH INTERNATIONAL CONFERENCE ON NEW ORLEANS, LA, USA 26 FEB.-1 MARCH 1996, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 26 February 1996 (1996-02-26), pages 208 - 217, XP010158918, ISBN: 0-8186-7240-4 *
CRUZ, I.F., LEVEILLE, P.S.: "Implementation of a constraint-based visualization system", PROCEEDINGS 2000 IEEE INTERNATIONAL SYMPOSIUM ON VISUAL LANGUAGES, 10 September 2000 (2000-09-10) - 13 September 2000 (2000-09-13), Seattle, USA, pages 13 - 20, XP002196194 *
DANGBERG A ET AL: "Generation of interactive visual environments for direct manipulation of database content", VISUAL LANGUAGES, 1999. PROCEEDINGS. 1999 IEEE SYMPOSIUM ON TOKYO, JAPAN 13-16 SEPT. 1999, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 13 September 1999 (1999-09-13), pages 178 - 179, XP010352723, ISBN: 0-7695-0216-4 *
HOWER, W., GRAF, W.H.: "A bibliographical Survey of contraint-based approaches to CAD, graphics, layout, visualization, and related topics", KNOWLEDGE-BASED SYSTEMS, ELSEVIER SCIENCE, B.V., vol. 9, no. 7, December 1996 (1996-12-01), pages 449 - 464, XP002196195 *
KRISHNAMURTHY R ET AL: "RBE: RENDERING BY EXAMPLE", PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON DATA ENGINEERING. TAIPEI, MAR. 6 - 10, 1995, LOS ALAMITOS, IEEE COMP. SOC. PRESS, US, vol. CONF. 11, 6 March 1995 (1995-03-06), pages 288 - 297, XP000551572, ISBN: 0-8186-6912-8 *

Also Published As

Publication number Publication date
US20040090456A1 (en) 2004-05-13
US8073846B2 (en) 2011-12-06
DE10065323A1 (de) 2002-07-18
DE10065323C2 (de) 2003-10-30

Similar Documents

Publication Publication Date Title
DE69835616T2 (de) Verfahren zur verwaltung von objekten und objektverknüpfte parameterwerten in einem simulationsmodell
DE10051645A1 (de) Verfahren und Vorrichtung zur Versionskontrolle und Protokollierung in einem Prozesssteuersystem
EP1061422A1 (de) Informationstechnisches System zur Definition, Optimierung und Steuerung von Prozessen
DE102004043788A1 (de) Programm Generator
DE112011105625T5 (de) Sequenzprogramm-Erzeugungsvorrichtung
DE69434184T2 (de) Verfahren zur vermeidung von unerwünschten interferenzen zwischen diensten
EP0838054B1 (de) Verfahren und steuereinrichtung für eine graphische steuerung von abläufen in einem netzwerkmanagementsystem
DE60032403T2 (de) Speziell adaptierte Wiedergabe und Darstellung von Datenbankinformationen
EP1036352A1 (de) Verfahren zur bildschirmgestützten definition und parametrierung von schnittstellen
EP2171582B1 (de) Fernbedienung eines browser-programms
DE10065323C2 (de) Verfahren zur Steuerung der Anordnung von graphischen Elementen
DE60225464T2 (de) Robotersystem und verfahren und software für das robotersystem
DE60132517T2 (de) Verfahren und System zur Druckablaufplanung, Speichermedium für ein Druckablaufplanungsprogramm
DE19523537A1 (de) Verfahren und Anordnung zur Steuerung von Leistungsmerkmalen einer Vermittlungsstelle
EP1328865A2 (de) Anzeigesteuerung mit aktiven hypertextdokumenten
EP3361366A1 (de) Verfahren und gerät zur automatischen umschaltung von checkboxen
EP2249219A2 (de) Verfahren zur Auswahl eines einem Übertragungsnetz eines Automatisierungs-Systems zugeordneten Kommunikationssystems
EP1234231B1 (de) Verfahren zur erzeugung grafischer benutzerschnittstellen für computerprogramme
DE10016337B4 (de) Verfahren und Vorrichtung zur Erzeugung und Verarbeitung von Daten durch einen aktiven Strukturbaum
DE102004023634B4 (de) Verfahren zur Vollständigkeits- und Konsistenzprüfung einer Informationsbibliothek
DE102021126065A1 (de) Verfahren und System zur Erzeugung und Anwendung eines Modells beim Konvertieren von Daten
EP1332446A2 (de) System, verfahren und computerprogramm zur konfiguration von objekten
EP0740257B1 (de) Verfahren zum Konvertieren von betriebstechnischen Informationen in einer programmgesteuerten Kommunikationseinrichtung
DE202021103037U1 (de) System zur Darstellung von Prozessgrafiken in der Prozess- und Anlagenautomatisierung
WO2003046772A2 (de) Konstruktionsverfahren und cad-system

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PH PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 10451986

Country of ref document: US

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP