Le DDS

contrôle de sous-fichier pour le sous-fichier
à  droite de l’écran ; cet enregistrement
définit aussi la fenêtre dans laquelle
il se trouve. WDWTITLE est
utilisé pour donner quelques attributions
aux touches de fonction en bas
de la fenêtre, mais observez qu’il n’y a
pas de touches de fonction définies sur
ce format, pas plus que de champ acceptant
des entrées.
#4SFL est le sous-fichier associé ; il
a un champ caché contenant le numéro
du client. Ce format n’a pas non
plus de champs d’entrée, mais il a un
indicateur pour contrôler le mot-clé
HIGHLIGHT. Le manque de champs
d’entrée et de touches de fonction
s’explique parce que la fenêtre est en
sortie seulement avec un WRITE. Il n’y
a pas de EXFMT associé ; c’est le programme,
et pas l’utilisateur, qui
contrôle ce que fait la fenêtre.
#3CTL et #2SFL sont le contrôle
de sous-fichier et le sous-fichier pour la
fenêtre à  gauche de l’écran. Ils ressemblent
beaucoup à  #5CTL et #4SFL en
ce qu’il n’y a pas de champs d’entrée
ou de touches de fonction
attribuées. Là  encore, c’est le programme,
et pas l’utilisateur, qui
contrôle.
Si vous regardez les paramètres de
ces deux fenêtres, vous constaterez
qu’elles se chevauchent légèrement.
Le but est de maximiser la largeur des fenêtres pour les données (en n’ayant
qu’une ligne descendante au centre de
l’écran).
Le premier format, #1WND, est le
format de titre. Il a les attributions de
touches de fonction qui contrôlent le
fonctionnement du programme. A noter
que les touches de page sont définies
et utilisées comme n’importe
quelles autres touches de fonction ;
elles ne contrôlent pas les sous-fichiers
directement. (Je pourrais avoir choisi
une autre paire de touches de fonction,
mais au risque d’encombrer l’interface
utilisateur.)
Un dernier mot à  propos de ces fenêtres
: USRRSTDSP est défini dans
chacune d’elles. C’est pour empêcher
le système de sauvegarder les fenêtres ;
j’ai la maîtrise directe de ce qui se
passe dans le programme.