Fonctionnement ( Traitement Standard )

Description

Ce modèle est appelé depuis un bouton bas d'écran, un menu, le menu contextuel d'un champ ou une fonction, pour effectuer un traitement procédural. Ce traitement peut fait appel au modèle "saisie fenêtre" pour gérer la saisie d'une fenêtre de critères et la saisie d'une fenêtre principale. La fenêtre de critères peut être composée de un ou plusieurs onglets. Par contre pour pouvoir s'exécuter en batch, elle est limitée à 500 champs et un nom de champ ne doit pas se retrouver sur plusieurs écrans. Dans ce modèle "traitement standard", plusieurs actions sont appelées. L'action essentielle est l'action EXEC ; celle-ci contiendra votre traitement procédural. Aucune transaction de mise à jour n'est prévue dans ce modèle : elle est donc à prévoir dans votre traitement.

Ce traitement peut être lancé par la soumission d'une requête batch. Dans ce cas, on peut considérer deux phases : phase interactive de saisie des paramètres de lancement, et phase batch d'exécution du traitement. Deux variables globales nous permettent de connaître le contexte de lancement :

  • GBATCH  en phase de saisie paramètres ( 0=interactif, 1=batch )
  • GSERVEUR  en phase d'exécution traitement ( 0=interactif, 1=batch )

La saisie initiale des paramètres 
Elle se fait par l'intermédiaire d'une boite de dialogue ou d'une saisie fenêtre. Lorsque le traitement standard est lancé en batch, la première phase ( saisie initiale ) est interactive et lancée immédiatement, alors que la deuxième phase ( traitement ) est enregistrée dans la file d'attente des travaux du serveur batch. Les paramètres saisis sont alors enregistrés dans la table système ABATRQT, pour ensuite, être relus dans la deuxième phase du traitement.

Attention !
Le nombre de paramètres est limité à 500.
Par contre, pas de limite dans la longueur d'un champ alphanumérique.

Stockage dans la table des requêtes :

  • Le champ DEB(15)(80) contient le nom du champ dans l'écran de saisie des critères
  • Le champ FIN (30)(80) contient la valeur du champ.
  • Si la valeur du champ > 30, les caractères > 30 sont mis sur l'indice suivant.
  • Si nombre de champs > 80, on enregistre la requête courante avec DEB(79)="&" et on crée un deuxième enregistrement (no de requête +1) avec FLAG=99. Sept enregistrements peuvent ainsi être créés.
  • Un champ écran est pris en compte s'il n'est pas nul ou vide.

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
Ce traitement, fourni par ADONIX, ne doit absolument pas être modifié par le spécifique. 

Le traitement spécifique
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