Fonctionnement ( consultation )

Description

Ce modèle est appelé depuis une fonction, un bouton bas d'écran, un menu ou un menu contextuel. Ce modèle permet de visualiser un ensemble d'enregistrements d'une table, sélectionnés en fonction de critères saisis par l'utilisateur ou bien passés par programme. Ce modèle offre la possibilité d'afficher les résultats de la consultation sous forme d'un graphe.

Ergonomie

La consultation se présente avec un écran d'entête, comprenant les critères principaux pour la sélection des enregistrements, et un onglet principal constitué d'un ensemble d'enregistrements à afficher. Cet onglet est un tableau pour lequel chaque ligne correspond à un enregistrement. On a ensuite la possibilité d'avoir divers onglets supplémentaires. Attention ! ce modèle ne chargement pas automatiquement les informations dans ces onglets; le chargement des onglets doit se programmer dans l'action LECTURE. Lorsque les critères sont nombreux, ils peuvent être regroupés dans un écran particulier, qui sera affiché lorsque l'utilisateur clickera sur le bouton CRITERES. Le bouton GRAPHIQUE, permet l'affichage d'un graphe, à la condition de fournir les données à afficher dans l'action GRAPH.

Normalisation des éléments du dictionnaire

    Ecran d'entête : doit se nommer "CONS" + code consultation + "1"

    Ecran de détail : doit se nommer "CONS" + code consultation + "2"

    Ces 2 écrans sont regroupés dans une fenêtre principale nommée "FCNS" + code consultation. cette fenêtre est de type "plein écran".

    Ecran de critères : doit se nommer "CRIT" + code consultation. il est facultatif.

    Cet écran est encapsulé dans une fenêtre de critères nommée "DCNS" + code consultation. cette fenêtre est de type "boite de dialogue". Elle est facultative.

    Consultation : elle est identifiée par le code consultation sur 3 caractères. Attention ! pour le spécifique, ce code doit commencer par l'une des 3 lettres suivantes : X, Y ou Z. La consultation regroupe la fenêtre principale et la fenêtre de critères.

   Action : doit se nommer "CONS" + code consultation. Dans cette action, on précise obligatoirement le code consultation. Et puis, il est possible de définir des paramètres.

   Fonction : doit se nommer "CONS" + code consultation. Dans cette fonction, on précise obligatoirement l'action et éventuellement des valeurs pour les paramètres de cette action.

Les écrans

pour l'écran de détail de la fenêtre principale, la variable de bas de tableau doit se nommer NBLIG.

pour l'écran de critères, si l'on désire que le modèle gère la mémorisation des paramètres de cet écran, il faudra la présence du champ MEMO. De plus, si on veut que l'écran des détails de la fenêtre principale soit paramétrable, il faudra la présence du champ ECRAN. Le principe est le suivant : sur la base de l'écran de détail déclaré dans la fenêtre principale, l'utilisateur peut se construire un ensemble d'écrans de détail par la fonction Paramétrage / Paramètres généraux / Ecrans de consultation. Ces écrans pourront n'afficher que certaines colonnes et ceci dans un ordre qui peut être différent par rapport à l'écran de base. L'utilisateur choisit l'un de ces écrans, par le champ ECRAN de la fenêtre de critères.

      

Les traitements

Le modèle est un traitement superviseur qui fait appel à deux traitements annexes : le traitement standard et le traitement spécifique, s'il sont renseignés dans le dictionnaire de l'action. Ces deux traitements Sont structurés de la même façon, c'est à dire qu'ils commencent par une étiquette ACTION, qui traite les différents évènements susceptibles d'arriver lors de l'exécution de la fonction.

Le traitement standard
Il est nommé CNSxxxSTD ( xxx est le code de la consultation ). 
Ce traitement, fourni par ADONIX, ne doit absolument pas être modifié par le spécifique. 

Le traitement spécifique
Il doit se nommer CNSxxxSPE ( xxx est le code de la consultation ). Ce traitement n'est pas fourni par Adonix, mais il peut être développé en spécifique (à la fois pour des fonctions standards pour lesquelles on désire faire des ajouts et pour les fonctions spécifiques). 

Les Actions

Le traitement standard ou spécifique comment donc par cette étiquette $ACTION à écrire de la façon suivante ( ou XXXXXX est le code de l'évènement ) : 

$ ACTION
Case ACTION
   When "XXXXXX" : Gosub XXXXXX
   When default
Endcase
Return

Chaque événement est identifié par un code alphanumérique, contenu dans la variable ACTION. S’il n’y a pas de traitement pour un événement, le fonctionnement de la fonction n'en sera pas entravé. C'est dans le sous-programme $ACTION, que l'on fait l'aiguillage vers l'étiquette ajoutée. On précisera dans cette syntaxe "case ACTION", autant de lignes qu'il y a d'évènements à compléter. Le $ACTION est appelé du traitement superviseur par GOSUB ; Cela permet donc d'utiliser des variables locales au traitement superviseur. 

On trouvera ci-joint la liste des actions. On trouvera ensuite,  la description détaillée de ces actions. On y décrit le contexte appelant et l'OBJectif de ces actions.

Ajout d'actions spécifiques sur le standard

Par défaut, pour un même évènement, l'action spécifique est appelée avant l'action standard. 

Elle peut annuler et remplacer l'action standard si elle positionne la variable GPE à la valeur 1. 

Pour exécuter l'action standard avant l'action spécifique, dans ce cas, on duplique le traitement standard dans l'action spécifique, on y ajout le traitement spécifique puis on positionne la variable GPE à la valeur 1. Exemple :

Traitement superviseur
GPE=0
Gosub  ACTION  From  trait_std              ( appel du standard )
If GPE=0
   Gosub  ACTION  From  trait_spé.            ( appel du spécifique )
Endif

Traitement spécifique
$ ACTION
Case ACTION
   When "OUVRE" : Gosub OUVRE
   When default
Endcase
Return

$OUVRE
...                                                                ( action spécifique OUVRE )
GPE = 1                                                     ( pas d’appel du standard suite au spécifique )
Return

---