RU2305860C2 - System for providing hosting to objects of graphical composition or representation - Google Patents

Abstract

FIELD: engineering of computer components for ordering graphic elements, shown through graphic user interface.

SUBSTANCE: a system of presenting means provides base class of presenting means and a set of interface methods, realized by presentation mechanism, for creation and integration of expandable set of classes of presenting means for processing data of graphical elements of various types during composition operation in given visible image. System of presenting means allows realization of complex image composition operations through calls of presentation mechanism. Aforementioned complex image composition operations include: breaking into pages, partial computation, stepwise computation, a set of samples, alteration of capabilities/operations of composition.

EFFECT: expanded functional capabilities, due to support of compositions of visible images of application, to which a set of graphic elements is assigned.

4 cl, 15 dwg

Description

FIELD OF THE INVENTION

The present invention relates generally to computing devices. In particular, the present invention relates to computing components for arranging graphic elements displayed through a graphical document / user interface.

State of the art

The display and / or visualization of graphical output for an application that runs on a computer system involves many tasks. One such task is layout / presentation management. Layout / presentation management refers to organizing and “decorating” (decorating) a set of image elements in places allocated to them (for example, rectangles). Although the term “layout” and the term “presentation” may differ in other contexts, in the present description these terms should be interpreted as interchangeable and equivalent. Display elements processed by the layout / presentation system provide graphical output to visualization components of the graphics output system and graphics display drivers. These visualization components drive graphics hardware such as monitors and printers.

Layout / presentation operations performed by computing systems encompass a wide variety of functions performed on graphic display elements. An example of such an operation is the ordering of text within the given sizes of the graphical user interface of the editorial application. The layout operation determines the content (content) and placement of lines of text in the designated rectangular space. Another example is framing an element (for example, a dialog box, toolbar, control panel, etc.) with a uniform border. These operations are also called “features” (options). The components of the visualization of the computer system create graphic output based on the state of the display elements, which may have been modified by previously performed operations / layout / presentation capabilities.

Various presentation mechanisms are known. For example, the Microsoft Windows “user module” performs layout operations for high-level windows on the graphical user interface. The Microsoft Windows dialog box administrator places objects at predefined positions and allows you to group objects. The positioning of objects is carried out in a logical order and does not depend on the physical device. The JAVA SWING system performs basic placement operations for objects in the visible image based on the properties specified on the objects.

Layout / presentation operations are currently performed in several ways. The layout operation of the display elements can be completely performed by the application itself. The layout (or “view”) operation is encapsulated in the application. The application performs “decoration” / composes elements for one visible image (or images) associated with the current state of the application. The application arranges the items in the display area allocated to this application. After that, the application visualizes the displayed output data corresponding to the ordered display elements, passing them to the graphics system / drivers.

Another configuration processing configuration option included with the Microsoft Windows XP operating system provides support for a predefined set of layout capabilities that applications may require. The layout feature set contains specialized layout / presentation operations for graphical user interface display elements for applications. A set of predefined layout / presentation capabilities, such as, for example, a border generator for the provided rectangles, reduces the amount of programming work for application developers regarding specific aspects of organizing and representing graphic display elements. This set of predefined capabilities also facilitates compatibility with some basic functionality / display functions that are running, such as the aforementioned boundaries. Applications complement predefined layout functionality with additional layout operations built into the applications themselves.

The well-known layout processing architecture, which includes predetermined layout capabilities that may be required by the application, simplifies the programming of the layout tasks that applications encounter when organizing the visible image before providing graphic data and commands to the visualization components of the computer system. However, the known layout processing architecture has difficulty supporting extensions or modifications regarding a set of predefined layout features that may be required by applications. Thus, new layout features are placed, for example, directly in the application program, instead of including these features in the set of predefined layout features offered by the presentation / layout architecture. Further, during execution, the application performs the calculations for the layout using a combination of predefined layout functionality and the layout / presentation operations performed within the application.

SUMMARY OF THE INVENTION

The present invention includes a system of presenters (presentation modules) for inclusion in the composition of the graphical output data layout control system. The specified layout control is directed to the way in which objects are ordered, set dimensions and placed in the display space. These systems process the layout on behalf of a program that provides graphic elements that contain data representing the displayed content of the program (for example, a block of text that needs to be arranged on a displayed or printed page). Presenters perform an additional role with respect to graphic elements (which define data) by setting display states to represent the content of graphic elements. As such, presenters support the layout description for the corresponding graphic element.

According to the invention, the system of presenters performs the role of the leading node and arranges the presenters associated with graphic elements in the visible image. The system of presenters, playing the role of supporting the process of obtaining (output) presenters of many types, includes the base class of presenters (presentation modules), from which classes of presenters are obtained. After that, presenters are concretized based on the derived classes of presenters.

The presenter system also includes a leading presenter interface. The host interface comprises a method for arranging graphic elements in a visible image in accordance with presenters associated with graphic elements. As such, the layout of the graphic elements in the visible image is set by the respective presenters.

Brief Description of the Drawings

Although the features of the present invention are set forth in detail in the attached claims, the invention and its advantages can best be understood from the following detailed description together with the accompanying drawings, in which:

FIG. 1 is a block diagram showing an example computer system for implementing one embodiment of the invention;

FIG. 2 is a high-level diagram depicting the main components of a layout control architecture including a presenter system for supporting graphic layout in a computing system where the present invention is embodied;

FIG. 3 is a diagram showing relationships between graphic elements and presenters defining a graphical document / user interface in a system where the present invention is embodied;

figures 4a and 4b are the final structure of the base class of presenters, from which classes of objects-presenters are derived according to the requirements of the user, to perform specific layout / visualization tasks in the system where the present invention is embodied;

FIG. 5 - the final structure of the child intermediary class;

FIG. 6 - the final structure of the interface of the class of notification handlers;

FIG. 7 - the final structure of the class of the node of the notification handlers;

FIG. 8 - the final structure of the class of the visible image;

FIG. 9 - the final representation of parts of the BoxSizeInfo structure (information about the dimensions of the rectangle);

FIG. 10 is a summary view of parts of the page descriptor structure;

FIG. 11 - the final structure of the class of the presentation mechanism;

FIG. 12 is a flowchart giving a summary of exemplary steps for processing a change in a graphic element based on a notification handler;

FIG. 13 is a flowchart giving an overview of exemplary steps for performing recalculations and rendering a visible image containing a set of presenters, according to an embodiment of the present invention; and

FIG. 14 is a flowchart giving a summary of exemplary steps for performing an update on a presenter (and associated affiliated presenters) in response to a change in a graphic element relating to it.

Detailed Description of Drawings

The following describes the user interface architecture and layout / presentation of the document.

The disclosed layout / presentation architecture includes components (presenters, presentation modules) of the graphic processing / visualization of the layout, which implement the aspects of the visible image of the corresponding basic data (graphic elements) for the document / user interface. The system of presenters hosts (hosts) presenters. Fulfilling its leading role, the system of presenters organizes and coordinates the updating of the visible image containing the set of presenters in response to changes in the corresponding graphic elements. Thus, the system of presenters provides a mechanism that associates the state (for example, the state of data) of graphic elements with the states of the visible image, updated, cached and visualized using the corresponding presenter objects.

One aspect of the layout / presentation architecture based on the presenter system in which the present invention is embodied is a high degree of extensibility with respect to the types of presenters it manages. The base class of presenters provided by the system of presenters facilitates the expansion of the set of types of presenters (object classes) available for composing and visualizing the information provided by the corresponding graphic element. Various types of presenters derived from the base class of presenters include specific layout / visualization methods as overrides for the default methods specified by the base class of presenters. Presenter objects created on the basis of a set of classes of presenter objects realize the layout / presentation capabilities according to the data state of the corresponding graphic element.

The presenter system manages presenter objects created (set) based on a set of presenter object classes. The system of presenters implements management (that is, creation, deletion, etc.) throughout the entire existence of presenter objects. The presenters system provides processing related to monitoring the “contamination” of presenters for the selective updating of only modified presenters. The presenter system supports the coupling of presenters to provide elements of “decoration” (decoration) to the main presenters. The presenter system also coordinates the updating and visualization of presenters.

In one embodiment of the invention, the presence of notification handlers facilitates notification of changes to graphic elements that potentially affect the state of the visible image. Notification handlers provide the ability to process change notifications that are allocated from presenters' change processing. Each type of presenter item is associated with a type of notification handler. Each notification handler processes changes to the corresponding graphic element. If an update is necessary, then the notification handler initiates the setting of the “pollution” property in the corresponding object of the presenter. The established “pollution” property causes repeated calculations for the presenter object in response to changes in the corresponding graphic element.

The layout / presentation architecture of the user interface described here as an example is included in the operating system, which provides hosting for applications that have graphical user / document interfaces. Device-specific visualization applications, presenters, and operating system components, as well as device-specific drivers, visualize commands / data for controlling graphic / interface output devices for displaying document data (for example, monitors, printers and etc.). The capabilities (options) of the layout of the rendered output are based, at least in part, on the processing of the layout / presentation and visualization performed by the presenters hosted by the presenter system.

The presentation architecture allows you to break the connection between the data state of the displayed element and the state of its visible image. This disconnection provides an extensible platform with extensive customization capabilities by the user to create new and specialized capabilities for the base graphic element. In one embodiment of the invention, the display element is represented by a graphic object (representing the state of the element's data) and at least one associated with it a presenter object (representing the state of the visible image) for arranging (placing) the element in a particular visible image. The presenter performs a custom layout update for the item associated with it. The presenter also renders the image of the element after updating the layout.

Using presenter objects eliminates the relationship between the data state of the displayed item and its display in the visible image. As a result, each graphic element (display data source) is potentially capable of having many presenters providing separate visible images of the graphic element (for example, a full-scale and minimized image of a photographic element). The ability to associate multiple presenters with one graphic element also allows you to associate one element with many places inside the field (for example, splitting one graphic element into many columns). In addition, the system of presenters supports the linking of many individual presenters of various types with one element, as a result of which the fixing of many different "decoration" elements configured by the user to the basic visible image for the element is supported. Next, with reference to the drawings, these and other aspects of an exemplary image composition / rendering architecture are described.

In FIG. 1 illustrates, by way of example, a suitable operating environment 100 for implementing a layout / presentation architecture of mappings based on a presenter system. Operating environment 100 is just one example of a suitable operating environment, and should not be construed as limiting the scope or functionality of the invention. Other well-known computing systems, environments and / or configurations that may be suitable for use with this invention include, but are not limited to: personal computers, server computers, portable / desktop computing devices, portable computing devices, multiprocessor systems, microprocessor-based systems, networked personal computers, minicomputers, universal computers, distributed computing environments that include any of the above systems systems or devices, etc. The layout control architecture disclosed herein, for example, the architecture shown in FIG. 1, including a presenter system, meets a number of different requirements, including extensibility, integration, and uniformity with respect to display functionality for a computing system.

The invention is described in the general context of a set of steps and processes implemented by instructions, such as program modules, executed by a computer. Typically, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Although the example embodiment described is described with reference to locally performed operations in a single computer system, the invention can potentially be included in network nodes operating in distributed computing environments where tasks are performed by remote processing devices that are interconnected via a communication network. In a distributed computing environment, program modules are typically located in both local and remote computer storage environments, including storage devices.

Referring to FIG. 1, an exemplary system for implementing the invention includes a general-purpose computing device in the form of a computer 110. Components of a computer 110 may include, but are not limited to, a processing unit 120, a system memory 130, and a system bus 121 , which associates various system components, including system memory, with processing unit 120. A system bus can be any of several types of bus structures, including: a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of different bus architectures. By way of example, but not limitation, such architectures include: industry standard architecture (ISA) bus, microchannel architecture (MCA) bus, ISA advanced architecture bus (EISA), local bus developed by the Video Equipment Standards Association ( VESA), and the Peripheral Component Interconnect (PCI) bus, also known as the Mezzanine bus.

Computer 110 typically includes many different computer readable media. A computer-readable medium can be any available medium that can be accessed by computer 110, and includes both volatile and non-volatile media, removable and non-removable media (media). As an example, but not limitation, a computer-readable medium may comprise a computer storage medium and a communication medium. A computer storage medium includes both volatile and non-volatile, both removable and non-removable media implemented in any way or by any technology for storing information, such as computer-readable instructions, data structures, program modules or other data. A computer storage medium includes, but not only: RAM, ROM, electrically erasable ROM (EEPROM), flash memory or other memory technology, ROM on a compact disc (CD-ROM), digital versatile disks (DVD) or other optical disk storage device, magnetic tapes, magnetic tape, magnetic disk storage device or other magnetic storage device, or any other medium that can be used to store the required information and which can be accessed by computer 110. Communication mediumtypically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal, such as a carrier signal, or other data transport mechanism, and includes any information delivery medium. The term "modulated data signal" means a signal that has one or more characteristics set or changed in such a way as to encode information in this signal. By way of example, but not limitation, a communication medium includes a wired medium, such as a wired network or a direct wired connection, and a wireless medium, such as an acoustic, radio frequency (RF), infrared, or other wireless medium. Combinations of any of the aforementioned environments may also be included within the scope of computer-readable media.

System memory 130 includes a computer storage medium in the form of volatile and / or non-volatile memory, such as read-only memory (ROM) 131 and random access memory (RAM) 132. A basic input / output system (BIOS) 133 containing basic routines that help transfer information between items on a computer 110, for example during startup, is sometimes stored in ROM 131. RAM 132 typically contains data and / or program modules that are directly accessible and / or are currently being processed by processing unit 120. By way of example, but not limitation, in FIG. 1 shows an operating system 134, application programs 135, other program modules 136, and program data 137.

Computer 110 may also include other removable / non-removable, volatile / non-volatile computer storage media. As an example in FIG. 1 shows only a hard disk drive 140 that reads from or writes to a non-removable, non-volatile magnetic medium (medium), a magnetic disk drive 151 that reads from or writes to a removable non-volatile magnetic disk 152, and an optical drive 155 which reads from and writes to a removable non-volatile optical disk 156, such as a CD ROM, or other optical medium. Other removable / non-removable volatile / non-volatile storage media that can be used in the example operating environment include, but are not limited to: magnetic tape cartridges, flash memory cards, digital versatile disks, digital video tape, solid state RAM (RAM) , solid state ROM (ROM), etc. The hard disk drive 141 is typically connected to the system bus 121 via a non-removable memory interface such as interface 140, and the magnetic disk drive 151 and the optical disk drive 155 are usually connected to the system bus 121 via a removable memory interface such as interface 150.

The drives and associated computer storage media described above and shown in FIG. 1 provide for the storage of computer readable instructions, data structures, program modules and other data for computer 110. FIG. 1 as an example, it is shown that the hard disk drive 141 stores the operating system 144, application programs 145, other program modules 146 and program data 147. Note that these components may be the same or different from the operating system 134, application programs 135, and other software modules 136 and program data 137. The operating system 144, application programs 145, other program modules 146 and program data 147 are represented here by different reference numbers to show that they are at least different copies. The user can enter commands and information into the computer 20 through input devices, such as a keyboard 162 and pointing device 161, which is usually understood as a mouse, trackball or touch keyboard. Other input devices (not shown) may include a microphone, joystick, gaming keyboard, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 120 via an input user interface 180 that is connected to the system bus, although these devices can be connected via other interface and bus structures, such as a parallel port, a game port, or a universal serial bus (USB) . Through an interface, such as video interface 190, a monitor 191 or another type of display device may also be connected to the system bus 121. In addition to the monitor, computers can also include other peripheral output devices, such as speakers 197 and a printer 196, which can be connected via an output peripheral interface 195.

Computer 110 potentially operates in a networked environment using logical connections to one or more remote computers, such as remote computer 180. Remote computer 180 may be a personal computer, server, router, network personal computer, peer device, or other common network node, and typically includes many or all of the elements described above in connection with computer 110, although in FIG. 1 shows only the storage device 181. The logical connections shown in FIG. 1 include a local area network (LAN) 171 and a wide area network (WAN) 173, but may also include other networks. Such networking environments are widespread in offices, corporate computer networks, intranets, and the Internet.

When used in a LAN network environment, computer 110 is connected to LAN 171 via a network interface or adapter 170. When used in a WAN network environment, computer 110 typically includes a modem 172 or other means for establishing communication over a WAN 173 network, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via an input user interface 160 or other suitable mechanism. In a networked environment, program modules depicted in relation to computer 110 or parts thereof may be stored in a remote storage device. By way of example, but not limitation, in FIG. 1, remote applications 185 located in memory 181 are shown. It will be appreciated that the network connections shown are exemplary and that other means can be used to establish a communication link between computers.

In FIG. 2 is a high-level diagram identifying program modules and programs, as well as specific objects and data components of the architecture of a layout / presentation control system in which the present invention is embodied. The exemplary layout / presentation management system architecture shown in FIG. 2 includes a presenter system 200 that supports layout / presentation of displayed objects based on a set of hierarchically ordered presenter objects associated with the visible image 202 being created, based on the visible image object class (see FIG. 8, described below) when requesting application 204 running on operating system 205.

In one embodiment of the invention, each visible image (e.g., visible image 202) has a corresponding presenter system (e.g., presenter system 200) that is responsible for maintaining the displayed objects in the visible image. In one embodiment of the invention, image 202 is a visual root object for all visual objects that are created by presenter system 200. The displayed content in the visible image 202 is based on graphic elements 206 in the auxiliary storage device 208. Application 204 is a source of graphic elements 206 in the auxiliary storage device 208. In FIG. 3, described below, an example is shown where the relationships between visible images, presenter systems, presenter trees for visible images, and graphical trees associated with the application are presented.

The layout / presentation control system architecture shown in FIG. 2, is divided into many functional components. The lines between the components shown represent the interaction paths between the components. The present invention is not limited to a specific arrangement of components and shown as an example of interactions between components in the illustrative embodiment shown in figure 2. Conversely, the functionality of the components described below is grouped in various combinations according to alternative embodiments of the invention.

In one embodiment of the invention, application 204 calls a constructor method on the application program interface of object classes — visible images (see the structure of visible image classes in FIG. 8, described below) to create a root object for an object instance — a visible image 202. Calling a method to create a visible image 202 passes through a link to the root graphic element of the graphic elements 206 located in the auxiliary storage device 208. After creating the visible image 202, the method call DoLayout (layout) on the visible image 202 creates a presenter tree for the visible image 202 with the root presenter object corresponding to the root graphic element originally passed to the constructor method that created the visible image 202. The presenter tree (not shown in FIG. 2) for the visible image 202 contains a set of presenters who are responsible for organizing and visualizing the output for the visible image 202.

In one embodiment of the invention, each visible image (e.g., visible image 202) has a presenter system (e.g., presenter system 200). Thus, in response to a call to the DoLayout method, the visible image 202 initiates the creation of a new presenter tree and returns it to the caller (for example, application 204). In the initial state, the visible image 202 calls the constructor method from the class of presentation mechanism objects to create an instance of the presentation mechanism 212, which includes the presenters 'application programming interface (presenters' leading API). The presentation engine 212 includes an executable program for coordinating and organizing the execution of layout / presentation operations in a computer system supporting graphical output. The functions performed / coordinated by the presentation engine 212 include: creating presenter objects (both root and child versions), coordinating recalculations of presenter display states, visualization, managing presenters throughout their entire existence, monitoring “contamination”, coupling multiple presenters with one element and step-by-step layout. Examples of invoked methods on the presenter’s host API of the presentation engine 212 are described below with reference to FIG. 12. These methods are high-level queries that create and maintain a tree of presenter objects for the visible image 202. The identified tasks performed by the presentation engine 212 are given as examples, and those skilled in the art should understand that in alternative embodiments of the invention presentation engine 212 may solve additional / alternative tasks.

Presentation engine 212 constructs a presenter system 200 for processing presenter objects associated with the visible image 202. In one embodiment of the invention, the presenter system 200 includes a base class 216 of presenters. The base class 216 of presenters is a base class with a full set of capabilities for creating subclasses of presenters and presenter objects that can use the layout control functionality for the system described below. The base class 216 of presenters contains a template that includes virtual (redefinable) program code and data structures from which a set of classes of 214 presenters is obtained. Classes 214 of presenters contain a set of specialized types of presenters corresponding to visible images of graphic elements having specific properties / display modes. Presenter classes 214 created for the user’s requirements, obtained from the base class of 216 presenters, for example, compose content, organize child presenters, create visuals for the elements attached to them, paginate content for printing documents and update the visuals step by step, including graphic elements 206. The specialized functionalities of each class of presenters in the set of classes of 214 presenters are established by redefining and adding to practical methods defined by the base class of 216 presenters. Presenter objects, concretized based on a set of presenter classes 214, present and process display aspects of graphic elements 206.

In one embodiment of the invention, the set of presenter object classes 214, including both predefined presenter classes 218 and external presenter classes 220, is extensible. For a set of predefined classes of 218 presenters, a system of 200 presenters is provided. Outer classes of 220 presenter objects are typically set independently of the 200 presenter system. However, properly combining the outer classes of 210 presenter objects with the presenter system 200 is facilitated by the published interface specification for the base presenter class 216 (described below with reference to figures 4a and 4b). The developer of the external classes of 220 presenters redefines / modifies the machine code and data structures associated with the user-configured layout / visualization methods of the base class 216 of presenters to provide functions for sizing, positioning of child presenters and visualization taking into account the user's requirements. After that, a new class of presenters is installed in the set of external classes 220 of presenter objects, for example, by installing a file containing a new class of objects in the designated directory in the computer file system.

In one embodiment of the invention, the presenter class 214 includes presenter classes for implementing layout capabilities (options), including, for example: arranging content, arranging children, creating visuals, paginating document content, and incrementally updating visuals (e.g. HTML pages, which cover many display screens). Examples of special types of presenters include: a text presenter, which provides measurements and display of text formatted in various ways (for example, bold, Italian, etc.); image presenter, which provides measurement and display of a given image; and a docking presenter, which divides the space between multiple subsidiary presenters.

After creating a system of 200 presenters and classes of 214 presenters for a given visible image, a set of presenter objects associated with the visible image 202 and a system of 200 presenters are specified, starting with the root presenter object. Note that invoking the constructor method for the class of the presentation engine object to create the presentation engine 212 identifies the root graphic element for the visible image 202. After installation, the presentation engine 212 calls graphic elements 206 to determine the type of presenter object associated with the root graphic element for the visible images 202. After determining the type of presenter of the graphic element, the presentation engine 212 calls the method in one of the classes 214 of the objects of the presenters, with Resp presenter object type identified by the graphical elements 206 for the purpose of assignment of the root presenter object for the values of the visible image 202.

As shown by the path between the presenter classes 214 and the auxiliary storage device, presenter objects, including the root presenter, access the graphic elements 206 in the auxiliary storage device 208 to determine the properties of specific graphic elements. For example, a presenter object for a particular graphic element is able to identify any child graphic elements of a particular graphic element and the type of presenter for each child graphic element. Next, the presenter object calls its own 486 method for each identified child graphic element (for example, GetChildProxyForElement (get the child intermediary for the element)) to implement the child intermediary (proxy) intermediary object from the class of 222 child intermediaries of the system 200 presenters. Subsidiary intermediary (proxy) objects are wrapper objects (wrappers) for presenter objects implemented (created) based on classes of 214 presenter objects that are embedded in the display space allocated for the parent presenter object. The child intermediary class 222 satisfies the encapsulation and security requirements (for example, a child presenter object using the parent presenter object or application 204 restricts access to presenter content contained in the child presenter). Alternatively, the encapsulation level provided by child intermediaries is skipped, and parent presenters have direct access to their child presenters.

A method for a presenter object to create a child intermediary object for one element in one embodiment of the invention calls a constructor method from the class 222 of child intermediaries and passes the identity of the child graphic element to create a new child intermediary (proxy) object and the presenter object for the child graphic element. Immediately after creation (implementation), a new child intermediary object creates a presenter object for the child graphic element through the presenter constructor corresponding to the type of presenter defined on the identified child graphic element. In turn, the child intermediary object returns its own link to the parent object of the presenter. The presenter’s parent maintains the returned link of the child broker in the array of links to child brokers. As such, the entries in the array of child mediation objects for the presentation object correspond to the child graphic elements for the parent graphic element with which the parent presenter is associated.

Another aspect of the graphical ordering / presentation architecture shown in FIG. 2 is a change notification. In one embodiment of the present invention, presenter objects created from presenter classes 214 are provided with a set of notification handler classes 224. Classes 224 of notification handlers are defined in accordance with the base class 225 of notification handlers. The base class 225 of notification handlers is an abstract class that defines an interface for classes 224 of notification handlers. The base class 225 of notification handlers offers a definition of an interface of two virtual methods (see FIG. 6), the implementation of which is provided for in classes 224 of notification handlers according to the corresponding classes of 214 presenters. Classes 224 of notification handlers help to perform a step-by-step update of the layout, and only presenter objects that have undergone changes in the set of corresponding graphic elements are recalculated. In one embodiment of the invention, a notification handler is defined for combinations of a graphic element and a visible image. In cases where multiple presenters are created for one graphic element / visible image combination, the only notification handler acts as the only source for tracking changes in the element in order to update the set of presenters for this element in the visible image. Each type of presenter defines a specific type of notification handler. When a presenter object for an element is created, which requires a notification handler, the presenter system creates an appropriate notification handler of a given type and associates the notification handler with the presenter object.

Instances of classes 224 of the notification handlers determine which parts of the objects of the presenters are “contaminated” and therefore require updating. First, a notification relationship is established between the graphic and the notification handler created for the presenter in the visible image (for example, in the visible image 202 for the application 204). The notification processor receives notification of changes associated with the graphic element in the auxiliary storage device 208, through a presentation engine 212 in the presenter system 200. The notification handler determines the part, if any, of the presenter that was affected by the change in the element. The notification processor returns information about the part that has undergone a change to the system of 200 presenters. The presenter is marked as “contaminated” by the submission engine 212. The presenter system 200 collects information about “contaminated” presenters for all presenters in the data structure supported for the visible image (eg, visible image 202). Then, in response to a call to recalculate the layout for the visible image, the presentation engine 212 in the presenter system 200 activates the update method / operation only on “dirty” presenters. Thus, classes 224 of notification handlers allow you to restrict layout updates to presenter objects that have undergone changes that were created based on classes of 214 presenters.

The architecture of the layout control system in which the present invention is embodied operates independently of any particular output hardware on which the laid out (displayed) elements are ultimately displayed in accordance with their defined visible images. The layout / presentation management system architecture shown in FIG. 2, performs a preprocessing step with respect to the graphic display output. In one embodiment of the invention, the ordered output associated with the architecture of the layout / presentation control system is device specific. Subsequently, at the visualization stage, the objects of the presenters visualize the recalculated visible image on the components of the graphic output of the computing system. However, in other embodiments of the invention, the output of the layout / presentation system is returned to the calling application using either the presenter objects 214 or the presenter system 200, and the application 204 performs the visualization task. In one embodiment of the invention, visualization commands, if issued by objects by presenters obtained from presenter classes 214, visible image 202 or application 204, are sent to the graphics subsystem and to the drivers 234 of the graphic devices on the user's computer. The graphics subsystem and graphics device drivers 234 provide visualization commands and data to a particular selected output device, such as a monitor 236 or a printer 238.

Summarizing the above about the layout / presentation management system architecture described above, it can be argued that the presenter system 200 provides a device-independent layout processing platform for applications such as application 204. Layout processing is performed by presenter objects created from classset 214 presenters led by a system of 200 presenters. The system 200 of presenters belongs to the visible image 200. The objects of the presenters correspond to specific states of the visible image / visualizations for graphic elements 206. The separation of the states of the visible image (objects of presenters) from the states of elements (graphic elements 206) allows independent designation of the set of states of the visible image / presenters for one item state. The layout is divided into visible images, such as a visible image 202, where each visible image corresponds to a display area, such as a specific rectangle on the output screen allocated to the application 204, or a document page in the output of a graphic printer. The selection of data and states of the visible image allows one element to generate many visible images of this graphic element and, therefore, allows you to display one graphic element in many views / in many ways.

Another aspect of the layout control system architecture disclosed herein is its high degree of extensibility. The extension of the set of classes of 214 presenters is facilitated by the base class of 216 presenters provided by the system of 200 presenters and the leading presenters API of the presentation engine 212.

The layout architecture described above supports many different advanced layout processing options for applications that visualize graphical output on graphical user interfaces and printers. The ability to separate one element (graphic element) into many states of the visible image (presenters, presentation modules) facilitates paging and separation of elements into many columns (pagination) in applications when visualizing the output of the printer or the output of the visible image of the document on the display screen . Such applications include Web browsers and word processing programs.

Another advantage of using multiple presenters is the ability of applications to make many attempts to place their content in a given display space. Applications can implement many specific attempts at different objects of presenters for one element using different input parameters, and then provide the user with the opportunity to choose the best of the displayed images of the graphic element (s).

Another advantage arising from the use of the above-described layout control architecture is the ability to perform step-by-step changes to a visible image containing a set of presenters for a set of corresponding elements. The change is implemented on a bit-by-bit basis in the auxiliary storage device (see, for example, auxiliary storage device 308 in FIG. 3). Notification handlers and the presenter system 200 provide the infrastructure for restricting updates to the corresponding visible image by presenters that have been modified in the corresponding elements in the auxiliary storage device.

The next advantage of the layout control architecture as an example is the ability to “decorate” (decorate) the states of the visible image of elements embodied in previously created presenters. This is accomplished by linking additional presenters with a presenter of the type that was specified for a particular type of element. Linking allows developers to expand the capabilities of user interfaces and output documents by adding borders, backgrounds, and so on to the state of the visible image specified by the particular type of presenter for the element.

Considering the above description of the general architecture of the layout management system in which the present invention is embodied, refer to FIG. 3, which shows the relationships between visible images, presentation mechanisms, presenter objects in visible images, graphic elements, and notification handlers for a specific, exemplary, visible image.

The conceptually visible image defines a specific way of arranging a set of graphic elements represented in the auxiliary storage device 208 according to the specified (specified) presenters. In one embodiment of the invention, the visible image is bounded by a rectangle in the output field (for example, a display screen). In addition to the rectangle and its coordinates, the visible image also defines the graphic elements and associated presenters contained in the visible image. In addition, note that in one embodiment of the invention, each visible image is associated with its own instance of the presenter system (for example, the presenter system 200a for the visible image 202a and the presenter system 200b for the visible image 202b).

As shown in FIG. 3, the page memory 308 comprises an organized set of graphic elements (Ex) associated with visible images 202a and 202b. Graphic elements (Ex) are objects of content organized by the user. Examples of elements include a button or text panel of a graphical user interface (GUI), a text editor window, a bitmap display, etc. In one embodiment of the invention, the graphic elements (Ex) in the auxiliary storage device 208 are arranged in a tree form. Each element (Ex) in the set of graphic elements 206 supported in the auxiliary storage device 208 is associated with a set of properties / placeholders (which can be defined explicitly or implicitly specified through other explicit properties / placeholders). One or more of these properties / placeholders on graphic elements specify the type of presenter that is used to layout and visualize the content of the graphic element in combination with other components of a computer system. In embodiments of the invention, concatenated presenters are defined explicitly or, in alternative embodiments, are implicitly defined through other properties defined on the element (for example, the “border” property of two pixels implies the presence of a presenter attached to the border). The types of properties defined for graphic elements depend on the particular graphic element and include color, font, name, height, width, etc.

Auxiliary memory 200 is potentially associated with a plurality of visible images (e.g., visible images 202a and 202b). Each of the potential plurality of visible images has an exclusive set of instances of presenter objects corresponding to the set of graphic elements in auxiliary storage device 208. Thus, when a graphic element is represented by a plurality of visible images, a presenter object is created for the element in each visible image (for example, a presenter P2 and presenter P2 'for element E2). The graphic element with which the presenter is associated is set in the field of the element owner and corresponds to the dashed lines going from the presenters to the corresponding graphic elements. This is just one example of the presentation architecture shown in figures 2 and 3, where many presenters are supported, acting on the basis of information provided by a single graphic element.

As a consequence of the features of the presentation architecture, embodying the above ability to attach multiple visible images (and presenters) to the same set of graphic elements in auxiliary storage device 208, the graphical user interface is capable of displaying many visible images of the same information set provided by graphic elements. For example, in an application such as MICROSOFT's POWERPOINT, two visible slide images are supported simultaneously, the main visible image and a preview image (or “sketch”) for the same slide graphic element.

The ability to create multiple instances of presenter objects for one graphic element also facilitates splitting one graphic element into multiple pages / columns (for example, document text) (that is, if one graphic element is divided into two pages, then two presenter objects for the element are created - by one for each page). Refer to figure 3, where the object of the parent presenter (for example, P5) receives the transferred property from a graphic element (for example, E5) indicating that the content in the element (for example, text element E8) can be represented by two columns. Under the P5 presenter, two objects P8a and P8b of the child presenters are created, corresponding to two separate rectangles for the column / page in the document, to display the text represented by the graphic element E8.

Another case of creating many presenters for one graphic element occurs when “decoration” elements (for example, borders, backgrounds, frames, etc.) are highlighted for a graphic element. The concatenated presenter Q4 for element E4, which provides a border around the rectangle defined by presenter P4 to save the text provided by the data field in element E4, is an example of a concatenated presenter. The presenter Q4 and the presenter P4 are connected / connected to the graphic element E4 by setting the graphic element E4 in their fields for the owner of the element. In one embodiment of the invention, the parent presenter, based on an analysis of an element corresponding to one of its child elements, detects that a concatenated presenter is needed (for example, a border of two pixels is defined on the element). If there is an interlocked presenter Q4 when the presenter P1 calls the method to create a child (intermediary) presenter for the child element E4, presenter P1, based on the properties of E4, determines that a concatenated presenter (Q4) is needed. First, a child proxy / presenter Q4 is created, and is identified as a child presenter of the presenter P1. The Q4 presenter, in turn, creates a P4 child intermediary / presenter. Thus, P4 is a child presenter for the Q4 presenter. Information is stored in a child intermediary for the linked presenter Q4, identifying the next presenter (P4) in the chain.

Further, after specific examples have been described, where a plurality of presenters associated with the same graphic element are used, and where a plurality of visible images (and presenter systems) are created for a set of graphic elements in the auxiliary storage device 208, are described the relationship between the displayed objects in figure 3. As mentioned above, the visible images 202a and 202b have their own presenter systems 200a and 200b, respectively. The presenter system 200a has created and maintains a set of presenters 302 for the visible image 202a through code and a base class, including the API, into which presenter classes are written. The presenter system 200b has created and maintains a set of presenters 303 for the visible image 202b.

As shown by the lines between the presenters (Px) and the graphic elements (Ex) in the auxiliary storage device 208, the presenters (Px) are associated with the corresponding graphic elements (Ex). Presenters (Px) represent the state of visible images for the corresponding graphic elements (Ex). Graphic elements (Ex) in the auxiliary storage device 304 are supported, for example, in a tree structure constructed by the application using one of many possible ways. Examples of such methods include running a file with text markup through a parser, using code (program) to create graphic elements, etc. The tree structure of the set of presenters 302 is constructed by the presenter system 200a in response to a call to a specific method on an interface (e.g., DoLayout) provided by its presentation engine. As described previously with reference to figure 2, the nodes of the tree of objects of presenters are determined by the nodes of the tree of graphic elements associated with a particular visible image. Graphic elements in the visible image are determined by the root graphic element specified for the given visible image, its child elements, "grandchild" elements, and so on.

The set of presenters in the visible image 1 has a hierarchical structure. The root presenter P1 has two daughter presenters, P2 and P4 (Q4 is the presenter of the “trim” elements on the presenter P4). Presenter P2 has no subsidiary presenters. However, the presenter P4 has two subsidiary presenters P5 and P7. Presenter P5, in turn, has subsidiary presenters P8a and P8b, which are associated with one graphic element E8. Such sharing / separation of one graphic presenter between two objects of presenters occurs, for example, when the text graphic element E8 is divided between two columns of the parent text graphic element E5, which has a presenter (P5) of type TextPresenter (text presenter). Presenter P5 initiates the process of dividing into columns when he notices the properties on E5, requesting the separation of the content (E8) of the E5 element into two columns. Presenters P8a and P8b correspond to the graphic existence of parts of the graphic element E8 in two columns.

As noted earlier, a single graphic element can have many presenter objects associated with it. Three cases were cited as an example. In the first scenario, shown with the plurality of visible images 202a and 202b and the respective presenter systems 200a and 200b of FIG. 3, one graphic element (eg, E2) has corresponding presenters P2 and P2 'associated with the visible images 202a and 202b, respectively. Such visible images correspond, for example, to an outline image and a full-size representation of a photographic image (E2) displayed in different areas of the user interface that is generated by the application for processing photographic images. In this case, the presenters P2 and P2 'are created for the element E2 in each visible image 202a and 202b containing this element. In the second scenario, which includes many presenters for one element (for example, text element E8), the presenter elements P8a and P8b correspond to two columns in the rectangle defined by one presenter element P5. Alternatively, these cases of using multiple presenters in the visible image with links to the same graphic element occur, for example, when the parent element makes many attempts to compose the visible image and saves these attempts. In the third scenario, a presenter (for example, Q4), which depends on another presenter (for example, P4), with the opposite state of the data of the graphic element (for example, E4), is connected by a clutch to another presenter, which expands the display capabilities provided by the original presenter. An example of a clutch of presenters is a border presenter, which provides the “decoration" of the border for the main presenter.

Previously, with reference to FIG. 2, it was noted that child intermediaries created from the class of 222 child intermediaries are a “wrapper” for each child presenter object of the parent presenter object. In a graphical representation of the tree structure of the presenters for the visible image 202a, the child intermediary objects are represented by arrows on the lines connecting the parent presenter with its child objects presenters. Subsidiary intermediary objects restrict access from the presenter’s parent to its child presenters.

Notification processors (Nx) are responsible for notifying the respective presenters (Px) of data state changes in their graphic elements (Ex). Nx notification handlers do not significantly affect the performance of the presentation / layout management system. They only facilitate step-by-step updates of presenters, performing them only when an element changes in the visible image.

Figures 4a and 4b show that the base class of presenters includes a set of methods, properties, and fields. In one embodiment of the invention, the properties are available on the particular presenter object that is being accessed by initiating receive / install operations on the object. The background property 400 sets the coloring value for the presenter background. The background opacity property 402 stores a value specifying the background opacity. Border property 404 stores a value that specifies the thickness of the border that defines the layout space of the presenter at the edges. The border property 404 stores, for example, four values indicating the border width for the top, bottom, right, and left sides of the rectangle selected by the presenter. The border color property 406 defines a value indicating a border color around the presenter. The border style property 408 stores a value indicating one of a set of border display styles. An example of border styles includes: solid, in-depth, ribbed, nested, and elevated.

The bounding box property 410 defines a zone (eg, a rectangle) in which the graphic elements of the presenter (or child elements) are displayed. The default size of the bounding box property 410 is the same as the size specified in the layout size field 460. However, the size of the bounding box may exceed the size of the layout, which allows the presenter to create an image outside the size of the layout.

On the other hand, if truncation property 414 is set to true, then the presenter (and its child presenters) cannot be displayed outside the rectangle specified by the layout size field 460. If the value of truncation property 414 is set to true, then the bounding box property 410 does not exceed the layout size. This ensures that the depicted presenter does not reproduce graphic elements outside the layout space allocated to it.

The property 412 of the child elements is an array or, alternatively, any other suitable multi-element data structure where references (for example, labels, pointers, direct / indirect, etc.) to the child presenters embedded in the parent presenter are stored, and their Transformed locations in the layout space of the parent presenter. The property 412 of the child elements is on the presenter when it is first used in the context of calling the OnUpdate (update) method, which is described below. The term "for first use" refers to the case when the parent presenter sequentially requests a set of children, and the set of children is located along with presenters corresponding to the child graphic elements of the graphic element that corresponds to the parent presenter from the tree of graphic elements in the auxiliary storage device ( for example, in auxiliary storage 208). The property 412 of child elements facilitates the establishment / maintenance of a hierarchy reflecting nested relationships with presenters in the visible image. In one embodiment of the invention, array entries have references to child intermediary objects. Child intermediary objects are wrapper objects for child presenter objects that are nested in the display space allocated to the presenter's parent object. The “shell” of the child intermediary object meets the encapsulation and security requirements (for example, the child presenter restricts access to the content from the parent presenter).

The truncation property 414, as described above, determines whether the presenter content will be limited by truncating to the presenter layout size specified by the presenter size field 460.

A set of properties denotes the space allocated to content in the presenter space. In addition to the border property 404, the padding property 416 sets the amount of space within the border that remains unallocated content. The content height property 418 sets a value indicating the height of the content in the presenter — the height of the part of the presenter that remains after taking into account the values specified in the border property 404 and the padding property 416. The content width property 420 sets a value indicating the width allocated to the content in the presenter, taking into account the parameters of the border property 404 and the padding property 416. The combination of the content height property 418 and the content width property 420 defines a presenter zone that content in the presenter potentially occupies.

The height property 422 and the width property 424 specify the actual height and width of the presenter, and these two values include content, fill, and border parameters. The default height property 422 and the default width property 424 specify default values assigned to the presenter when the height property 422 and the width property 424 are not provided for a particular presenter object. The maximum width property 430 and the minimum width property 432 set boundaries for the value assigned to the width property 424.

Another dimensional property for presenters is the property of 434 fields (pages). Property 434 fields sets the buffer space outside the border of the presenter. The 434 field property is set by the child presenter and is available to its parent presenter when ordering the layout with a hierarchical structure from nested presenters.

Property 436 visibility sets the visibility state of the presenter. The visibility property 436 is related to the determination of how the graphic image corresponding to the presenter and its child presenters is visualized (or to the determination of whether this graphic image is in principle visualized). In one embodiment of the invention, potential visibility states include: visible, compressed, and hidden.

A number of presenter properties are used to associate presenters with other objects in the layout / presentation management system. Presenter property 438 specifies the type of presenter that is used to compose and render the graphic item. The presenter type is initially set on the graphic element, and the presenter system 200 reads the presenter property 438 from the graphic element and creates a presenter object corresponding to the presenter type identified by the presenter property 438. The presenter property 408 is passed to the create block, which in turn creates an instance of the presenter of the identified type. The 440 IsMainPresenter property determines whether the presenter is the only presenter or the main (for example, the last) in the set of concatenated presenters associated with the graphic object. Refer to figure 3, where the presenter P4 is the main presenter for the chain, including B4 and P4. In one embodiment of the invention, the IsMainPresenter property 440 is a property of the Boolean (logical) type.

Element owner property 442 identifies the graphic element for which the presenter has been defined (created). Referring again to FIG. 3, where the dashed lines connecting the presenters (Px) with the corresponding graphic elements (Ex) represent links indicated by the content of the property 442 of the element owner. The layout context property 444 sets a global context that facilitates messaging between presenters during the layout process. The values stored in property 444 of the layout context allow presenters to send messages regardless of the system of 200 presenters. The notification handler property 446 sets a reference to the notification handler for this presenter. The notification handler type property 448 specifies the type of the notification handler referenced by the notification handler property 446.

The “pollution” property 450 determines whether a particular presenter has been changed and, therefore, whether an update operation is required. The presenter system 200 and related components of the layout management architecture support step-by-step layout processing. The “pollution” property 450, supported by each presenter, indicates separately for each presenter whether updating is required.

In FIG. 4a, as an example, the final set of fields of the base class of presenters is presented. In one embodiment of the invention, these fields are fields of the Common Language Runtime (CLR) (similar to the well-known belonging variables in C ++ classes). In one embodiment of the invention, the above properties are similar to fields. However, properties on graphic elements (e.g., graphic elements 206) are owned and controlled by auxiliary storage device (e.g., auxiliary storage device 208). When a property changes, this auxiliary storage device notifies the presentation engine of the change. A presentation engine (e.g., a presentation engine 212 for the presenter system 200), in turn, notifies the respective notification handlers 224. Thus, in the case of the property, the change notification is received through one of the above notification handlers. On the other hand, the auxiliary storage device 208 does not control the fields (instead, the fields are controlled, for example, by CLR). Therefore, when a field is changed, no notification of changes is sent to the presentation engine.

The layout size field 460 maintains the dimensions of the layout space allocated to the presenter. The layout size field 460 is used to arrange adjacent presenters in the page / user interface layout. The layout impact field 462 is a set of properties (for example, border, padding, etc.) of the presenter that, when changed, affect the layout of the presenter. The layout impact field 464 for the parent presenter represents the set of properties (for example, fields, visibility, etc.) of the presenter, which, when the element (for example, element A) changes, “pollutes” (that is, potentially affects) the layout of the first parent presenter for an element (element A) having a given presenter. The effect visualization field 466 is a notification mechanism that initiates cancellation and re-rendering of the presenter.

We now turn to the methods of the base class of 206 presenters listed in FIG. 4b, where the OnUpdate method 470 measures and positions tasks on a presenter for one item. The authors of presenters rewrite the base class version of the OnUpdate method 470 to create / provide a mode for setting dimensions / positioning of the layout according to the user's requirements for the corresponding visible image of the element.

The first default action when using the 470 OnUpdate method is to set the presenter sizes. Method 470 OnUpdate gets the dimensions of the presenter in the received BoxSizeInfo parameter (information about the size of the rectangle). The OnUpdate method 470 sets the sizes specified in the layout size field 460 according to the BoxSizeInfo settings, the default width property 428, and the default height property 426. Additional sources of size / positioning information for the presenter are an integral part of the disclosed presenter-based layout / presentation processing architecture, these sources being used in alternative embodiments of the invention.

The second default task when using the 470 OnUpdate method is to position the child presenters in the local size space of the presenter. The base class version of the 470 OnUpdate method iteratively calls the 470 OnUpdate method for child presenters identified in the 412 property of the child presenters to reveal their sizes and child presenters. After establishing and measuring the child presenters, these presenters are positioned in the parent presenter by calling the transformation method (discussed below) for the individual child presenters. Iterative calls to the OnUpdate method 470 for child presenters end when no additional child presenters are specified in the presenter. In addition to registering the size in the layout size field 460 and iteratively calling / positioning the child presenters, the OnUpdate method 470 returns a value to the caller indicating whether rendering is required, taking into account the call to the 470 OnUpdate method.

The atomic registration method 471 registers the presenter string name for layout context 444, as well as any other suitable presenter lists, including those supported by presenter extensions. Method 471 for registering “atoms” is called, for example, to establish a connection with another presentation object in a non-standard way (for example, by a method that is not currently supported by the presenters application programming interface). Presenters register an “atom,” and then set up the object with which they want to communicate using this “atom." For example, a child presenter wants to pass the source of the text to the parent presenter. The child presenter registers the “atom” with the “Descent” label / tag (origin) and accepts the identification data for that “atom”. The child presenter calculates the “source” and sets the value in the atom using the credentials. The parent presenter then uses the credentials (which are also obtained by registering Descent) to retrieve the stored information.

Method 472 OnUpdateBoundingBox (updating the bounding box) creates property 410 of the updated bounding box for the presenter. The OnUpdateBoundingBox method 472 is called when the OnUpdate method 470 returns a value (for example, true, indicating that re-rendering is necessary). The default implementation of the 472 OnUpdateBoundingBox method provided in the base class of presenters scans the child presenters identified in the property 412 of the child presenters for this presenter and combines (that is, performs mathematical union of the rectangles) the transformed properties of the child bounding rectangle with the presenter sizes stored in field 460 layout size. The base class implementation for the OnUpdateBoundingBox method 472 also accesses the truncation property 414, and if its value is true, then the bounding boxes of the child presenters are ignored. Instead, child presenters will be truncated to the sizes specified in the layout size field 460 for their parent presenter. Presenters whose image extends beyond the layout size field 460 cause a rewrite of the method. These presenter classes, customized to the user's requirements, invoke the base presenter class and add an extra “colorful zone” to their rewriting program. In one embodiment of the invention, the presenters are given the opportunity to evaluate the "colorful zone" for whether it is larger than what is actually required. If the bounding rectangle property zone 410 is smaller than the region necessary to draw the presenter, then the pattern is truncated based on the bounding box property 410 dimensions specified for the presenter.

Method 474 OnRender is called for presenters who request / require re-rendering. Method 474 OnRender is the primary call for the presenter to re-render the presenter and any of its child presenters. The OnRender method 474 is preferably called after the OnUpdate method 470 is called on all “dirty” presenters in the layout (for example, a scene). In one embodiment of the invention, the OnRender method 474 is called from the presentation objects based on an analysis of whether the OnUpdate method call 470 provided the object / presenter with a return indication that the presenter is requesting a re-rendering. In one embodiment of the invention, the base class OnRender method 474 performs presentation / layout ordering operations for the presenter, regardless of the particular device. Other components, including the graphics subsystem and drivers of 234 graphic devices, render the visible image of the presenter in a format associated with a specific device. Derived variants of the OnRender method 474, taking into account user requirements, include calls to the components of the computer system that form the graphic elements to visualize the output of the document / user interface.

In one embodiment of the invention, the base class version for the OnRender method 474 renders presenter content, including any children, in three stages of layout processing. At the OnRenderBeforeChildren stage (visualization to child presenters), the presenter object invokes operations to be processed before any of its child presenters is processed. In one embodiment of the invention, the base class implementation for the OnRender method 474 provides a connection (trap) for configuration and does not specify any preprocessing operations at the OnRenderBeforeChildren stage. However, an example of a customizable default replacement for this mode, taking into account the specific requirements of the user, sets / displays the user background for the display zone of the presenter.

The base class version of the OnRender method 474, at the stage of visualization of child presenters, refers to the child presenters identified in the property of 412 child presenters. The OnRender method 474 is called, in turn, for each of the child presenters (to extend the requested child presenter when the OnUpdate method 470 is implemented). Thus, a high-level call to method 474 OnRender is distributed sequentially to child presenters and their descendants until the bottom of the tree is reached (that is, a presenter that does not have child presenters). After the high-level call completes, all child presenters in the tree that requested re-rendering will be rendered again.

At the OnRenderAfterChildren stage (visualization after child presenters), the object's presenter invokes operations that must be performed after calling the 474 OnRender method for child presenters identified in the property 412 of child presenters. The base class version of the 474 method OnRender provides a trap (connection) for customization in accordance with the requirements of a specific user and does not specify any post-processing operations at the OnRenderAfterChildren stage. However, examples of this setting include annotations, trim elements, etc.

If the presenter does not re-render any objects other than child presenters, then there is no need to rewrite the base class version of the 474 OnRender method. However, if the presenter himself needs to draw something, then the base class for the 474 OnRender method is rewritten to visualize the graphic data in the space allocated to this presenter. The replacement program includes, for example, calls to applications 230 and / or the graphics subsystem and graphics device drivers. The concatenated presenter is in the presenters tree for the particular visible image. If a linked presenter requires re-rendering, then the presenter system will call its OnRender method in the same way as the OnRender method for the main presenter.

In the context of this application, the term “coincidence check” refers to the process of identifying which presenter is at a particular point in the grid coordinate space of the graphical user interface. A match check is used, for example, to determine the location of the mouse pointer (for example, which presenter it is above) when the user clicks on one of the mouse buttons. Method 476 OnHitTestDetail (match checking details) returns data stored in the HitTestDetail structure for the presenter. A presenter class customized according to user requirements rewrites the base class implementation for the OnHitTestDetail method 476 to be placed in the HitTestDetail structure to enable the presenter to return data other than the matching element and presenter, thereby providing, for example, more detailed information related to the presenter, such as the part of the presenter that really hit the specified point (for example, the position of the character relative to the text).

Method 478 OnCreateViewResult (creating the resulting visible image) has parameters that describe the calculated state of the presenter in the resulting object of the visible image. Users request a result object — a visible image for an element in the context of the designated visible image. The base class version for method 478 OnHitTestDetail provides, through the resulting object-visible image, the height, width and position of the upper left corner of the presenter. If additional / alternative information is required regarding the state of the presenter, such as the number of lines of text contained in the presenter, then the base class version for the 478 OnHitTestDetail method is redefined to provide the required information through the resulting visual object.

Hit Test Method 480 initiates a hit test on a subtree whose root is the given presenter. Coordinates of the point (in the local coordinates of the presenter) where the hit test should be performed are passed to the hit verification method 480. The hit test method 480 returns hit test data containing the hit test results for the designated point and presenter. The result contains all the visuals at which the specified point falls. A visual is a basic object (for example, a line), on the basis of which the presenter creates a displayed image. A visual is a graphic object with the ability to actually draw an image at the output of a graphic display. When calling the presenter's OnRender method for the visual API, several calls are issued, for example, to render text, images, videos, etc.

Method 482 OnGetBypassList (getting a list of crawls) provides a list of child presenters calculated previously for the identified presenter. This list of child presenters makes it easier to bypass child presenters during layout calculations (for example, by comparing a new layout child presenter with previously calculated layout children presenters and reusing the previously calculated presenter if there is a match with one of the presenters on the list). If a presenter expands his child presenters by accessing the property set of 412 child presenters, he should not replace this method. However, if the presenter uses the 486 GetChildProxyForElement method described below (getting the child mediation presenter for the item), then the OnGetBypassList method 482 is usually overwritten.

When using the layout system embodying the present invention, if the GetChildProxyForElement method 486 is called before the OnUpdate method 470, the OnGetBypassList method 482 is called and the presenter object creates and populates the array list with child intermediaries (described below with reference to FIG. 5) that it cached from the previous layout calculation. If the presenter object does not have a cache for storing recalculated child intermediary objects, then all child presenters of the presenter object are recalculated for each call to the OnUpdate method 470 for the presenter.

Boundary calculation method 484 computes and returns the boundaries of a subgraph that has an identified visual as a root.

As explained above, the child intermediary object is a wrapper object that acts as an intermediary between the parent presenter and the child presenter for a particular graphic element. Child intermediary objects for child presenters of a particular presenter object are accessed as a set in the property 412 of child presenters for the presenter object. The GetChildProxyForElement method 486 is a method for the parent presenter object that creates the child proxy and presenter object for the specified element. The method returns null if the specified element does not have a presenter.

The OnBeforeBypass method 488 is called when the presenter system 200 wants to “bypass” a particular presenter (that is, skip calling the presenter's OnUpdate method 470). Such a bypass occurs, for example, when the presenter is not “dirty”, and the dimension parameters (BoxSizeInfo) (information about the rectangle sizes) of the presenter entered by calling the 470 OnUpdate method have not changed since the last call of the 470 OnUpdate method for this presenter. The OnBeforeBypass method 488 is a mechanism that improves performance by allowing presenters who have their own custom set of child proxies (who use the GetChildProxyForElement method 486) to reuse their child presenters child proxies when performing a layout update (for example, when only small part of the layout).

The OnDisconnectChildren method 490 removes all of the presenter children from the set of child presenters defined in property 412 of the child presenters for the specified presenter. If the default property 412 for child presenters is overridden for the presenter class derived from the base class 216 presenters, then the OnDisconnectChildren method 490 is also overridden to ensure that the right presenters are located.

The Min / Max passage is a special passage (viewing) for specifying the sizes used by presenters participating in this operation (for example, DockPresenter) when setting the sizes of child presenters for content. Knowing the minimum and maximum widths for child presenters allows the parent presenter to rationally distribute the space between the set of child presenters sharing a specific width value. Without the minimum / maximum value provided by the MinMaxPass function, the participating presenter would need many passes to rationally set the size for the content. Method 492 OnMinWidth (state of minimum width) is called after passing (viewing) Min / Max. Method 492 OnMinWidth calls the MinWidth value, which is a by-product of the calculation of MaxWidth. The base class version for the OnMinWidth method 492 displays the message “I don't care”, which initiates a calculation run with ProposedSize (suggested size) = (0, infinity) and both directions “NotFixed” (not fixed).

Presenter method 494 is the design method for the presenter instance. Presenter method 494 has no parameters. The presenter method 494 is initiated when the presenter system 200 instantiates the given presenter. The presenter method 494 sets up the presenter instance, allowing other methods (such as OnUpdate) to be initiated on the presenter.

The QueueLayoutTask method 496 (arranging a layout task queue) adds a specific layout task to be performed on a given presenter object to the layout task queue executed by the 200 presenter system. When this specified layout task is at the beginning of the queue, the presenter system 200 calls the OnLayoutTask method 604 (launching the build task), which is described below, in the notification handler for this presenter.

The OnQueryValue method 498 (query value state) returns the value corresponding to the specified computed value for the presenter.

Based on the description of the base class 216 of presenters, we turn to FIG. 5, which provides a summary of the properties and methods of an exemplary embodiment of a child mediation class 222. As explained previously, in one embodiment of the invention, child mediators are wrappers for presenter objects that are children of the presenter’s parent object, and these child mediators support limited access from the parent to the resources of the presenters' child objects. All data transfers (requests / responses) between the parent of the presenter and the child of the presenter are sent through a child intermediary for this child presenter. The child intermediary maintains a reference to the child presenter and routes calls / requests from the parent presenter to the child presenter.

In one embodiment of the presenter system 200, the child proxy class 222 includes an item owner property 500 that indicates the item in graphic elements 206 that the presenter of the child proxy with which the link is associated with is associated.

The transform property 502 positions the child object of the presenter (and its associated visuals) inside its parent object of the presenter. The transformation is implemented through a standard 3x3 graphic transformation matrix in the base class of visual objects. When the transformation matrix is set, the visual object associated with the graphic element of the presenter places its child presenter with the offset specified by the transformation matrix.

The bounding box property 504 sets the rendering boundaries of the child presenter. Thus, the visualization boundaries of the child presenter may differ from the layout size for the child presenter.

The “pollution” property 506 sets the “pollution” state of the presenter of the subsidiary intermediary. In one version of the system of 200 presenters, the state of “pollution” is one of: clean, “witness of pollution” (dirty bystander) or “polluted”. A “clean” state indicates that there have been no changes to the child presenter in the child presenter since the last update of the visible image. A “dirty” state indicates that a change in the child presenter has occurred since the last update of the visible image. The state “witness of pollution” indicates that at least one of the descendants of the daughter presenter is “polluted”, but the daughter presenter is not polluted. These states allow parent presenters to optimize update operations.

The QueryDefaultSizeInfo method 510 (querying for size information by default) initializes the sizes of the child presenter based on the default values provided by the parent presenter of the child presenter.

The 520 Update method requests the child broker to initiate the OnUpdate method 470 on the child presenter. The parent presenter invokes the 520 Update method on the child broker when the parent presenter performs a search to calculate the layout of the child presenter. Calling the 520 Update method includes two forwarded parameters. The information about the size of the rectangle sets the dimensions of the rectangle in which the layout should be calculated by the child presenter, and if pagination is activated, the parent presenter passes the page information in the page descriptor parameter (see Fig. 10, which is described below). Thus, the 520 Update method provides a layer between the caller and the child presenter that allows you to screen / filter these requests to the child presenter. The 520 Update method provides a mechanism to bypass calls typically routed to the OnUpdate method on a child presenter. For example, a call to the 520 Update method is initiated in cases where the child presenter has not been changed and the input parameters (information about the size of the rectangle and page description) have not been changed.

The join method 530 issued by the parent presenter to the child broker invokes the OnRender command for the child presenter associated with the child broker.

The request value method 540 provides a presenter value corresponding to the computed type (property) of the value identified in the method call. A call to method 540 of the query value is delegated to the corresponding method 498 OnQueryValue on the child of the presenter.

Layout size query method 550 provides calculated layout dimensions. A call to the layout size request method 550 is delegated to the corresponding OnQueryValue method 496 on the presenter's child. The MinMax calculation method 560 provides the minimum and maximum widths of the child presenter.

Turning to FIG. 6, where the set of base classes associated with the system of 200 presenters includes a base class of notification handlers. As explained above, notification handler objects receive all notifications regarding changes potentially affecting the presenter associated with a particular visible image (view), accumulate information about “contamination” and make it easier to determine whether updating of the corresponding presenter object is required. Both methods from the base class of notification handlers accept as an argument an object that includes a method that provides the necessary information from an element among the graphic elements (for example, graphic elements 206) with which the notification handler is associated.

The base class of notification handlers includes the OnNotify method 600 (notification), which provides notification of the "contamination" of a particular presenter object associated with it. The OnNotify method 600 potentially includes additional derivative notification tasks formulated according to the user's requirements (by substituting the default action, which is to provide the value of the “pollution” property), which are performed in response to receiving the notification. The OnNotify method 600, as an input parameter, receives information about the change, as a result of which a notification was sent. The OnNotify method returns a Boolean value indicating whether the notification handler can handle the change itself (or indicating whether the notification handler for the ancestor presenter in the presenters tree must be notified for the visible image). The method also returns the value of “contamination”, indicating whether the presenter is “clean”, “contaminated” or refers to a condition called “evidence of contamination”.

The OnLayoutTask method (run the build task) 602 executes the tasks previously queued by the corresponding presenter using QueueLayoutTask.

Turning to FIG. 7, where the set of base classes associated with the presenter system 200 further includes a notification handler node class. The notification processor node class is a node object that is passed to the notification processor object, which allows the notification processor to call the notification services supported by the system of 200 presenters.

The notification handler node class includes an item owner property 700 defining a graphic item to which the notification handler node object is associated.

The atom registration method 702 registers the provided string name in the layout context 444 for the notification handler. The functionality of the “atom” registration method 702 is similar to the “atom” registration method 471 described above with reference to the base class of presenters. Thus, the “atom” registration method 702 is a means for transmitting requests from the notification handler to other objects (eg, presenter objects).

The notification creation method 704 creates a new presenter notification object and uses these fields based on the passed parameters. The transmitted parameters include identification information about the type of "atom" (indicating the type of the object-notification of the presenter) and notification data.

The “descendants” notification method 706 calls the OnNotify method 600 for notification handlers associated with the presenter descendants to which the notification handler node is bound to forward the specified presenter notification. The descendant notification method 706 performs the function of notifying descendant presenters of any changes in the parent presenter (eg, re-sizing). Similarly, the ancestor notification method 708 calls the OnNotify method 600 for notification handlers associated with the presenter ancestors to which the notification handler node is bound to forward the specified notification to the presenter. “Ancestors” are determined by traversing the tree of graphic elements (see FIG. 3) in the auxiliary storage device 208. The graphic elements presented in the auxiliary storage device include a property that defines the “parent” (intermediate ancestor) of the graphic element. The “notify everyone” method 710 calls the OnNotify method 600 in the notification handler objects for all presenters in the presenters tree belonging to the visible image to forward the specified notification. Finally, the “self-notification” method 712 provides a means for the presenter to invoke the OnNotify method 600 in order to mark its own “contamination”.

Turning to FIG. 8, where an example shows a class of objects of visible images from which a visible image 202 is created. Objects of a visible image have an instance of a system of presenters (for example, a system of 200 presenters) and are the visual “root” of all the visuals created in the created instance of the system of presenters. The visible image object initiates all calculations on the presenters in the visible image. Method 800 for the visible image is a constructor method that is used to create a new visible image object. The visible image takes as a passed parameter a link to the element, which is the root graphic element of the visible image. The 802 RootElement property (root element) returns a reference to the root graphic element for the visible image (which was set using the above method 800 for the visible image).

DoLayout method 804 creates a new presenter tree for the visible image and returns a link to the new tree. The DoLayout method 804 accepts the proposed height and width for the rectangle of the visible image as input, as well as two Boolean values (fixed width and fixed height) that determine whether the proposed sizes can change during the execution of the 804 DoLayout method.

The ViewSize property 806 (size of the visible image) sets the dimensions of the visible image. The ViewSize property 806 (for recording only) is used when the visible image object is located (hosted) in the window, and the ViewSize property 806 represents the initial size from which the layout operation is performed.

The GetViewResult method 808 (receiving the resulting visible image) accepts a reference to the graphic element as input, and then the GetViewResult method 808 returns the resulting visible image for the graphic element. The value "null" is returned when this graphic element is not in the set of graphic elements for the visible image.

HitTest method 810 (hit check) performs a hit test for the transmitted point in the coordinate system of the visible image. The HitTest method 810 returns the first opaque object obtained from the hit test. If the graphic element is not found, then the method returns false.

The CreatePage method 812 accepts BoxSizeInfo (see FIG. 9, described below) and PageDescriptor (see FIG. 10, described below) as input parameters. CreatePage method 812 creates a new page based on the entered parameters and returns a child intermediary object corresponding to the root graphic element for this page.

Turning to FIG. 9, where, as an example, the structure of BoxSizeInfo is shown. The BoxSizeInfo structure defines a set of sizes for presenters and their child presenters in the visible image, and also determines how these sizes should be processed by the receiving side. Property 900 of the proposed size sets the proposed size for the child presenter in the visible image. Initially, the property value 900 of the proposed size comes from the properties for the child graphic element in the auxiliary storage device. Before being sent to the child presenter, it can be modified by the parent presenter. Parental size property 902 is the suggested size for the parent presenter. Parental size property 902 is used, for example, to calculate sizes based on values in the form of percentages from the parent presenter for child presenters. The BoxSizeInfo structure also includes two properties with Boolean values, FixedWidth (fixed width) 904 and FixedHeight (fixed height) 906, which instruct the receiving presenter to indicate whether the presented size is a prescribed (fixed value) or is this size value simply offered in as height or width.

Turning to FIG. 10, which shows parts of an example page descriptor structure. The page descriptor includes the 1000 PageSize property (page size). The 1000 PageSize property is a read-only property that sets the page size. It is initialized when the page descriptor structure is created. The recording break property 1002 is a structure that includes: a starting position of a character identifying the first character of the current presenter that is on the next page (relative to the graphic element that is the root of the visible paginated image); the number of characters (counted back from the beginning of the character arrangement) that can invalidate the previous page; and the boolean value IsDirty (dirty), which indicates whether the dangling record (covering a specific range of characters in a paginated graphic element) was invalid as a result of a change in the auxiliary storage device.

The page descriptor structure also includes the 1004 AvailableSize property. A full page cannot be accessed by the presenter after the OnUpdate method begins to run on the presenter. The 1004 AvailableSize property indicates the space remaining on the page for the presenter. The 1004 AvailableSize property is initialized to the page size value.

Turning to FIG. 11, where a set of methods is defined that are performed by the presentation engine 212 of the presenter system 200 created by the visible image 202 (see FIG. 2). The constructor method 1100 in the presentation engine 212 accesses a visible image 202 that contains a link to the root graphic element for this visible image provided by the tree of graphic elements 206. DoLayout method 1102 accepts the width and height in the form of passed parameters representing the dimensions of the visible image 202, and in response, it proceeds with the layout process as applied to the content of the graphic elements 206. The UpdateLayout method 1104, performed at least once after execution Nia DoLayout, starting step change earlier calculated layout for the visible image 202. Method 1106 CreatePage receives as input information on the size of the rectangle (BoxSizeInfo), which contains the size of the displayed page and the page descriptor that contains information about how to start a specific page. Instead of displaying all the content under the root of the graphic elements 206 for the visible image 202, the CreatePage method 1106 displays only one page of interest.

An exemplary architecture for processing layout has been described with reference to FIG. 1-11. The architecture given as an example includes the selected states of the visible image (objects - presenters) associated with data states for elements (objects - graphic elements). The architecture shown includes a presenter system 200 that helps expand the layout / presentation capabilities of the visible image through the base presenter class 216, from which new classes of presenter objects that embody new layout / presentation functionality are derived. The system and architecture disclosed herein also includes a notification mechanism linking elements to respective presenter objects to selectively initiate re-calculation of portions of the visible image in response to changes. The illustrated base classes of objects illustrate many potential alternative implementations of an extensible architecture embodying the present invention, and should not be construed as limiting the scope of the invention.

Considering the set of components described here that form an exemplary presentation / layout processing architecture embodying the present invention, we now turn to FIG. 12, which shows the general process for processing changes in graphically displayed elements. First, at step 1200, changes occur in the auxiliary storage device 208. For example, the application 204 performs an operation that changes the state and / or content of one or more displayed graphical user interface components for this application. In response to these changes, at step 1202, the presentation engine 212 in the presenter system 200 receives a change notification resulting from a change in the graphic in the auxiliary storage device.

As a basis, at step 1204, the presenter system 200 maintains communications between the elements and presenters in the element-presenter (EPI) information link. Each time you create a presenter for a graphic element, a link to that presenter is created on the element, which is stored in the EPI supported by the presenter system. If a graphic element has more than one presenter, then the EPI of the graphic element will have many links (one for each presenter). When a property on a graphic element changes, the following steps are performed:

(a) The auxiliary storage device marks a change in the graphic element;

(b) The auxiliary storage device 208 notifies the change presentation engine 212 with reference to a graphic element that has changed one of its properties;

(c) The presentation engine 212 looks at the EPI of a graphic that has changed and determines the presenters that were created for that graphic; and

(d) After determining the presenter, the submission engine 212 receives a link to the corresponding notification handler for the presenter (via property 446 of the presenter's notification handler).

Thus, in light of the foregoing, at step 1204, the presentation engine 212 of the presenter system 200 determines the identity (identity) of the presenter for which the change notification is used. As explained above, the presenter system maintains a list of presenters that have been instantiated for a given element in its EPI. After determining the presenter for which the change notification is used (in this example, it is assumed that there is only one presenter for this element), the presentation engine 212 in the presenters system receives a reference to the notification handler for the presenter via the notification handler property 446 on the identified presenter.

Then, at step 1206, the presentation engine 212 of the presenter system 200 sends a change notification to the notification handler using the link that was obtained at step 1204. In one embodiment of the invention, step 1206 is performed by initiating the OnNotify method 602 on a particular notification handler.

After receiving the notification of the change from the presenter system at step 1208 (for example, during the OnNotify method 602), the notification processor determines the actions, if any, that the presenter needs to take to respond to these changes in the graphic during step 1200 in the auxiliary storage 208. In one embodiment of the invention, the notification handler determines for which part, if it exists, of the corresponding presenter, an update is necessary in the light of the received notification the change. Said parts include, for example, children of the presenter and the presenter itself.

Next, at step 1210, the notification handler (for example, OnNotify method 602) returns a result that allows the corresponding presenter to determine and perform actions in the light of the change notification received by the presenter system 200 during step 1202. In one embodiment of the invention, the returned result is presented as a handler notifications / specific presenter. In some cases, in the returned result, the presenter is simply marked as “polluted,” resulting in a complete recalculation of the corresponding presenter. In other cases, information is provided for selectively invoking only some of the options for recalculating the visible image for the presenter.

In one embodiment of the invention, the presentation engine 212 of the presenter system 200 receives, at 1210, a returned result from the presenter's notification handler. After that, at step 1212, if the changes in the auxiliary storage device do not necessitate a re-calculation of the presenter, the control proceeds to decision block 1216. However, if, at step 1212, the returned result indicates that the presenter needs to be recalculated, then control proceeds to step 1214, where the presenter system 200 adds the presenter to the set of "dirty" presenters requiring recalculation. In an exemplary embodiment of the invention, the presenter system sets the “contamination” property 450 on the corresponding presenter (indicating the need to recalculate the presenter) and adds this presenter to the set of presenters that need to be recalculated. Presenters also provide information describing the content of the changes that lead to the setting of the 450 “pollution” property. Then, control proceeds to block 1216.

At step 1216, if the parent presenter does not exist for the presenter associated with the notification handler of interest at the moment, then control passes to step 1218 “end”. If the parent presenter does exist, then control proceeds from step 1216 to step 1220, where a notification is generated (forwarded) to the notification handler of the parent presenter (which leads to the notification handler for the parent presenter processing the notification), as shown by the dashed line to return to step 1208.

Thus, the set of steps shown in FIG. 12, allows the presenter system 200 to accumulate a list of presenters that have been “contaminated” as a result of changes to the auxiliary storage device 220 since the last layout calculation for the document / user interface.

Turning now to FIG. 13, where the flowchart describes an exemplary process for re-computing / re-rendering a document / user interface in accordance with changes in presenters in a particular visible image (see FIG. 12, described above). In one embodiment of the invention, the application 204 controls updates to the visible image 202 and invokes update procedures for the visible image, such as the procedure disclosed in FIG. 13, in response to events such as the end of a time interval, a request to print a document, or change the state of a graphical user interface.

First, at block 1300, the presenter system 200 and the specific presentation engine 212 receives a call to the DoLayout method 1102 (described above with reference to the API description of the presentation engine 212). In response to receiving a call to the DoLayout method 1102 by the application 204, the presenter system 200 recalculates the presenter objects contained in the visible image 204 to post changes to items in the auxiliary storage device since the last call to the DoLayout method 1102.

In one embodiment of the present invention, where the presenters for the visible image are hierarchically ordered (see FIG. 3), the presenter system 200 first determines in step 1302 the root presenter for the visible image. In one embodiment of the invention, the root presenter is identified by the property of the presenter on the root element, which is assigned to the visible image (for example, the visible image 204a) and, therefore, to the system of presenters (for example, the presenter system 200a). After determining the root presenter, control proceeds to step 1304, where the presenter system 200 starts traversing the presenter tree for the visible image and recalculating each “contaminated” presenter.

At step 1304, the presenter system 200 calls the OnUpdate method 470 on each “contaminated” presenter in the visible image. The OnUpdate method called 470 passes the height and width of the rectangle in which the presenter layout must be re-computed. After recalculating the layout, the presenter caches the result. Thus, after completing step 1304, previously “contaminated” presenters are recalculated, and the results of the recalculations are cached for easy access during subsequent re-visualization. A “dirty” bit is cleared in each of the called presenters. Next, with reference to FIG. 14, the set of steps performed by invoking the OnUpdate method 470 is described in more detail.

There are several ways to clean the “contaminated” presenters at step 1304. However, in an embodiment of the present invention, the presenter system 200, and in particular, the OnUpdateLayout method 1104 of the presentation engine 212, uses hierarchical relationships between presenters in the visible image to simplify the execution of its function at completion step 1304. In particular, during the execution of the 470 OnUpdate method, each called presenter invokes iteratively (or, alternatively, requests a system of 200 presenters to call) the 470 OnUpdate method on all child presenters of the called presenter. Thus, the presenter system 200 starts traversing the presenter tree with the root presenter OnUpdate method 470 (for example, the presenter P1 of FIG. 3) and supports consecutive calls of child presenters when the OnUpdate method call 470 bypasses the branches of the presenter hierarchical tree to recalculate “contaminated” presenters . Iterative calls to the OnUpdate method 470 on child presenters ensure that all presenters in the visible image are bypassed, and if the presenters are dirty, they are recalculated.

At the end, each OnUpdate method 470 called in step 1304 sets the “dirty” property 450 to its initial state, indicating that a re-calculation or “cleanup” has been performed. Each OnUpdate method 470 also returns a value to the caller indicating whether the present presenter needs to be re-rendered (that is, re-drawn). In one embodiment of the invention, the return value is a Boolean value. If it is true, then re-visualization is required. If it is false, then re-visualization is not required. After processing at step 1304 each of the “contaminated” presenters for the visible image, control proceeds to visualization step 1306, where the presenters identified in the list of presenters requiring re-rendering are processed.

At 1306, the presenter system 200 calls the OnRender method 474 on each presenter identified in the list of presenters requesting re-rendering. The operation of an exemplary embodiment of the OnRender method 474 is described with reference to FIG. 14. When implementing the base class of the 474 OnRender method, the presenter does not “draw” anything, but instead iteratively calls the 474 OnRender method on its child and / or linked presenters to fill the allocated space (for example, a rectangle). Custom versions of the OnRender method 474, customized to user requirements, render bitmaps through calls to application 204 and / or graphics APIs and drivers 234 of graphic devices. After processing all the presenters requesting re-rendering in step 1306, control proceeds to step “end” 1308 and returns to the caller who initiated the DoLayout method call 1102 on the presentation engine for the particular visible image.

Turning to FIG. 14, which shows a flowchart of the OnUpdate method 470 performed to recalculate a presenter of a visible image. The OnUpdate method 470 calculates a new layout for the presenter, including any child presenters, and caches the results for accessing them during the re-rendering stage. In the example below, calling OnUpdate method 470 for each presenter sends a set of sizes that define the boundaries of the space for the visible image (for example, a rectangle), which can be occupied by the presenter layout. A set of sizes defines, for example, height and width, and it also sets whether these values can be modified during the execution of a call to 470 OnUpdate. However, the invention contemplates recalculating presenters based on any one or more of the many different parameters obtained, including the dimensions of the space for the visible image, which affect the layout.

At step 1400, the presenter performs the required size-setting operations based on the passed parameters before calling any of the child presenters (via child intermediary objects) to perform their updates. The content of this operation depends on the particular type of presenter. The presenter then calls a system of 200 presenters to locate and update the child presenters of the current presenter. At the preprocessing stage, the presenter determines the potential need to create a new page / column and creates a new child proxy / presenter to process the new page / column for the visible image.

Next, at 1402, the OnUpdate method 470 determines the next child presenter on the current parent presenter to invoke an update to its layout. Note that at this stage, at least in the first case, it is required that the parent presenter determines the presence of a child element and create the corresponding child intermediary object / presenter. In subsequent iterations, the parent presenter can use the cached child intermediaries identified in its 412 child presenters field to identify the next remaining (untreated) child intermediary / presenter, that is, the child presenter that has not yet been called during the current iteration of the OnUpdate method on the current parent presenter.

The parent presenter accepts the response from the supporting storage device or determines, based on his property, 412 child presenters, whether the child presenter to be processed remains; however, at step 1404, if there are no more child presenters to be updated, control proceeds to step 1420 (described below). Otherwise, if the presenter does have in its property 412 child presenters an unprocessed child presenter that has not yet been updated, then control proceeds to step 1406.

At step 1406, the presenter calls the OnUpdate method 520 on the returned child broker, which is between the parent presenter and the current child presenter in question, to obtain the height and width of the child presenter that the child broker is associated with. The child presenter is associated with a specific graphic element (defined in its field 442 owner of the element).

At step 1410, the child broker calls the OnUpdate method 470 on the child presenter that this child broker is associated with. The OnUpdate method 470 calculates the updated height and width of the child presenter (and determines if re-rendering is required). Note that at step 1410, the OnUpdate method 470 is called recursively by child presenters until the called child presenter determines at step 1402 that it has no child presenters and until it returns to the calling parent presenter (through its child intermediary). After calling OnUpdate method 470 on the child presenter, control proceeds to step 1414.

Thus, at block 1414, the calling parent presenter (from block 1406) receives a response to the OnUpdate method call 520 for the identified broker. The answer includes the height and width of the child presenter in the form of the returned parameters. The response also indicates whether re-rendering of the called child presenter is required. Next, at step 1416, the parent presenter positions the called child presenter in the allocated layout space of the parent presenter based on the placement algorithm / strategy. In one embodiment of the invention, at step 1416, the parent presenter places the child presenter in their layout based on the height and width parameters of the child presenter obtained by the presenter at step 1414.

Then, control returns to block 1402, where the parent presenter's OnUpdate method 470 continues to update the remaining child presenters (via their child shell intermediaries).

If at step 1404 there are no child presenters (element or mediator presenters) to be processed / updated, control proceeds to step 1420. At step 1420, the called presenter's OnUpdate method 470 implements customization functions configured according to user requirements, including possible additional calls to OnUpdate method 470 on child presenters, to configure the layout for the presenter.

At step 1422, or, which is possible, at any time when new information is obtained by the OnUpdate method 470, the results of the layout processing are cached for later use in the re-visualization step in the process of processing the graphic image.

After completion of the update processing for this presenter, including for all child presenters of the called presenter, at step 1424, the presenter returns its size to the caller (system 200 presenters), as well as a value indicating whether a second visualization of this presenter is necessary.

It will be apparent to those skilled in the art that, by way of examples, a new platform and methods have been described to control the layout / presentation processing of graphical document / user interface output data in a computing environment including graphical output devices such as a graphical user interface display or printer. From the point of view of the many possible environments in which the principles of this invention can be implemented, and the flexibility of designing and implementing software utilities and tools, it should be noted that the options described here are only an illustration and should not be construed as limiting the scope of the invention. Those skilled in the art who use the present invention, it is obvious that the options shown here can be modified in structure and in detail, without going beyond the merits of the invention. Thus, the invention described herein considers all of these options as being included in the scope of the following claims and their equivalents.

Claims (51)

1. The control system layout graphic output data for organizing and maintaining graphically displayed output data of programs running on a computer system, and the control system layout graphic output data contains graphic elements containing data that represent the displayed content of the program; presenters defining display states for graphic elements, where a particular type of presenter supports a layout description for the corresponding graphic element; and a system of presenters, including the leading interface of the presenters, containing a method for preparing the layout for the visible image in accordance with the set of presenters associated with graphic elements contained in the visible image. 2. The graphical output layout control system according to claim 1, wherein the presenter system further comprises a base class of presenters and in which a set of presenters is created from presenter classes derived from the base class of presenters. 3. The graphical output layout control system of claim 2, wherein the presenters include an update method for computing layout properties for the presenter. 4. The control system for the layout of the graphic output data according to claim 3, in which the presenters include a visualization method for generating commands issued to the graphic output subsystem of the computer system. 5. The control system for the layout of the graphic output data according to claim 2, in which the classes of presenters include predefined classes of presenters and classes of external presenters. 6. The layout control system of the graphic output data according to claim 1, in which each of the presenters calculates the layout state for the corresponding graphic element based on the values of the layout parameters specified on the presenter. 7. The graphical output composition management system of claim 1, further comprising a set of notification handlers, each notification handler associated with one particular presenter from a set of presenters in the visible image, and where the notification handler processes the change in the graphic to determine whether to update appropriate presenter. 8. The graphical output composition management system of claim 7, wherein each presenter defines a type of notification handler that provides change notifications to a particular presenter related to the graphic element associated with it. 9. The graphical output layout control system of claim 8, wherein the notification handler determines a portion of the corresponding presenter that needs to be updated due to changes in the associated graphical element. 10. The layout control system for the graphic output data according to claim 7, wherein the system of presenters registers by means of notification handlers those presenters that require updating based on changes in the corresponding graphic elements. 11. The control system for the layout of the graphic output data according to claim 1, in which one instance of the graphic element from among the graphic elements associated with many presenters. 12. The graphical output layout control system of claim 11, wherein the plurality of presenters with which the graphic instance is associated are the same type of presenters. 13. The graphical output layout control system of claim 12, wherein the plurality of presenters corresponds to individual columns in the same visible image. 14. The graphical output layout control system of claim 12, wherein the plurality of presenters corresponds to individual pages in the document visible image of one graphic element. 15. The graphical output composition management system of claim 11, wherein the first presenter and the second presenter of the plurality of presenters associated with an instance of the graphic element are associated with respective first and second separate visible images. 16. The control system for the layout of the graphic output data according to clause 15, in which the "hosting" of the first and second separate visible images is performed by the corresponding first and second systems of presenters. 17. The control system for the layout of the graphic output data according to claim 1, in which the visible image corresponds to a rectangular region in the space of the graphic display. 18. The graphical output layout control system of claim 11, wherein the plurality of presenters associated with the graphic instance is a plurality of different types of presenters. 19. The graphical output layout control system of claim 18, wherein one of the plurality of presenters comprises a presenter of “trim” elements for the main presenter. 20. The graphical output composition management system of claim 1, wherein the presenters in the visible image are hierarchically arranged so that the child presenters are contained in the area specified by the corresponding parent presenter. 21. The system of presenters for inclusion in the composition management system of the graphic output data for processing the layout on behalf of a program that provides graphic elements that contain data representing the displayed content of the program, by means of presenters that determine display states for graphic elements, and the presenter supports the description layouts for the corresponding graphic element, and where the presenter system manages and organizes presenters associated with diffrac- tion elements within a view, the presenter system comprising a presenter base class from which presenter classes are obtained, and wherein the presenters are created from the presenter classes; and a leading presenters interface comprising a set of methods, including at least a method for preparing a layout embodied in a set of presenters associated with graphic elements in a visible image. 22. The system of presenters according to item 21, in which the base class of presenters defines a user-configurable update method, replaced by the resulting classes of presenters, to calculate the layout properties for the presenter. 23. The system of presenters according to item 22, in which the base class of presenters sets a user-customizable visualization method, replaced by the received classes of presenters, for generating commands issued to the graphical output subsystem of a computer system. 24. The system of presenters according to item 21, in which the system of presenters supports a set of classes of presenters, which includes predefined classes of presenters and external classes of presenters. 25. The system of presenters according to item 21, in which the base class of presenters defines a method for calculating the layout state for a graphic element based on the values of the layout parameters specified on the associated presenter. 26. The presenter system according to claim 21, further comprising a base class of notification handlers from which classes of notification handlers are obtained, and in which each notification handler created from the class of notification handlers is associated with a specific presenter in the visible image, and where the notification handler processes the change graphic element to determine if the appropriate presenter should be updated. 27. The presenter system according to claim 26, wherein the base presenter class includes a “placeholder” for the presenter to specify the type of notification handler that provides change notifications to a specific presenter related to the graphic element associated with it. 28. The system of presenters according to claim 26, in which the system of presenters registers by means of notification handlers those presenters who need updating, based on changes in the corresponding graphic elements. 29. The system of presenters according to item 21, in which the system of presenters is associated with a visible image characterized by a root graphic element and a designated area in which the root graphic element and its child graphic elements are displayed. 30. The system of presenters according to clause 29, in which the visible image corresponds to a rectangular region in the space of the graphic display. 31. The system of presenters according to item 21, in which the leading interface of presenters includes a constructor for creating a system of presenters for layout display for a visible image containing a set of graphic elements. 32. The system of presenters according to p, in which the visible image is set at least partially by the root graphic element sent to the designer. 33. The system of presenters according to item 21, in which the system of presenters supports the coupling of many presenters, so that the first presenter provides a "finish" for the second presenter associated with the graphic element. 34. The system of presenters according to item 21, in which the base class of presenters includes a "placeholder" for defining child presenters, thereby supporting the creation of a hierarchical tree structure of presenters in the visible image, so that the child presenters are in the area specified by the corresponding parent presenter. 35. A method for processing a layout on behalf of a program providing graphic elements that contain data representing the displayed content of the program by means of presenters defining display states for graphic elements, and wherein the presenter maintains a description of the layout for the corresponding graphic element, while the presenter system provides hosting and organizing presenters associated with graphic elements in the visible image, the method comprising the steps of: provide a system of presenters containing the base class of presenters and a leading interface for presenters, containing a method for creating the layout embodied in a set of presenters associated with graphic elements in the visible image; accept the presenter’s leading interface to request a layout for a set of graphic elements in the visible image; and create corresponding presenters for the set of graphic elements from the set of presenter classes obtained from the base class of presenters, and call the method on each created presenter to calculate the layout state for the graphic element corresponding to the presenter. 36. The method according to clause 35, further comprising the step of: provide a base class of notification handlers that defines an interface for a set of notification handlers that facilitate step-by-step updating of the layout based on changes in the corresponding graphic elements. 37. The method according to clause 35, further comprising organizing presenters for the visible image in the form of a hierarchical tree. 38. The method according to clause 35, in which in response to the challenge of creating a layout for the visible image create a system of presenters, thereby creating a separate system of presenters and corresponding presenters for each visible image. 39. The method according to clause 35, in which the base class of presenters defines an update method for calculating the layout properties for the presenter instance associated with a particular graphic element. 40. The method according to clause 35, in which the base class of presenters defines a visualization method for generating commands issued to the graphical output subsystem. 41. The method according to clause 35, in which the system of presenters supports the formation of predefined classes of presenters and external classes of presenters. 42. The method according to clause 35, in which the classes of presenters correspond to different types of presenters that compose various types of content of the graphic element. 43. The method according to clause 35, in which the presenters in the visible image are hierarchically ordered so that the child presenters are contained in the area specified by the corresponding parent presenter. 44. A computer-readable medium including computer-executable instructions to facilitate image processing on behalf of a program providing graphic elements that contain data representing the displayed content of the program, by presenters defining display states for the graphic elements, and where the presenter supports a layout description for corresponding graphic element and where the system of presenters provides hosting and ordering of presenters associated with the graph eskimi elements visible in the image, wherein the computer readable instructions, facilitating the execution of the method steps comprise: providing a system of presenters containing the base class of presenters and a leading interface for presenters, containing a method for creating the layout embodied in a set of presenters associated with graphic elements in the visible image; receiving the leading interface of the presenters of the request for the formation of the layout for a set of graphic elements in the visible image; and creating for the set of graphic elements corresponding presenters from the set of presenter classes obtained from the base class of presenters, and calling the method on each created presenter to calculate the layout state for the graphic element corresponding to the presenter. 45. The computer-readable medium of claim 44, further comprising computer-readable commands for arranging the presenters for the visible image in the form of a hierarchical tree. 46. The computer-readable medium of claim 44, wherein the computer-executable instructions facilitate creating an instance of the presenter system in response to a call to create a layout for the visible image, thereby creating a separate presenter system and corresponding presenters for each visible image. 47. The computer-readable medium of claim 44, wherein the base class of presenters defines an update method for computing layout properties for a presenter instance associated with a particular graphic element. 48. The computer-readable medium of claim 44, wherein the base class of presenters defines a visualization method for generating commands issued to the graphical output subsystem. 49. The computer-readable medium of claim 44, wherein the presenter system supports the formation of predetermined presenter classes and external presenter classes. 50. The computer-readable medium of claim 44, wherein the presenter classes correspond to different types of presenters that compose various types of graphic element content. 51. The computer-readable medium of claim 44, wherein the base class of presenters sets a placeholder for child presenters, thereby facilitating the hierarchical arrangement of presenters in the visible image, so that the child presenters are contained in the area specified by the corresponding parent presenter.

Images