XSL components 

Monthly planning

Graph associated with an X3 grid, that is used to view and modify a planning presented month by month.

The possibilities linked to this monthly planning :

  • Assignment of 1 to 8 activities
  • Sub-dividing of all the days into 1 to 4 sections.
  • Management of a maximum 12 months, potentially overlapping two years.
  • Assignment of 1 to 12 months simultaneously. According to the parameterization, it is possible to have a vertical scroll bar.
  • According to the sub-division of the days, within the limit of a month, for the assignment of an activity.
  • Three types of mandatory days (local menu 9836) : working, weekend, vacation
  • An activity can only take place on a working day.

Usage of the component

Drag and Drop :

  • Move an element and all those that are attached to it

Click on field :

  • Positioning request for the server on the line in a corresponding grid

Right-Click on field :

  • Contextual menu button, with positioning on the line in the corresponding grid

Double-click on field :

  • Execution of the process AMAJHIER with the CODACT="E"

Usage of the palette

It is necessary to firstly select an activity. Its title will be displayed in bold.
There is then the possibility to select the sub-sections of the days where this activity will replace the current activity. The XSL component will then contact the server using the interaction program defined in the XSL parameterization. This is the server that is in charge of the update of the data in the grid. If the server returns a code that is not equal to 1, the local update is cancelled. The program shipped as standard, does not authorize an activity during vacations and at the weekend.

Design possibilities

  • Assignment of 1 to 8 activities
  • Sub-dividing of all the days into 1 to 4 sections.
  • Management of a maximum 12 months, potentially overlapping two years.
  • Assignment of 1 to 12 months simultaneously. According to the parameterization, it is possible to have a vertical scroll bar.
  • According to the sub-division of the days, within the limit of a month, for the assignment of an activity.
  • Three types of mandatory days (local menu 9836) : working, weekend, vacation
  • An activity can only take place on a working day.

To function, the XSL planning component needs the information contained in the grid associated with the graph and by the XSL parameterization.

The screen

Graphical parameters linked to the grid section

The XSL monthly planning component APLANM proposes 4 options :

  • NBMONT : Number of months displayed simultaneously (value 1 to 12).
  • MENACT : Local menu type of activity (9837 with 5 values as standard). The elements of this local menu are modifiable. This parameter gives the possibility to call another local menu. Whether for local menu 9837 proposed as standard or for another local menu selected with this parameter, there is a maximum of 8 elements.
    Remark : the colours used are however, fixed by XSL.
  • SDATA : Update of the graph following a return to interactive mode. Value 0 or 1. By default No (0). On return to the interaction sub-program, the graph is not recalculated even if there is a change in the data. Only the return code is processed which validates or not the return of information and gives rise to a local interaction in order to accept the modification.
  • PINTER : Interaction program By default, the program AMAJPLAN is called, however, it is possible to call another, this is used to name the fields differently and to intervene in the acceptance, interaction or total rules.
Fields in the grid

The X3 grid on entry must be constituted of a line by day.

The grid must contain the next fields, characterised by the "parameterization" column.

  • "Internal date" in field (alpha 15) composed of
    • Year WWYY
    • No of months MM
    • No of days in the month DD
    • No of the week in the year WW
    • No of days in the week D (1 Monday to 7 December)

Each value is separated by a -.
The sub-program TRSFDATP(DATE,DATTEC) from INTRUTILA is used to construct DATTEC from a date in the Adonix date format date . This column can be defined in an invisible field, transmitted to clients of the miscellaneous types. Example : 2006-05-12-19-5 corresponding to Friday May 12 2006.

  • "Type of Day" where the values are associate with the local menu 9836.
    • 1 : open
    • 2 : week-end
    • 3 : vacation

To reduce the flows between the server and the client, there is the possibility to define the value in numeric and to replace it with the values 1, 2 or 3 that are imposed. With the standard interaction program supplied, only the working days can be updated, following a change of activity.

  • "Section 1 to Section n" according to the sub-division of the day carried out. There is the possibility to sub-divided the day into 1 to 4 sections. The presence of the columns defines the number of sections.

In addition, if requiring to use the standard interaction program AMAJPLAN, the names of the next fields are imposed because they are written into the program.

  • Columns at the bottom of the grid : NBDAY
  • Internal : TECDAT
  • Type of day : TYPDAY
  • Sections of the day : PLAG1, PLAG2, PLAG3 et PLAG4. It is necessary to define at least 1, the program tests for their presence and adapts to the number defined.
  • Totals : TOTTYP1 to TOTTYP8. The program tests for their presence and loads them as a function of the number of days corresponding to each type of day.

The XSL parameterization

These three local menus are shipped as standard and associated with a code defined in the XSL parameterization :

  • 9001 : MONTH - Label for the month
  • 9833 : DAY - Label for the days
  • 9834 : ABRDAY - Abbreviated label for the days

There is the possibility to assign other local menus to these codes, which are themselves fixed.

Interactions

They are defined and made into templates using a standard sub-program MAJPLAN From AMAJPLAN to which the following parameter is passed :

  • LDEB : Integer - Interaction start line in the grid
  • PLAGED : Integer - Section start (1 to 4 according to the number of day sections)
  • LFIN : Integer - Line end
  • PLAGEF : Integer - Section end (identical to the section start)
  • ETAT : Integer  - Type of activity placed on the working day (from 1 to a number of the value of the activity type menu - 9837 or its replacement)
  • MESSAGE: Char - Return message
  • CODRET : Integer - Return code (1 = OK)

The component expects 365 or 366 lines in the grid, representing 12 successive months that can extend over 2 year.

Planning annual

Graph associated with an X3 grid, that is used to view and modify a planning presented by year.

Usage of the component

identical to monthly planning

Usage of the palette

identical to monthly planning

Design possibility

  • Assignment of 1 to 8 activities
  • Sub-dividing of all the days into 1 to 4 sections.
  • Management of a maximum 12 months, potentially overlapping two years.
  • According to the sub-division of the days, within the limit of a month, for the assignment of an activity.
  • Three types of mandatory days (local menu 9836) : working, weekend, vacation
  • An activity can only take place on a working day.

The XSL planning component needs to identify the following information in order to function, which are carried by the associated grid and by the XSL parameterization.

The screen

Graphical parameters linked to the grid section

The XSL annual planning component APLANY proposes 3 options :

  • MENACT : Local menu type of activity (9837 with 5 values as standard). The elements of this local menu are modifiable. This parameter gives the possibility to call another local menu. Whether for local menu 9837 proposed as standard or for another local menu selected with this parameter, there is a maximum of 8 elements.
    Remark : the colours used are however, fixed by XSL.
  • SDATA : Update of the graph following a return to interactive mode. Value 0 or 1. By default No (0). On return to the interaction sub-program, the graph is not recalculated even if there is a change in the data. Only the return code is processed which validates or not the return of information and gives rise to a local interaction in order to accept the modification.
  • PINTER : Interaction program By default, the program AMAJPLAN is called, however, it is possible to call another, this is used to name the fields differently and to intervene in the acceptance, interaction or total rules.
Fields in the grid

The X3 grid on entry must be constituted of a line by day.

The grid must contain the next fields, characterised by the "parameterization" column.

  • "Internal date" in field (alpha 15) composed of
    • Year WWYY
    • No of months MM
    • No of days in the month DD
    • No of the week in the year WW
    • No of days in the week D (1 Monday to 7 December)

Each value is separated by a -.
The sub-program TRSFDATP(DATE,DATTEC) from INTRUTILA is used to construct DATTEC from a date in the Adonix date format date . This column can be defined in an invisible field, transmitted to clients of the miscellaneous types. Example : 2006-05-12-19-5 corresponding to Friday May 12 2006.

  • "Type of Day" where the values are associate with the local menu 9836.
    • 1 : open
    • 2 : week-end
    • 3 : vacation

To reduce the flows between the server and the client, there is the possibility to define the value in numeric and to replace it with the values 1, 2 or 3 that are imposed. With the standard interaction program supplied, only the working days can be updated, following a change of activity.

  • "Section 1 to Section n" according to the sub-division of the day carried out. There is the possibility to sub-divided the day into 1 to 4 sections. The presence of the columns defines the number of sections.

In addition, if requiring to use the standard interaction program AMAJPLAN, the names of the next fields are imposed because they are written into the program.

  • Columns at the bottom of the grid : NBDAY
  • Internal : TECDAT
  • Type of day : TYPDAY
  • Sections of the day : PLAG1, PLAG2, PLAG3 and PLAG4. It is necessary to define at least 1, the program tests for their presence and adapts to the number defined.
  • Totals : TOTTYP1 to TOTTYP8. The program tests for their presence and loads them as a function of the number of days corresponding to each type of day.

The XSL parameterization

identical to monthly planning

Radar

Display of a grid with a graphical representation in the form of a radar within which :

  • each colour represents a line in the grid.
  • each axis represents a column with a value in the grid.

The possibilities linked to this radar :

  • Graph in display mode only
  • Button possible on the variable at the bottom of the grid is accessible in the graph by right click on each color.
  • Possiblity to display a maximum value
  • Possibility to display a scale
  • Many elements are visible (grid line). Limit to a reasonable number for clarity in the graph.
  • Several axes can be displayed (grid column). 3 minimum and limit to a reasonable number for the clarity of the graph.

Usage of the component

Pass over a field :

  • Increases the opacity of the field
  • Info bullet label

Click on field :

  • Positioning request for the server on the line in a corresponding grid

Right-Click on field :

  • Request positioning on a line in the corresponding grid)
  • Contextual button menu (line in corresponding grid)

Click on the colour legend :

  • Move to the front, the corresponding field
  • Increase opacity

Click on the "eye" legend :

  • Mask the corresponding field

The XSL radar component needs to identify the following information in order to function, which are carried by the associated grid and by the XSL parameterization.

The screen

Graphical parameters linked to the grid section

The XSL radar planning component ARADAR proposes 3 options :

  • SCALE : used to fix a scale in the display (by default 0). If this scale is set to 0, the component adapts to the scale at the largest value to be represented, if not the values are transferred to the scale.
  • MENSCA : Scale menu. It is used to define a legend for the different values in the scale. This information must be a number of a local menu. If the value is set to 0 (default), there is no scale displayed.
  • SDATA : Update of the graph following a return to interactive mode. Value 0 or 1. By default Yes (1).
Fields in the grid

The X3 grid on entry must be constituted of a line by element to be studied.

The grid must contain the next fields, characterised by the "parameterization" column.

  • "Key" : field containing a unique identifier
  • "Label" : field containing the label for the identifier
  • "Value" : a field by analysis axis where the title is specified in the label. These fields must be of the integer or decimal type

Horizontal Nomenclature

Display of a grid with a graphical representation in the form of an flowchart within which :

  • each element represents a line in the grid.

The possibilities linked to the horizontal nomenclature :

  • possibility to move an element and all that is linked to it (subject to the parameterization)
  • possibility to display an image in the framework (subject to the parameterization).
  • possibility to have a contextual menu for each element (deletion of an element by button action)
  • Possibility to execute a process associated with a double click (subject to the parameterization)

The XSL "horizontal nomenclature" component needs to identify the following information in order to function, which are carried by the associated grid and by the XSL parameterization.

The screen

Graphical parameters linked to the grid section

The XSL monthly planning component ANOMH proposes 5 options :

  • MODHIE : Authorizes the movement of an element and all that is attached to it. Value : 1 no/ 2 yes. By default Yes (2).
  • SIZEB: Size of the box for each element in pixels expressed in height and width. (by default : 100,100).
  • SDATA : Update of the graph following a return to interactive mode. Value : 0 no / 1 yes. By default No (0). On return to the interaction sub-program, the graph is not recalculated even if there is a change in the data. Only the return code is processed which validates or not the return of information and gives rise to a local interaction in order to accept the modification.
  • PINTER : Interaction program By default the AMAJHIER program is called, it is possible to call another, which makes it possible to call the fields and to intervene in the rules for the interaction acceptance.
  • EXECFL : Authorize the call to a sub-program with double-click on the element of the lowest level.
Fields in the grid

The X3 grid on entry must be constituted of a line by day.

The grid must contain the next fields, characterised by the "parameterization" column.

  • "Parent key" : key for the parent for the current record. Empty, if it is the header of the nomenclature, if not mandatory.
  • "Key" : key for the current record, mandatory.
  • "image" : image displayed in the flowchart boxes. The image must be localized in the directory of the resources by folder (/X3_PUB/folder/RES). The image is re-dimensioned as a function of the SIZEB parameter, optional column.
  • "short label" : displayed in the element box, optional column.
  • "long label" : info bullet when passing over the element, optional column.

In addition, if wanting to work with the standard interaction program AMAJHIER, the names of the following fields are imposed :

  • Columns at the bottom of the grid : NBCMP
  • Parent key : PARENT
  • Key : KEYC
  • Short label : LIBSHORT
  • Long label : LIBL1
  • Image : IMG

The XSL parameterization

Interactions

They are defined and made into templates using a standard sub-program MAJHIER From AMAJHIER to which the following parameter is passed :

  • CODACT: Char - action code (D delete / M Modify / Execute)
  • NLI: Integer - Line number for the component to be processed (1 to n)
  • FATHVAL: Integer - Number of the line for the attachment element (parent if RANGNIV=0, child if RANGNIV=1 or -1)

  • RANGNIV: Integer - type of attachment (0 below, 1 to the right, -1 to the left)
  • MESSAGE: Char - Return message
  • CODRET : Integer - Return code (1 = OK)

To delete an element, an action button will be used in the variable at the bottom of the grid and write :

Local Char MESSAGE(100)
Local Integer CODRET
Call MAJHIER("D",nolign,"",0,MESSAGE,CODRET) From AMAJHIER
If CODRET<>1
   Call ERREUR(MESSAGE) From GESECRAN
Endif

  

Vertical nomenclature

Display of a grid with a graphical representation in the form of an flowchart within which :

  • each element represents a line in the grid.

The possibilities linked to the horizontal nomenclature :

  • fold -unfold an element (click)
  • to move an element and all that is linked to it (subject to the parameterization)
  • delete an element and all that is attached to it (right click)
  • execute a process with a double click on the last element (subject to the parameterization).

The XSL "horizontal nomenclature" component needs to identify the following information in order to function, which are carried by the associated grid and by the XSL parameterization.

The screen

Graphical parameters linked to the grid section

The XSL monthly planning component ANOMV proposes 4 options :

  • MODHIE : Authorizes the movement of an element and all that is attached to it. Value : 1 no/ 2 yes. By default Yes (2).
  • EXECFL : Authorize the call to a sub-program with double-click on the element of the lowest level.
  • SDATA : Update of the graph following a return to interactive mode. Value : 0 no / 1 yes. By default No (0). On return to the interaction sub-program, the graph is not recalculated even if there is a change in the data. Only the return code is processed which validates or not the return of information and gives rise to a local interaction in order to accept the modification.
  • PINTER : Interaction program By default the AMAJHIER program is called, it is possible to call another, which makes it possible to call the fields and to intervene in the rules for the interaction acceptance.
Fields in the grid

The X3 grid on entry must be constituted of a line by day.

The grid must contain the next fields, characterised by the "parameterization" column.

  • "Parent key" : key for the parent for the current record. Empty, if it is the header of the nomenclature, if not mandatory.
  • "Key" : key for the current record, mandatory.
  • "icon" : optional, icon displayed at the start of the line. The icon must be localized in the standard resources directory (/X3_PUB/X3_PUB/RESSTD/IMG), specific/custom (/X3_PUB/X3_PUB/RESPER/IMG), or vertical (/X3_PUB/X3_PUB/RESVER/IMG).
  • "long label" : Long label, mandatory.
  • "short label" : short label, optional, in case of the presence of the column, display the info bullet.

In addition, if wanting to work with the standard interaction program AMAJHIER, the names of the following fields are imposed :

  • Columns at the bottom of the grid : NBCMP
  • Parent key : PARENT
  • Key : KEYC
  • Long label : LIBL1
  • Short label : LIBSHORT
  • Image : ICO

The XSL parameterization

Interactions

They are defined and made into templates using a standard sub-program MAJHIER From AMAJHIER to which the following parameter is passed :

  • CODACT: Char - action code (D delete / M Modify / Execute)
  • NLI: Integer - Line number for the component to be processed (1 to n)
  • FATHVAL: Integer - Number of the line for the attachment element (parent if RANGNIV=0, child if RANGNIV=1 or -1)
  • RANGNIV: Integer - type of attachment (0 below, 1 to the right, -1 to the left)
  • MESSAGE: Char - Return message
  • CODRET : Integer - Return code (1 = OK)

To delete an element, an action button will be used in the variable at the bottom of the grid and write :

Local Char MESSAGE(100)
Local Integer CODRET
Call MAJHIER("D",nolign,"",0,MESSAGE,CODRET) From AMAJHIER
If CODRET<>1
   Call ERREUR(MESSAGE) From GESECRAN
Endif