Method for generating dialogue-windows visually displayed on a computer-screen and equipment for implementing this method

Description Submit all comments and votes

TECHNICAL FIELD

The present invention concerns the generation of dialogue windows displayed on a computer screen and serving as operational interfaces in various applications such as cards, instrument panels, menus, data display or acquisition masks, dialogue boxes etc. A very common application for such dialogue windows consists in the interactive emulation on the screen of actual forms generally comprising fixed elements grouped as a skeleton and active zones, in particular filling zones capable of receiving variable data in a predetermined structure both from the user and from the computer system. Accordingly the dialogue windows of the invention shall also be indiscriminately termed "forms" without thereby restricting it in the above sense. In particular the expression "form" may denote furthermore an interactive and structured presentation which can be visualized at the arbitrary computer or information screen both at the input and at the output, in particular data from external events allowing to activate certain screen zones and transmitted through a keypad and/or a pointer system such as a mouse (illustratively when performing a menu selection, when triggering a particular action...).

BACKGROUND ART

In the past few years and thanks to the appearance of individual work stations and of micro-computers, a large number of non-specialized users have gained access to computers in their most varied forms such as data banks, office automation, expert programming, artificial intelligence. Frequently such access is in the form of an interactive mode wherein the user can enter into a dialogue with the system both at the input and at the output. In this new context, it happens that the user increasingly requires visualized forms that may be changed in order to replay on a screen the amazing diversity of documents present on his desk. Obviously this adaptation must be comparatively easy to carry out by the user and in particular the undesirable constraints resulting from the operational environment application/user to which the sought form shall be related must be avoided or reduced.

The object of the invention is the generation of forms displayed on a screen of a computer system and being inherently autonomous while nevertheless allowing this generation to be of a matching nature (permitting variable routings and modifications) and furthermore being evolutionary depending on the experience of this user (the generation being intended as well for non-specialist users as for expert programmers to whom wide latitude is offered to create forms in their programs).

DISCLOSURE OF THE INVENTION

The invention offers a method for generating dialogue windows, hereafter called forms, which can be displayed on the screen of a computer system comprising a central processing unit and a central memory loaded with operational software, said screen operating in a graphic multi-window mode, each window being displayable on the screen by a contour and provided with a system of local coordinates and with a graphic context, where this method is characterized by the following operations:

1. The form is set up as one or several pages each displayable on a screen window,

2. At least one active zone, page or part of page capable of reacting with at least one data unit constituted by an external event is defined in at least one page,

3. A set of functions, hereafter termed "editor" and comprising at least one reaction function of the active zone responsive to activation by one or more external events, in particular the filling of said zone with variable data, is associated with said active zone, and, in optional manner, a function of editor-validation capable of validating said activation.

The form so created evinces a pronouncedly autonomous character (resulting from its generating mode) because being structured around a base module consisting of an interactive zone, that is, the dual zone which can be displayed on the screen and the editor incorporating the reaction function to the zone. This character is further reinforced by the ability to incorporate into the editor an activation-validation function, in particular for zone filling, which makes it possible to verify the triggering of the reaction. Generated and structured in that manner, the form is easily carried toward such and such user application, the more so its modular structure allows easy modification.

It must be borne in mind that the form generation may be made easier yet by recursivity for each page or part of a page to define active sub-zones in the manner of the same model as that of the above defined active zones.

Furthermore the method of the invention allows simple, reliable and easily checked hook-up with a user-application both at the screen data input toward the system as at the the system output toward the screen.

In a first embodiment mode of the method, an active zone is related not only to its editor but further to at least one action function associated with a user-application program and selected from the following:

a post-validation action-function for the validation of said active zone, ie, FAV,

a pre-display action-function at the display data screen for the data contained in the active zone, ie FAA.

In practical terms, the hook-up with the user application is implemented by means of the action function of which the definition in the form itself may be minimized, that is down to identification allowing to call it. Such a hook-up in no way changes the form's autonomous and portable character.

The method of the invention allows a large number of different embodiment modes which are advantageous both as regards generating the forms and their flexibility of application. Such implementing modes shall be discussed in detail below. In particular as regards another embodiment variation of the method of the invention, the forms are generated either by creation from scratch or by modification or by re-designing a pre-existing form. In still another variation, the method of the invention is implemented in programmed or interactive manner by using a set of of specific, complementary instructions to a programming language of which the programmed interface is loaded into said data or computer system. Advantageously the programming language is of the object and interpretation type (allowing the creation of associated methods and structures).

Another object of the invention is equipment with which to implement a method for generating dialogue windows on the screen of a data or computer system, where this hardware comprises:

a data system with a central processing unit and a central memory loaded with an operational software.

said system comprising at least one screen operating in the multi-window graph mode and at least one input device capable of displacing a pointer on said screen,

an interface programmed by means of a programming language loaded into said system,

a set of software developed at least in part in said programming language by following at least one of the specifications defined by the diverse implementing modes shown herein of the method of the invention.

Presently the method of the invention shall be described in illustrative but non-limiting manner in reference to the attached drawings showing partial and schematic views of the screen of a data system upon which is carried out the method of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows two forms following creation,

FIG. 2 shows a form in the initial stage of creation in association with a menu for creating the form, and

FIG. 3 shows a form during creation and in association with a data window.

BEST MODE FOR CARRYING OUT THE INVENTION

Preferably the method of the invention is implemented using a data system comprising at least a central processing unit, a central memory, a keyboard and an input device capable of positioning a cursor on the screen, for instance a mouse. The system furthermore includes hardware and/or software to operate the screen in the multi-window graphic mode.

The method of the invention is implemented in all its modes shown below by having this data system so defined carry out a set of instruction programs defined and developed to carry out at least three operations:

1. Organizing the form into one or several pages that can be embodied each by a screen window,

2. Defining at least one active zone, page or part of a page defined in at least one page and capable of reacting to at least one data unit consisting of an external event,

3. The association to said active zone of a set of functions, hereafter called "editor", comprising at least one reaction function of the active zone to activation by one or several external events, in particular the filling of said zone with variable data, and optionally an editor-validation function which can validate said activation.

Moreover the data system loaded with this set of programs constitutes an embodiment mode of the equipment with which to implement the method of the invention even in all its variations discussed below.

Be it borne in mind that both the method and the equipment of the invention assure a technical effect, namely either the appearance of a zone of interactive dialogue (form) on the screen or the physical writing into the central memory of coded data in the form of electric signals and as a block representing the defining structure of the form.

Obviously too the invention is not restricted to the particular implementation described below, that is, to the particular equipment being used, or its type, or to the programming language standard being used (here the LISP standard). In particular, the PROLOG standard, which may offer an object layer, also is significant as regards the implementation of the method of the invention. Moreover, where it is desired to carry out the method of the invention in the interactive mode, it will be necessary to resort to a so-called interpreted language, that is, a language allowing direction interpretation of each instruction by the machine.

In the present case the system employs a SUN machine, series 3/50, made by Microsystems Inc., having a memory capacity of 4 megaoctets and associated with a high-resolution screen in support of multi-window display. This system is equipped with an operating software UNIX (by ATT) together with a graphic environment software X-Windows (version X.11) by O'Reilley and Associates Inc (Newton, Mass. 02164, USA).

In general a multi-window graph mode implies defining a window as being displayed on the screen by a rectangular frame and being provided with a system of local coordinates (illustratively x for the horizontal and y orthonormalized vertical) and where called for the definition of a graph context (such as the definition of the background, color and pattern, frame, a display title etc). In the X-Windows environment and for the window management system used in the present case, a horizontal bar appears over each window and represents a certain number of regions. Referring now to the Figures, the bar comprises a dark central zone carrying the window number and upon selection allowing to shift the window on the screen, further three side zones, zone R1 once selected allowing to move the window to the front of the screen, zone R2 once selected allowing to close the window and to reduce it to the state of an icon, and zone 3 once selected allowing to vary the window size.

The form generating method of the invention can be implemented either in totally programmed manner or in interactive manner by means of a particular software set denoted hereafter interactive software "F".

To make use of the inherent advantages of the object programming particularly matching the implementation of the method of the invention, such implementation shall be in the form of a LISP programming interface comprising an object layer, more specifically it will be the Le-Lisp interface in its 15-2 version (graphic function support) which was developed by L'INSTITUT NATIONAL DE RECHERCHES EN INFORMATIQUE ET EN AUTOMATISM (INRIA) at Rocquencourt, 78153 Le Chesnay. France.

To implement the method of the invention in programmed manner, the LISP functions available in the Le-Lisp version 15-2 interface shall be used. However these base functions have been supplemented by a number of functions, or original primitives which are themselves defined from the Le-Lisp version 15-2 interface (on account of latter's opening capacity) and which are recombined as the set of functions "F". Thereby time is saved and flexibility in use is achieved as regards portability compared to other machines for the interface so completed because the Le-Lisp 15-2 functions are directly interpreted to generate the corresponding instructions to the assembly code (in the present instance that of the virtual machine LLM3). Consequently only the "F" functions which are the most representative of the implementation of the method of the invention shall be presented and defined in detail, it being understood that the user familiar with the Le-Lisp language shall be able without undue difficulty to reconstitute complete definition of the other functions "F" presented tersely shown or merely hinted at.

Be it borne in mind that even though strongly recommended, the use of the "F" functions is not mandatory to implement the method of the invention. In any event, the data shown there are sufficient to allow a programmer-user familiar with the the Le-Lisp language to develop the LISP programs corresponding to the "F" functions without exceeding his knowledge, and also the LISP programs, using or not the "F" functions, thus making possible the form generation of the invention. Similarly this programmer shall have the choice of developing programs corresponding to the interactive interface "F" or complementary to it either in LISP or using other languages such as language C or assembly.

In practice and besides the Le-Lisp (15-2 version) interface constituting the core of the system, the following also are loaded, namely a set of programs termed "F" system and further comprising the set of functions LISP "F" complementary to the core primitives, the interactive software "F" and various files used either to operate the system (for instance a mouse interface) or resorted to by the user for specific applications.

At the screen, the LISP interface takes the form of an Input/Output window denoted SUP which is associated to the main loop of the Le-Lisp (TOPLEVEL) interpreter--see FIG. 1.

The selected mouse is the three-button type, the left-hand button being associated by convention with selecting zones or graphic objects on the screen and editor calls, the right-hand button being used for specific operations such as handling certain menus and the center button being left free for the user. The external events from the mouse are processed by the pre-programmed mouse interface which moreover can recognize depression (down), release (up) of a button, the motion (drag) of the mouse and logic events such as the entry of the mouse pointer in the window. At the screen, the position of the mouse pointer is denoted by a small upward arrow (see the Figure). Obviously, the mouse can be replaced by any other cursor means such as optical pen or a graphic table without thereby transcending the scope of the invention. Moreover, the mouse interface is complemented by a keypad interface which is programmed both for the character keys and the pointer and control keys.

Before discussing in detail a variation of the method of the invention, it must be noted that the reader may consult the various instructions manuals for the above hardware and the reference manuals for the available software, especially those relating to UNIX, X-WINDOWS (X-11) and Le-Lisp (version 15-2).

In particular various functions, symbols, and expressions from the Le-Lisp (15-2 version) shall be used herein, retaining however the same coding and the same writing principles. Illustratively the expression below defining a LISP function.

(NAME<x>[<y>]) [SUBR with 1 or 2 arguments]

is interpreted as follows:

NAME is the name of the function,

<x> and <y> are the function parameters, the presence of the brackets [] denoting that the parameter <y> is optional,

SUBR means that the parameters shall be evaluated as arguments of the function (in the LISP sense).

Before the method of the invention shall be exhaustively discussed below together with its features and programmed or interactive implementation, it will be advantageous for ease of understanding to provide several concrete examples of forms generated by the method of the invention.

Referring now to FIG. 1, a small nameless window showing the icon "form" ("F" inside a square frame) associated to the interactive software "F" appears on the window SUP at the top and on the right. This software may be called either in programmed manner into the window SUP or by selection into a utility menu associated with the window SUP.

FIG. 1 also shows the visual display of two forms generated by the method of the invention. These two forms are entirely independent, though used in the present case for the same user-application, namely a data-base management system. The first form realized in the window denoted "Data base" allows carrying out a temporary menu, ie the "Base file" regarding the operations on the data base file. The second form realized by the window denoted "Employee information" concerns an acquisition/display mask for a particular recording of the data base file.

In this embodiment the first form (denoted "table", not showing on the screen) comprises a single page (the screen window "data base") which in this particular case itself constitutes the active zone. This page comprises a skeleton consisting of inert data, the "string" SELECT OPERATION. This page is associated with the temporary menu (displayed by a frame straddling the lower window base) called BASE FILE offering the choice between the operation "new employee" (taken in this instance)to add a new entry to the file, and the operation "see/modify employee" to display an extant entry and possibly modify its contents. The temporary menu associated with the page by the editor "Temporary menu" (PM)is triggered by pressing the left-hand button of the mouse into the page and disappears at the editor output, that is when the left button is released. An operation shall be selected by clicking the left button into one of its two channels "New employee" and "See/modify employee". Due to a link between the form "Data base" and the user-application itself, the menu selection triggers the selected operation in the user application.

The second form (named "employee", not appearing on the screen) also comprises a single page (the screen window "employee information") having seven active zones or parts all in the form of rectangular frames. The first five zones (P1-P5)may receive variable information by means of filling (from the keyboard or the system) while the last two (P6-P7) each represent one skeleton consisting of the string EXIT or the string VALIDATE. These two zones P6-P7 are associated to the "click" editor (CL) and are activated when the lefthand button is pressed in the zone, (resulting in the video inversion), while releasing the button triggers activation validation and, through another so-called post-validation link, together with the user application, the performance of predetermined operations. The first five zones (P1-P5) are activated through an input to an editor (clicking the left-hand button of the mouse in the zone under discussion), thereby triggering authorization to fill the zone, in the present instance by means of text on one line or by means of text in a framed screen on the left for the zone P3. To terminate the description of the single page " employee information" of the form, this form includes a skeleton consisting of the names (shown in column) of the articles corresponding to the first five zones P1-P5.

The two following observations are advantageously kept in mind before detailing the structures of the forms generated by the method of the invention:

In the method of the invention, a form shall actually exist if it can be displayed (that is, loaded into the system central memory). It may be physically visible on the screen but this condition is not mandatory for the form's existence and definition. This original feature shall be widely used by another kind of link to the user application in the form of an action function for pre-display (the visual display call of the form triggering in the user application the performance of various pre-set operations).

A distinction must be made between the form generating operations called building mode from its filling operations; filling entails the possibility of an active zone coming under the control of an editor. Regarding the (construction mode) form generating operations, they combine on one hand the creation of all pieces and on the other hand the modification of an already created form.

Accordingly the method of the invention allows defining the form structure in the light of the points below:

1. A form obtained by the method of the invention consists of a set of pages which materialize on screen windows by the graphic server, each screen window at its creation being positioned relative to a system of coordinates linked to the graphic server (in the present instance the coordinate system associated to the root window defined by the environment X.11 and denoted by the dotted background in the Figures). In case there are several pages, they are linked to each other by reference to the form name but each bears a distinctive title which may merely be the form name followed by the creation number of the page such as "toto:1" in FIGS. 2 and 3.

2. An active zone, that is one associated with an editor to react to an external event when the editor itself is activated, for instance when the zone is being filled; may be either the page itself or part of it (visualized in the example described here by a rectangular zone). In fact this zone is an extension of a preset graphic object, here a graphic rectangle in particular defined by the coordinates of its upper left corner, its width and its height. This extension is carried out by means of variable information association, of the active or inert kind, under the control of an editor. In every case a form shall comprise at least one active zone.

3. A page may or may not contain skeleton objects, parts, editor identification (name), a post-validation function (if any, then associated to a user application by a link function), a pre-display action function (if any, then associated by a link function to a user application), active information and variable information following filling. The active information may be arbitrary on account of the editor display method. The skeleton objects are either preset graphic structures which can be handled as a block on the screen or icons, ie point memories. The page is activated by association with an editor followed by "filling" or by activating the graphic structure. In recursive manner one part may contain the same element types as a page, in particular the sub-parts recursively composed of active sub-zones.

The method of the invention employs the capital characteristic of the active zone editor. To meet the great many applications of the forms generated by the invention, a variation of its method incorporates the operation of defining and compiling a number of typical editors from which only one shall be selected during the association with the active zone.

Generally the editor manages the information filled into the active zone and determines latter's reaction to the external events, in particular to those from the keyboard and the mouse (for instance screen display of the contents, display, whether sequenced or not, drawing a line or a graph). The editor also manages its output, that is the stop of accounting for the external events and possibly the validation of the filled information.

The editors relate as well to the pages as to the parts. They are called or triggered by pressing the left button on the mouse into the page or the particular part. They may be released, in some cases automatically, upon releasing the button. Others may be released by clicking out of the particular part or page. This exit must be distinguished from the filling validation function which exists only in some cases. Lastly some editors allow functionalities accessible through right-hand button thanks to the display of a temporary menu.

The available editors for the example described herein are the following:

Line (LN)

Text editor blocking within the limits of the part (blocking prohibiting the insertion of a character once the right hand limit of the part has been reached),

Triggering is effected by the appearance of the writing cursor.

Filling validation is effected by a carriage return or possibly by clicking out of the part.

Line with advance (LS)C.

Text editor allowing advance

The left button of the mouse allows positioning the insertion point,

The right button allows advancing horizontally the filled text,

The filling validation is identical with that of the line editor (LN),

This is the editor associated by default to a part.

Normal screen (SN)

Screen text editor framed on the left of the part,

Its filling is blocking within the part's limits.

Triggering is caused by the appearance of the writing cursor,

The output is by click out of the part,

The right-hand button validates the filling.

Screen with advance (TS)

the editor is identical to the normal screen editor (SN) except that:

The number of lines is not limited by the part's height, thereby allowing to insert lines below the limits of the part.

Centered screen (SC)

the editor is identical with the normal screen editor (SN) except that:

The text is centered in the part.

Graph (GR)

Editor of graph objects,

Its triggering allows selecting an object and to move it provided the left mouse button not be released,

A click on the right button causes a menu to appear which offers validation of filling and operations on the object which can be implemented by the left-hand button. Among these operations are drawing or decoration (for instance background coloring). In FIG. 3 the display of eight marks consisting of black squares on the rectangle bounding a part denotes the selection and allows modifying the object dimensions.

Menu (MN)

The editor transforms a part into a menu zone containing the name of a list of choices and the articles of the list (in the form of graphic objects, in particular strings of characters),

The selected object is inverted as long as the left button remains depressed (FIG. 1, BASE FILE menu),

Releasing the left button causes editor output and validation of "filling" (object selection).

Cross (CR):

The editor displays (or erases) a cross at triggering,

Validation of activation by releasing the button is optional.

Brightness selection (SE)

The editor darkens (or brightens) the part at triggering,

Validation of activation by button release is optional.

Click (CL)

The editor inverts all the page, or associated part as long as the button remains depressed,

Activation validation is achieved by releasing the button.

Temporary menu (PM)

Input by the left button into this editor triggers the display of a temporary menu built-up from data stored in a so-called user field (UF). IN the embodiment mode of the invention described herein, the information is a LISP list consisting either of title string at the head of the strings of articles or a particular Le-Lisp function called CREATE-MENU preceding the other data and allowing to create effectively the menu only once.

Vertical (SV) and horizontal (SH) advances

Editor allowing the vertical/horizontal advance of the contents of a reservoir part associated with the part under consideration, comprising an advance bar thanks to a function defining a pair of advance bar and reservoir part.

The proper position of the cursor of the motion bar is provided either by re-displaying the bar or after selecting this same bar.

User-editor (EU)

In addition to the preset editors discussed above, the method of the invention also allows the user to create particular editors capable of reading the mouse events and processing them in very specific operations,

In the programmed LISP mode, this entails the creation of special functions, for example

(from #: editutil:select (<part><x><y><same>) (<sl>... <sN>)

In this case this function shall be called when the part <part> with which the editor "editutil" is associated will be selected by the left button of the mouse (event DOWN or DRAG); <x> and <y> are the mouse coordinates relative to the window; <same> is zero (not or () ) if the part hasn't been selected yet, "t" (yes or a symbol different from () ) in the other case, that is in the event of DRAG inside the part.

For some editors (line LN. line with motion LS, cross CR, selection brightness SE), the method of the invention permits sequenced filling of the parts depending on their rank or order numbers; in the programmed mode filling, the order function is defined as follows:

(ORDER--PARTS <part1>--<partN>) [SUBR with arguments].

In case of repetition of a part at the end of the list, there will be infinite looping of filling with destruction of the information filled-in at the end of cycle.

Reference has been made to some links with the user application for the presentation of the two forms illustrated in FIG. 1. Their incorporation into a variation of the method of the invention is highly advantageous. These original link functions assume prime significance because on one hand they they assure the autonomy of the form relative to the user application and on the other they allow its practical use, moreover for simple and flexible implementation.

* The first link function associates a post-validation function (FAV) triggered by filling validation with the part. This first function is applicable in the course of data input from the screen toward the system, for instance in data acquisition or in acquiring a selection carried out by the user during a dialogue.

In the programmed mode, it appears in the form

(FORMPART--COMPUTE >part>.vertline.<fn><argl>--<argN>]) [SUBR with 1, 2 or N arguments].

The function <fn> denotes the post-validation action function (FAV) which is called with 2 mandatory arguments page and part and its optional arguments.

If <fn> is not provided, the link function (FORMPART-COMPUTE) displays the filling function associated with the part.

Illustratively, this link function allows exiting from a blocking filling. In that case the post-validation action function shall be defined as follows:

(from fn(page part((exit endformfilling <sl>--<sN>)).

* The second link function offers communication toward the user application during the system data output toward the screen and in fact it does amount to the inverse of the first function. Prior to the display operation, this second function calls a pre-display action function (FAA). This action function allows filled data manipulation and therefore the simple call of the page re-display function, or the part's, whether explicitly programmed or implicitly by the occurrence of a mouse event in the dialogue window, allows updating a form.

In the programmed mode, it assumes the form (FORMPART--DISPLAYFN <part>[<fn><argl>--<argN>]) [SUBR with 1, 2 or N arguments].

The function <fn> denotes the pre-display action function (FAA) which is called with 2 mandatory arguments the page and the part and its optional arguments.

If there is no filled-in data in the form part, the function <fn> shall be called by default. Illustratively this will allow searching pre-existing information in a data base present in the system prior to display.

Frequently this second link function is associated with a priority function relative to the content of the part between the user (interactive dialogue) and the user application (the data system in the state prior to the display instruction). This priority function offers the choice (option yes or t) to call the pre-display action function before there is any display of information filled in the part (in that case the application has priority); in case of default (option no or nothing), the user shall have priority and the pre-display action function shall be called only in the absence of filled in data.

In the programmed mode, the function is defined as follows:

(FORMPART--APPLI/USER--PRIORITY<part>[<y/n>]) [SUBR with 1 or 2 arguments].

To conclude the discussion of the method of the invention and of diverse variations of implementation in the programmed mode,, other functions "F" so far not discussed but often used shall be surveyed below

A. Functions relating to the form

(CREATE-FORM<name>SUBR with 1 argument].

It creates a form named <name> consisting of a string of characters.

(STORE-FORM<form>[<file><mode>]) [SUBR with 1, 2 or 3 arguments].

Preserves the form in a complete-name file <file> or else (under the name <form>) in an extant file in the current directory of the operating system UNIX.

The mode (1, 2 or 3) specifies the kind of selected safeguard:

mode 1: the form is preserved in its state for instance during creation/construction,

mode 2: the form shall be preserved ready for filling (the part editors then being alerted to be ready for call),. however return to construction mode (for form modification) is authorized, authorization to return to construction mode.

At return, the inverted instruction divides itself into an option for loading the pages without display and an option of loading the pages with display.

B. Page-related function

(ADD-PAGE-TO FORM<form><x><y><w><h>[<title>][SUBR with 5 or 6 arguments]

Adds a new page to the form <form>. The corresponding window is created and displayed at position (<x><y> on the screen with a width <w>and height <h>. If the title <title> is provided, it becomes the title of the window, or else the window title shall be the form name followed by the creation number of the page.

(SHOW-PAGE <page>) [SUBR with 1 argument].

Displays the contents of the page <page>. This function serves to implement the pre-display action function.

(REDISPLAY-FORMPAGE <page>) [SUBR with one argument].

Erases and re-displays the page <page>. This function serves to implement the pre-display action function.

(FILL-PAGE <page>[<tilexit>]) [SUBR with 1 or 2 arguments].

Triggers the page filling mode (alerts the part editors). Provision of expression <tilexit> triggers a blocking filling on the page (that is, there is impossibility to activate another window or to carry out a command prior to filling validation of the zone being considered).

C. Functions and methods concerning the parts:

They apply mostly also to the pages and sub-parts thanks to the possibility of recursivity offered by the Le-Lisp interface.

(SENDQ DISPLAY <part>)

This method allows displaying besides the rectangle the contents of the part (its sub-parts, or skeleton and filled-in information).

(REDISPLAY-FORMPART <part>) [SUBR with one argument].

Erases and re-displays the part <part> (provided the corresponding page be current). This function also is used to implement the pre-display action function.

(ADD-PART-TO-PART <part><x><y><w><h>) [SUBR with 5 arguments].

Adds a new sub-part (part) to the part (page) <part>.

The new sub-part (part) is created at the position <x><y>) relative to its window page. Its contour is not displayed.

The editor associated by default is the line with motion (LS).

(FORMPART-USER <part>[<value>]) [SUBR with 1 or 2 arguments].

Allows reading the value of the field reserved to user for the page or part <part> or to assign to it the value <value>.

ORDER-PARTS (for memory)

D. Functions concerning the editors:

(FORMPART-EDITOR <part>[<editor>]) [SUBR with 1 or 2 arguments].

Associates the editor <editor>to the page or to the part <part>. By default will display the associated editor.

(FORMPART-VALUE <part>[<value>]) [SUBR with 1 or 2 arguments].

If the value <value> is not furnished, this function displays the set of data used in the page or the part <part>by the associated editor.

(FORMPART-FILLED-INFO <part>) [SUBR with 1 argument].

This function displays the information preserved following filling under the editor associated with the page or part <part>.

(FORM ) [SUBR with 1 or 2 arguments].

Associates to the page or part <part> the font of characters, of number or of holes <font>. If the number <font>is not furnished, this function displays the associated font number.

By default, a font of number zero or () is associated to the pages and parts.

(FORMPART-FILLING-VALIDATE <part>[<y/n>]) [SUBR with 1 or 2 arguments].

For the editors "cross" (CR) and "brightness selection" (SE), authorizes or denies the automatic triggering of the post-validation action function of