Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Programmation : C - OpenTags
(Article écrit par Olivier Jeannet et extrait d'Amiga News - juin 1994)
|
|
Le système 2.0 a apporté une technique bien pratique pour la programmation :
les marqueurs ("tags"). L'ouverture des écrans et des fenêtres, ainsi qu'un certain nombre
d'autres opérations s'en trouvent bien facilitées.
Les deux bibliothèques de fonctions (library en anglais) de l'Amiga qui sont les
plus "visibles" pour l'utilisateur s'appellent "Graphics" et "Intuition". La première
s'occupe de toute la gestion du graphisme à bas niveau, tel que tracé de lignes,
remplissage de formes ou type de résolution de l'écran. La seconde s'occupe de la
gestion des écrans et des fenêtres à un niveau plus élevé, ainsi que des gadgets,
des menus et des événements souris.
La bibliothèque Intuition permet d'ouvrir facilement des écrans et des fenêtres, et
de construire de superbes programmes pleins de fenêtres, de menus et de gadgets.
Nous allons nous intéresser à la bibliothèque Intuition, et aux améliorations qui
y ont été apportées avec le système 2.0.
Parenthèse : "V36" désigne les premières versions (boguées) du système 2.0, et
le 2.04 (version définitive) est appelé "V37".
En système 1.3
Programmer l'ouverture d'une fenêtre avec le système 1.3 n'était pas simple. La fonction de
la bibliothèque Intuition qui permet d'ouvrir une fenêtre s'appelle "OpenWindow",
et son prototype en C est :
struct Window *OpenWindow( struct NewWindow *)
|
Autrement dit, elle prend en argument un pointeur sur une structure NewWindow
(voir listing 1) et retourne un pointeur sur une structure Window. Avant d'appeler
la fonction OpenWindow, on devait remplir soigneusement une structure NewWindow, en
précisant les valeurs pour chaque champ. En général, il fallait regarder la documentation pour
se souvenir dans quel champ se spécifiait telle ou telle caractéristique. Par exemple, pour
que la fenêtre comporte un gadget de fermeture, on spécifiait dans le champ "Flags" (drapeaux)
la valeur "WINDOWCLOSE", et pour être informé du clic sur le gadget de fermeture on
spécifiait dans le champ "IDCMPFlags" la valeur "CLOSEWINDOW" (notez la subtile inversion
du mot !).
Ces valeurs sont des constantes numériques, presque toujours codées sur un mot
long (32 bits), et définies dans les fichiers include livrés avec le compilateur.
Avec le 2.0, les noms ont été remaniés pour être plus clairs, comme nous le verrons
plus loin. Le listing 2 montre l'ouverture d'une fenêtre en 1.3.
La plupart des champs sont optionnels, en particulier les champs de structure.
Les champs de structure comme CheckMark et BitMap sont souvent inutilisés, donc
laissés à zéro. CheckMark à zéro signifie qu'on obtiendra l'image standard,
et BitMap à zéro signifie qu'on n'utilise pas de BitMap spécial. Voici un exemple des valeurs
que l'on spécifie dans la structure NewWindow :
Ces valeurs se précisent indépendamment, en faisant un OU logique (le signe "|" en C)
de ces différentes valeurs.
Pour ouvrir un écran, on procède de façon similaire, en remplaçant la structure NewWindow
par une structure NewScreen, sauf qu'un écran ne peut recevoir d'événements.
En général, quand on ouvre un écran, c'est pour ouvrir une fenêtre dessus,
donc ça ne pose pas de problèmes. Nous verrons plus loin comment ouvrir un écran et une fenêtre.
Maintenant en système 2.0
Avec le système 2.0 sont apparus les "tags". On peut traduire "tag" par marqueur,
et ces marqueurs permettent de spécifier une liste de paramètres, au lieu de remplir
une structure. Les marqueurs servent aussi à demander les propriétés d'un objet. En pratique,
ils sont utilisés en tableaux ou en chaînes de tableaux. Voici la définition de la structure
TagItem :
Comme il a été dit plus haut, les valeurs à mettre dans les champs Flags et IDCMPFlags
ont été renommées avec le 2.0 de façon à être plus distinctes. Les valeurs pour les
drapeaux ont le préfixe "WFLG_", les IDCMPFlags ont le préfixe "IDCMP_".
D'autres types de valeurs ont aussi été renommés, comme ceux utilisés avec les gadgets,
évitant la confusion. Ainsi, pour les valeurs IDCMP, NEWSIZE devient "IDCMP_NEWSIZE"
et CLOSEWINDOW devient "IDCMP_CLOSEWINDOW".
Pour les drapeaux, WINDOWCLOSE devient "WFLG_CLOSEGADGET" et RMBTRAP devient "WFLG_RMBTRAP".
Le 2.0 apporte également les marqueurs booléens. Pour préciser des drapeaux avec les marqueurs,
on peut soit imiter la méthode classique avec un couple (WA_Flags, WFLG_RMBTRAP |
WFLG_DRAGBAR), soit utiliser les couples (WA_RMBTrap, TRUE) et (WA_DragBar, TRUE).
Les marqueurs utilisés par OpenWindowTags sont préfixés par "WA_", ceux utilisés par
OpenScreenTags sont préfixés par "SA_".
Il existe une manière d'utiliser les marqueurs qui est compatible avec le système 1.3,
tout en utilisant des possibilités du 2.0. On utilise pour cela la structure ExtNewWindow,
qui est une structure NewWindow augmentée d'un champ appelé Extension, qui pointe sur
une structure TagItem. On remplit une structure TagItem ; on fait pointer le champ
Extension vers cette structure, on précise dans le champ "Flags" la valeur NW_EXTENDED,
et on peut appeler la fonction OpenWindow (avec un pointeur sur la structure ExtNewWindow).
Avec le système 1.3, le drapeau NW_EXTENDED sera ignoré ainsi que le champ Extension,
donc seule la structure NewWindow proprement dite sera prise en compte. Avec le système 2.0,
le drapeau NW_EXTENDED va indiquer qu'il s'agit d'une structure étendue, et la structure TagItem
sera prise en compte, permettant ainsi d'avoir des caractéristiques en plus par rapport au
1.3, propres au 2.0. Le 2.0 permet par exemple d'être informé du pressage de la touche
"Help" pendant que les menus sont affichés, ce qui est très pratique pour l'aide en ligne
comme AmigaGuide.
Cette méthode est pratique du point de vue de la compatibilité, mais n'apporte pas beaucoup
de simplicité. Voyons à présent la puissance et la simplicité apportées par les marqueurs.
Avec les marqueurs sont apparues des fonctions qui les utilisent, et une de ces fonctions qui
nous intéresse est la fonction OpenWindowTagList. Son prototype en est :
struct Window *OpenWindowTagList( struct NewWindow *, struct TagItem *)
|
A priori, rien de nouveau par rapport à la méthode expliquée au paragraphe précédent : une
structure NewWindow et une structure TagItem à remplir. En fait, l'intérêt de cette méthode
est que la structure NewWindow est optionnelle (on peut mettre NULL), et on peut se contenter
de spécifier avec les marqueurs ce que l'on veut. Des valeurs par défaut seront donc utilisées,
et seront supplantées par les marqueurs. On peut même ne spécifier aucun marqueur et le système assure de
se retrouver avec une fenêtre "raisonnable", sur le Workbench ou sur l'écran public par défaut.
Voilà qui est pratique !
Il existe une manière plus pratique encore d'utiliser les marqueurs : la fonction OpenWindowTags.
C'est la même fonction que OpenWindowTagList, à la différence qu'elle accepte un nombre
variable d'arguments. Son prototype est :
struct Window *OpenWindowTags( struct NewWindow *, ULONG, ...)
|
On peut donc se passer d'allouer une structure TagItem, le compilateur se charge d'empiler
les marqueurs et de créer ainsi une structure TagItem sur la pile avant l'appel de la
fonction. C'est en utilisant cette forme que nous allons écrire nos programmes dorénavant.
Pour donner une idée de ce qu'on obtient quand on ne précise aucune valeur, voici un
programme minimal (on ne teste rien, c'est vraiment le minimum !).
Sur mon A1200, avec un Workbench en haute résolution 640x256, le programme précédent
ouvre un écran en basse résolution 320x256x1 (monochrome), et sur cet écran une fenêtre
qui prend tout l'écran, sans titre et comportant seulement un gadget de fermeture. Pour
que la fenêtre ait une hauteur de 150, il suffit d'ajouter (n'importe où) dans l'appel
OpenWindowTags les valeurs suivantes : "WA_Height, 150," et le tour est joué.
Voici à présent le programme final, l'ouverture d'un écran et d'une fenêtre en 2.0, avec les marqueurs.
En conclusion
Grâce aux marqueurs, on dispose d'une méthode pratique et facile pour ouvrir des écrans et
des fenêtres, ainsi que pour utiliser d'autres bibliothèques qu'Intuition, par exemple la
gadtools.library ainsi que l'asl.library. De plus, Commodore recommande d'utiliser les
marqieurs pour la compatibilité future des applications. En effet, en utilisant les marqueurs,
les fonctions ne dépendent plus de structures rigides et figées, il suffit de créer de
nouveaux marqueurs pour avoir de nouvelles possibilités. Comme les marqueurs sont codés sur des
ULONG (ti_Tag et ti_Data), les possibilités sont énormes (plusieurs milliards) !
On peut enfin mentionner d'autres possibilités apportées par le 2.0, comme les écrans publics
et les fenêtres visiteuses. Un écran public est un écran sur lequel peuvent s'ouvrir des
fenêtres appartenant à d'autres applications que celle qui a ouvert l'écran. Le système permet
d'ouvrir ces fenêtres, appelées visiteuses, de manière simple. On définit en général un
écran public par son titre. Le Workbench est lui-même un écran public, et un certain nombre
de programmes du domaine public ouvrent des écrans publics, comme les logiciels de communication
Term et VLT. Un écran public ne peut être fermé tant que toutes les fenêtres visiteuses
n'ont pas été fermées. On peut aussi définir un écran public comme étant SHANGAI :
les fenêtres qui devraient s'ouvrir sur le Workbench vont s'ouvrir sur cet écran.
Pour ouvrir un écran public, on spécifie la valeur "PUBLICSCREEN" comme type d'écran.
Pour trouver l'adresse d'un écran public, on utilise la fonction "LockPubScreen",
dont voici le prototype :
struct Screen *LockPubScreen( UBYTE *)
|
Cette fonction prend un nom en argument, et retourne l'adresse de l'écran.
Cette fonction permet non seulement de trouver l'adresse d'un écran, mais en plus d'empêcher
sa fermeture, par exemple le temps d'y ouvrir la fenêtre visiteuse.
Voici un exemple simplifié d'ouverture de fenêtre visiteuse :
Après ce petit panorama des nouvelles possibilités du 2.0, nous allons vous parler
prochainement de la programmation d'autres améliorations du système, comme les AppIcons et AppWindows.
|
