Mapping between model object and window surface

Mapping Model object ↔ Window interface

In order to present data in any form and composition, the basic visualisation algorithms contained in the InstantView® engine must be combined like building blocks. InstantView® achieves this flexibility by mapping the data to the window objects of the user interface. Access expressions are assigned to the window objects (input fields), which control the data input and output.

The relationships between objects are also visualised in this way.

The data transfer from the model to the surface and vice versa is triggered by four InstantView® instructions:

Using the example of three hypothetical classes, it is shown how InstantView® binds the window objects of the interface to data of the model objects: The classes A, B describe a person to whom any number of (or no) address details - class C - are assigned:

   class A
   {
      . . .
      char *name;
      char *firstName;
      short sex;
   };

   class B : public A
   {
      . . .
      os_Set address;  // 0 ... n addresses
      . . .
   };

   class C
   {
      . . .
      char *city;
      . . .
   }
 

These data are displayed in a window, with a maximum of three addresses:

Window(win1, 30, 30, 600, 110, "F i l l W i n d o w")
   {
     Prompt(p1, 10, 10, T("Name:", "name:", "nom:"))
     String(A::name, 70, 10, 140)
     Prompt(p2, 250, 10, T("Vorname:", "first name:", "prénom:"))
     String(A::firstName, 350, 10, 140)
     Enum(A::sex, 350, 20,  115, 30)
     // bis zu drei Adressen werden dargestellt:
     Prompt(p3, VOLATILE(adr1), 10, 40, T("Adresse 1:", "1st address", "adresse 1"))
     String(B::address[0].city, VOLATILE(adr1), 129, 40, 200)
     Prompt(p4, VOLATILE(adr2), 10, 50, T("Adresse 2:", "2nd address", "adresse 2"))
     String(B::address[1].city, VOLATILE(adr2), 129, 50, 200)
     Prompt(p5, VOLATILE(adr3), 10, 60, T("Adresse 3:", "2nd address", "adresse 2"))
     String(B::address[2].city, VOLATILE(adr3), 129, 60, 200)
   }

The following relationship exists between any object of class B and the window objects:

variable 'person' contain the instance of class B shown above. With

person FillWindow(win1)

you get:

Note that FillWindow takes into account the derivation A → B Since the collection 'address' contains only two objects of class C, the line for address 3 is hidden.

In the above example, window objects and data fields were uniquely assigned to each other. If this is not possible, access functions offer a possibility to realise more complicated correlations between data fields and window surface without having to abandon the basic separation between model classes and visualisation.