DominoArea.org [Archive]

Il y a aussi un autre aspect qu'il ne faut pas négliger : la répétition de DbLookup pour la même valeur de retour.

Il m'est arrivé souvent de visualiser des masques contenants plusieurs DbLookup pour une valeur identique, genre le type de monnaie : euro, usd, can, sterling. Si un masque contient plusieurs valeurs monétaires et qu'il faut préciser à chaque fois la valeur via un DbLookup, il est préférable de les mutualiser. Pour cela, tu crées un champ caché calculé à l'affichage qui exécute le DbLookup et tous les champs qui ont besoin de cette valeur pointe sur ce champ.

J'ai fait du menage dans mes dblookup, et j'ameliore mon tps d'accès !!
Par contre, dans la structure d'un masque, par défaut il existe dans lal iste des objets celui de "[global]", peux-tu me dire à quoi cela sert ??

ce sont des objet qui sont accessible par tous les evenement du masque et des boutons contenue dans ce masque

La partie "Globale" permet de définir des variables LS en accès globales.

Selon les points de vue des gens, il y en a qui ne jure que par ce type de déclaration dans leur programmation, d'autre, comme moi, on a tendance en faire le moins possible à cet endroit. Si tu n'es pas habitué, ça devient rapidement casse pied lorsque tu en fais la maintenance; d'autre disent que ça leur facilite la vie. L'argument qui ressort à chaque fois est : ça évite de passer les variables en paramètre.

mon avis sur le global
on doit trouver des variables génériques que l'on doit pouvoir accéder ou valoriser à n'importe quel moment
tout mettre en global n'est pas la bonne solution
ce que doit peut trouver et doit trouver ce sont les objets du style
- notessession
- le hDbCurrent pour la base active
- hView quand on a besoin d'une vue à la volée;;;
- hdoc idem que pour hview
- huiworkspace

- constantes génériques et moi pour cela j'utilise un lib réservée à mes constantes qui est appelée dans les autres lib
- dans ces constantes on retrouve les noms de champs des masques et ainsi dans l'application ou fonction j'utilse toujours les noms de champs en passant par ces constantes ; pas de nom de champs en dur... à éviter -> casse pied à la conception mais gain de temps dans la maintenance si un champ venait à changer de nom

et les variables génériques spécifiques à la l'application
ensuite le spécifique doit être passé en paramètre selon le contexte de la fonction

ensuite on commence toujours par un bonne procédure du style
Call p_INITSESSION dans la laquelle on va initialiser la session et la base active
si l'application a besoin en permanence l'accès à des vues on peut aussi les avoir en paramètres globaux et dans ce cas pINITSESSION fera appel à une fonction qui va instancier les vues....

c'est un peu ma manière de développer