Charte de développement

La gestion des accès se fera par le global tool et non pas pas SB+.

SB+Security sera uniquement là pour limitier les accounts.

Les applications seront développées sous Universe en FLAVOR Pick.

Au cas ou le FLAVOR d’execution est INFORMATION (pour cause de compatibilité avec les anciens prog) ; Il faut installer le programme INBASIC.UV UV.SELECT en surdéfinition de SELECT, SSELECT.

Les FieldDefn crée des dictionnaires de type D ou I

DMCONT SB.CONTROL<34,1> = ‘1’

• Détails des specs pour les applications multi langues

1. Tri-Grammes

Le commonblock SB+ est à usage du développeur et du système.

Les développements IN-tools se réservent la variable DIM PARMS(30..40) donc il est interdit à une application de charger ces données d'applications sur ces niveaux.

• Les valeurs « en dur » ne sont pas autorisées.
• Une equate est un nom, un mot-clé, mis sur une valeur. Exploitable dans les programme afin d’amélioré la lisibilité du code.
• On utilise le signe _ pour représenter une equate

• _x(6) Constante absolue sur Literal : Vrai,Faux,Ok/Ko
  • qui représente une valeur statique
    • liée à un paramétrage et lu via une expression F(fichier,clé)<attribut>
    • lié à un code Module, un code racine, …
    • lié à une valeur située en mémoire dans le Common @PARMS(x)<y,z>, @USERDATA(x), …
  • exemple :
    • _S == ‘#’ ; Séparateur d’application
    • _ICI == @PARMS(1), @PARMS, @USERDATA,…
    • _OUI == 1
    • _NON == 0
    • _VRAI == 1
    • _FAUX == 0

• _r.x(6) Constante Applicative : sur une liste de valeur,
  • ex : les valeurs d’une code table ou « r » représente une racine rappelant le code table.
  • Exemple : code_table type de compte comptable TCC

• Dans les programmes on peut tester : IF CLI.CAT.COMPTE = _TCC.CLI THEN …cela améliore fortement la lisibilité….

• _fff.x Constante structurelle
  • File structure f(,)<,>

Dans la mesure du possible, les commentaires seront saisis en anglais dans les programmes. Si cela constitue une difficulté pour le développeur, sinon en le français .

Les process paragraph devront avoir une en-tête¹⁾ commune telle que :

  P.XXX.YYY...
  *****************************************************************
  * This process is used for ... 
  *****************************************************************
  *   Parameters :
  *
  *   - PAR... : description
  *****************************************************************
  *   History :
  * 
  *   dd/mm/yyyy (user) : Initial Release
  *****************************************************************
  LOCAL ...

Chaque process est susceptible d'être appelé par un phantom (sans interaction avec l'utilisateur) et d'être inclus dans une transaction.

Pour cela, il est important de respecter les règles suivantes :

• On n'affiche les messages que par le GP.ERROR
• Les dialog box sont appelée par le GP.DIALOG
• Chaque WRITE doit avoir pris un lock (même si on est sûr que le record en question n'existe pas encore).
  • Le lock sera pris par la routine B.READUL
• L'appel à un écran ne se fera que si la variable _SILENCE # _OUI

Quand un fichier est créé, on doit générer les equates par l'outil /EQUATES. De là, on aura une entrée dans le fichier xxINCLUDE qui contiendra les equates sur le dictionnaire.

Exemple :

$EQU.CYC
************************************************************
*   Equates for File Fxx.CYC                                
************************************************************
  EQU EQU_CYC.GLB.CYC.CODE   TO   0  ;* Cycle             
  EQU EQU_CYC.GLB.STAMP      TO   1  ;* Stamp             
  EQU EQU_CYC.GLB.LIB        TO   2  ;* Libell‚           
  EQU EQU_CYC.GLB.LIB.FR     TO   2  ;* Libell‚           
  EQU EQU_CYC.GLB.LIB.NL     TO   2  ;* Libell‚           
  EQU EQU_CYC.GLB.LIB.EN     TO   2  ;* Libell‚           
  EQU EQU_CYC.GLB.UTG.CODE   TO   3  ;* Unit‚ de temps    
  EQU EQU_CYC.DEB        TO   4  ;* D‚but                 
************************************************************

Chaque basic devra être écrit dans le fichier xxBASIC et sera nommées telle que SYSID.xxx et devra commencer par une en-tête standard :

SUBROUTINE xx_my_subroutine(parameters)
************************************************************
* This subroutine is used for ... 
************************************************************
* Paramters :
* 
*   param1 : description
************************************************************
* History :
*
*    dd/mm/yyyy (user) : Initial Release
************************************************************ 

Dans la liste des paramètres d'une sous-routine, le paramètre de retour sera toujours le premier paramètre ; ce qui permet d'exploiter la subroutine dans un descripteur I-Type :

SUBROUTINE xx_ma_subroutine(result, parameter.in.1, parameter.in.2, ...)

Certains process sont nécessaire au bon fonctionnement des applications avec IN-tools.

Doit charger en common _SUB.x les valeurs exploitées par les DVS

_SUB.D      F(@SYSID:"DEFN","SUB#D")      
_SUB.V      F(@SYSID:"DEFN","SUB#V")      
_SUB.S      F(@SYSID:"DEFN","SUB#S")      
@RTN.FLAG   0              
_USR.LGE    P("P.USR.LGE") 

Ce process est le premier qui sera exécuté à l'entrée d'une application HK/CONTROL/Process at set common.

Si l'on l'écrit une application à vocation d'upgrade.defn, il faut lancer le process GP.UPGRADE.VERSION dans le process P.SET.COMMON.

EXEC “GP.UPGRADE.VERSION”
EXEC “A.SET.COMMON” 

Détail du P.SET.COMMON

• Tri-Grammes - How to ...

Le fichier global contiendra les définitions des dictionnaires à usage multi fichier.

Fsy.GLB

• Doit être défini lors de l’initialisation de l’application. T,O,H,S

Fsy{.mmm}.fff

• Nom de fichier 3 position : Ecrire une complete description !!
• F est une constante pour représenter un fichier physique
• sy est la valeur du SYSID de l'application, cela marque l'appartenance à l'application
• fff est le trigramme - code du fichier
• mmm est l'optionnel code de module auquel se rattache le fichier ; dans le cas d'une application multi-module.

Qsy.fff

• Représente un fichier pointeur Q / QS vers un fichier distant
• Parfois utilisé pour les mises à jours récurrentes

Ssy.fff_cli

• Représente un dictionnaire logique pour les développements de report & écran spécifique à un client.
• S est une constante pour représenter Synonyme
• sy est la valeur du SYSID de l'application, cela marque l'appartenance à l'application
• fff est le fichier de base, qui sera repris dans le datafile if different du PD.R / PD.I
• cli est la racine attribuée à un client afin de personnaliser ses développements.

Un logical file est typiquement une “vue” sur plusieurs fichiers, L'outil de SB+ permet de définir les règles de join et de mise à jour. Un LF permet de saisir des données présente dans plusieurs fichiers physiques.

Fsy.fff.LF

• LF est une constante qui représente <L>ogical <F>ile

Parfois on décide de créer d'emblé en mode LF

• Fsy.fff partie Header du Logical file 'fff'
• Fsy.fff.xxx partie Detail du Logical file 'fff'

Il est possible de construire le nom en plusieurs parties séparées par un point et si possible en 3 lettres. Ex : on a les articles : FXX.ART et les auteurs de l’article : FXX.ART.AUT

GLB.fff.x(6)

• fff := MAIN Data-FILE

Exemple dans le client, le nom :GLB.CLI.CODE

On applique une conversion du type : MCU[I pour la mise en majuscule en output et surtout en input.

fff.x(6)

• fff := Data-FILE

Exemple dans le client, le nom :CLI.NOM

Dans le cadre des champs gérés en tableau multivalué, on attribuera un trigramme qui permettra d'identifier les champs tous associé en controlant/dépendant. Le trigramme servira à identifier l'assoc_name.

Exemple : le tableau des lignes d'articles dans un document ART est le code d'association:

• DOC.CODE LE code du document
• DOC.ART.CODE Le code de l'article assoc = ASS_ART
  • peut être un GLB.ART.CODE
• DOC.ART.PRIX Le prix de l'article assoc = ASS_ART
• …

Les foreign data sont lue par des expression F / Trans() leur code “en local” rappelle le fichier d'origine.

fff1.fff2.x(6)

• fff1 est le fichier courant
• fff2 est le fichier pointé

Exemple dans une facture, le nom du client : FAC.CLI.NOM. Attention, il est peut être préférable de gérer des globals fields si l’usage est répété.

Si le champs est défini comme @WORK field, il dois comporter un W dans son nom.

Le Nunméro d’attribut Work n’est pas repris, non indispensable.

fff.W.x(6) GLB.fff.W.x(6)

• fff := D-FILE
• .W. := constante
• x(6) := field name

Texte qui se place à gauche du champs dans l’écran.

• Ne pas utiliser de ‘ :’ ; mauvais effet lors de la guitisation.
• Lors de la description des cles d’enregistrements, évitez d’utiliser les mots ‘code, cle,…’ mais un mot qui désigne la nature de la donnée. A la longue, on a plein de ‘Code..’ dans l’écran et on ne sait plus de quoi il s’agit.
• Ne pas oublier que les abréviations sont difficiles à traduire.
  • Ex : « Client » plutôt que « Code client »,
    

« Article » plutôt que « Code Article »,

• Numéroter les champs à la suite,
• Placer les tableau de MV un peu plus loin dans le record ; en démarrant à 10, 20, 30,…

Les numériques-monétaires seront ‘N’ afin de pouvoir modifier le nombre de décimales de présentation des valeurs.

• Taille des clé :
  • Paramètres : 5
  • Signalétique : 15
  • Transaction : 10

• Taille des libellés : 40
• Taille des noms, adresse,.. : 40
• Taille des numériques : 9 (9999.9999)
• Taille des monétaires : 12 (9 999 999.99) et 14 pour les totaux (999 999 999.99)

Texte qui se place au dessus des champs

• Attention à ce que la largeur du texte ne dépasse pas le length of field.
• Concernant le libellé, voir ci-dessus.
• Il peut être sur plusieurs lignes séparée par un @VM

Pour les les monétaires:

• soit MR22, (la virgule marque le séparateur de millier définit)
• soit si associé à ACX P(« A.O.DECIMAL, » :GLB.DEV.CODE) si on respecte les décimales d’une monnaie.

Pour les clés

• MCU[I

Les dates

• D4/

La pluspart du temps, Yes, car c'est le défaut programmé qui va gérer cela.

P(“G.D ”)[M]

• Le process G.D effectue une construction du nom de process à executer pour obtenir la valeur par defaut de ce champs :
• D.fieldname (sans le GLB ni le .W.) exemple : GLB.CLI.CODE → D.CLI.CODE.

C:G.V

• Le process G.V effectura une construction du nom de process à executer pour valider ce champs : V.fieldname (sans le GLB ni le .W.) exemple : GLB.CLI.CODE → V.CLI.CODE

Une valeur à valider comme une clé sur un fichier sera : V.fff.CODE > C :GP.TEST.EXIST,Fsy.fff mettre le P.TST.EXIST,Fsy.fff

G.S

• Le process G.S effectue une construction du nom de process à executer : S.fieldname (sans le GLB ni le .W.) exemple : GLB.CLI.CODE > S.CLI.CODE

• Saisie dans tous les cas, ce champ constitue l’aide de premier niveau.
• Un process GP.HELP sera executer pour l’aide de deuxième niveau.

• A définir pour les ‘C’ controlant ; très important pour les tableaux qui n'affichent pas toutes les colonnes dépendantes.
• Ne pas déclarer les ‘D’ dépendants, cela pose problème lors des phrases AQL.
• Déclarer les AssocName (Nom d’association) par la syntaxe : C;x;x;x[NomAssoc .
  • Avec cela, SB+ va maintenir dans le DICT une clé « NomAssoc » tell que

      0001 PH
      0002 la liste des champs de cette association
      

Par principe, les monétaires seront :

• soit MR22,
• soit si associé à ACX P(« A.I.DECIMAL, » :GLB.DEV.CODE) si on respecte les décimales et les arrondis à l’entrée d’une monnaie.

Par principe, les monétaires si associé à ACX seront : P(« A.R.DECIMAL, » :GLB.DEV.CODE) si on respecte les décimales d’une monnaie.

Influence la création du dictionnaire R/L

Permet d’avoir un champs en saise A alpha et un affichage/tri R right lors des listes. (time,…)

Les codes tables seront :

• Toggle si c’est un OUI/NON
• Radio si ce sont deux valeurs « significative » (bleu,blanc),… (franco/nonfanco), … maximum 3 valeurs
• Combo non saisissable si plus de deux à trois valeurs
• Mémo pour les tableaux de texte
• HTMLObjectRichTExt pour les « texte » formaté HTML (voir CM)

Information complémentaire sur le champs ; cette zone est du texte d’explication du champs, mais peut être détournée pour d’autres usages :

Le principe du “déterounement est d'utiliser un code suisvit de ”:“ et d'une valeur.

Les codes actuellement exploités sont :

• Z (Z:Fsy.fff) Le fichier ZOOM de ce champs. Utilis dans les champs foreign.key
  • Lors de l’exécution, il est possible de taper /Z dans un champs, si ce champs est une clé sur un autre fichier, le programme essaye de déterminer ce fichier au travers du nom du champs si il n’y arrive pas, il essaye de trouver dans le ‘Full Description’ une ligne qui commence par Z: à la suite du ”:“ doit se trouver le file_name sur lequel on peut zoomer. ou le process Z:P:process

• SQL: Les qualifiants SQL de ce champs.
  • Dans le cadre de la SQLisation des tables pick, certain qualifiants peuvent être ajouté à la définition de base du champs. Type SQL = CHAR, DATE, DECIMAL, DOUBLE PRECISION, FLOAT, INTEGER, NUMERIC, REAL, SMALLINT, TIME, VARCHAR
  • sugg : un tool qui va (si c’est un champs physique) demander cette valeur à l’enregistrement du /FD pour l’y placer et maintenir le @SELECT nécéssaire à ODBC.
  • sugg : un tool qui va maintenir le Dictionnaire Universe att<8> avec le type,taille SQL.

Les propriétés Gui ‘spéciales’ de ce champs. Dans le cadre de la Guitization d’un écran, il est affecté à un champs des propriétés gui de base issues du GDS, on peut ajouter ou modifier ces propriétés.

Développeement du dictionnaire au format de la plateforme (UV,…)

Dans un écran SB+ la méthode pour saisir des enregistrements dont la clé est composée de plusieurs valeurs est toujours la même.

Les différentes saisies des différentes valeurs des composantes de la clé se font distinctement sur la variable @WORK

Les champs qui la composent sont définis individuellement en physique et en work dans le global field definition.

en physique, le nom GLB.fff.x(6) référence une dérivée de la clé (<0>“Gn#1”), “n” étant le nombre de segment à sauter pour extraire la data depuis la clé, ce champs sera exploité dans les sélections et les reports.

en work, le nom GLB.fff.W.x(6) référence la saisie dans les écrans dans la variable @WORK<n> selon le datafile utilisé, un champ de clé composée peut être une fois en première position, deuxième,… sa saisie n’en reste pas moins la même.

Cette technique permet de sélectionner, valider chaque composant individuellement.

En début d’écran en BFS on aura un A.INIT.WORK (@WORK=”“)

Sur le dernier composant de clé, on aura la connective ‘R’ pour dire que c’est le dernier champs qui compose la clé. En process after de ce champ on aura un A.fff.KEY (@Key=W1 :_S :W2 :_S….)

Une fois les champs créés : on lance un /EQUATES pour maintenir dans xxINCLUDE les equates pour tous les fichiers au format $Fxx.filename.

L’écran principal porte toujours le nom INPUT.

Le process INPUT de base d'un fichier sera rp*Fsy.fff*INPUT, dans le but de permettre un zoom automatique sans paramètres. Exemple:

• le signalétique client : I*Fsy.CLI*INPUT
• la facture : I*Fsy.FAC*INPUT

Si des sous-écrans seront appelés depuis l’écran principal, ils devront être construits de cette manière : nom de l’écran principal.XXX. Ex. :l’écran principal s’appelle INPUT.

• Il appelle un sous-écran : INPUT.ART.
• Il est possible d’avoir plusieurs séries de 3 lettres séparées par un point.

En principe, c'est SB+ qui gère le readU, et le WRITE dans uen séquence classique.

Dans certains cas, nous déciderons de ne pas laisser SB gérer les locks. Pour ce faire, voici ce qu'il y a à savoir :

Placer les options RN (au niveau Control/Dep/Read) sur le champs qui doit déclencher la lecture (clef de l'écran ou dernière partie d'une multi-part key).

Nous ne laissons pas SB+ écrire l'enregistrement. C'est donc à nous d'assurer les mise-à-jour db. Nous placerons donc, dans chaque afa, l'appel au process P.REC.WRT.

On doit placer impérativement une série de process même s’il ne font rien.

x.fff.screename.step

Si le process est appelé spécifiquement dans un écran, à un step particulier :

• BFS Before screen : doit appeler GP.BFS,
• AFD After display : doit appeler GP.AFD,
• AFR After read record : doit appeler GP.AFR,
• AFA After accept (<F2> pressed) : doit appeler GP.AFA,
• AFU After Update (record writed on mainfile,key by SB+) : doit appeler GP.AFU,
• AFE After Escape (<ESC>, <Ctrl-X> pressed) : doit appeler GP.AFE,

• Ces process peuvent être appelés depuis un process global (externe).
• Si il n’est pas présent, l’application qui a fait l’appel sera arrêté.
• L’écran doit contenir ces 6 process : même s’ils ne font rien, ils doivent être présent avec au moins EXIT 0.

Il faut créer le menu M.fff.screenname.SUB ; voir a utiliser le P.BUILD.MENU/P.ERASE.MENU

Les touches de fonctions seront :

Le process PD.I fera appel au process After READ standard (à définir en template GP.AFA)

After Accept Sandard ( à définir en template GP.AFA)

Le report LIST doit être créé pour chaque fichier.

On crée, un report LIST pour chaque fichier.

• 1H head a78 : _R.HEADING, centré (c’est une equate qui reprend le nom de la société)
• 3H titre a78 : p(« A.R.TITRE »), centré (process qui résupère le nom du report)
• 5H GLB.CRITÉRIA (c’est champ global qui reprend les critères de sélection entrés pour pou obtnir le résulta de la liste)
• 6H : ligne
• 7C : les champs
• 8C : lignes
• 9D : field
• 10F : ligne
• 11F : p(«A.R.FOOT ») (process global qui reprend le numéro de page la date, heure et la personne qui a réalisé l’impression)

Liste des outils globaux

Dans certains cas d’écran très usuels, nous développerons en GUI Only.

Fixer les propriétés gui telle que :

<f6><f6> dans l’écran SD :

• Link Char = Guil Only
• Func Keys = Vertical
• Gui Presentation = vide
• Tab Linked = vide (sinon le nom de l’onglet
• Gui Click MENU = M.xx….SUB
• Gui ClickProcess = vide

Par la suite, il ne faudra plus revenir dans cet écran sous peine de devoir redéfinir les propriétés de base de la form (dimension et fctkeys coordinates)

SB+ crée la form de base avec les touches de fct à droite.

Fixer la propriété Dimensions de la form à 980;620

Menu > Options

• Fixer grid dimensions à 10,10
• Fixer le showgrid (il montre des petits points)
• Fixer le snap grid (il alignera automatiqument les objets sur la grille) ; les objets se déplace par pas de 10 points

Menu Window

• Garder Speed bar
• Garder Properties
• Garder Object Palette

Sélectionner les touches de fonctions avec la souris pour tout sélectionner d’un coup et grouper les par Ctrl-G

Pour ensuite les déplacer au bon endroit (900 ;10) pour la lignes verticale – dimension 2 ;610 pour la ligne verticale

• Mettre l’option Link Char and GUI Field Positions à Non
• Aller sur le dernier champ du tableau et le mettre le plus à droite
• Cliquer sur le bas du champ contrôlant pour descendre le plus bas possible.
• Enregistrer puis quitter et entrer dans l’écran en mode traitement et l’écran sera redimensionné.
• Ajuster les colonnes ” avec souris + dblclik“ dans le “blanc”

Faire attention à la taille lors de la saisie. Tout les cas doivent tenir dans la boite de présentation que cela soit en hauteur et largeur même en mode saisie.

Penser à homogénéiser les champs d’encodage.

Exemple :

• Code département sur 5 caractères et code éditeur responsable sur 15 caractères.
• Passer les deux champs sur 15 dans l’écran laisser de la place devant les libellés et les aligner puis mettre le code et le libellé des champs.

• Mettre la clef d’identifiant dans tous les onglets.
• Dans le premier en saisie et les autres en visualisation.
• Mettre le processus AFA ,AFU,AFE que sur le dernier onglet.
• Mettre les processus BFS,AFR,AFD dans le premier onglet.
• Mettre le write yes sur tous les onglets.

Lancer l’aide de 2éme niveau et vérifier les textes.

— Pascal Pontoise 12/02/2013 08:06

• Accès : /INTOOLS,Outil Développeurs, Création structure base
• Points abordés :
  • 1 Création du fichier
  • 2 Création processus
  • 3 Création champ clef
  • 4 Création stamp
  • 5 Création lib
  • 6 création écran input
  • 7 Création gp.sel.fic / sélection
  • 8 Création validation
  • 9 Report LIST
  • 10 equates
  • 11 génération STT

Lire le détail ...

• Utilisation des equates de fichiers de base décaler de 20 positions.Exemple personne timix+
• Utilisation des processus suivants nécessité.
  • GP.BDG.SCR
  • B.WRITE.AFA.AFU

• Pensez à structurer les selfic. Voir les 3 images ci-après
• Générales :
  • Select : libellé code
  • Sort Field GLB.LBL.LGE GLB.PAR.HIE.CODE
  • Display Field GLB.PAR.HIE.CODE GLB.LBL.LGE GLB.SEQ.NUM
  • Option ETFP

• Addit descripteur supplémentaire :
• delete
• code
• libellé

• Addit process particulier
  • Zoom.