Obligement - L'Amiga au maximum

Mardi 23 avril 2024 - 20:27  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

Actualité (récente)
Actualité (archive)
Comparatifs
Dossiers
Entrevues
Matériel (tests)
Matériel (bidouilles)
Points de vue
En pratique
Programmation
Reportages
Quizz
Tests de jeux
Tests de logiciels
Tests de compilations
Trucs et astuces
Articles divers

Articles in english


Réseaux sociaux

Suivez-nous sur X




Liste des jeux Amiga

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


Trucs et astuces

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


Glossaire

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


Galeries

Menu des galeries

BD d'Amiga Spécial
Caricatures Dudai
Caricatures Jet d'ail
Diagrammes de Jay Miner
Images insolites
Fin de jeux (de A à E)
Fin de Jeux (de F à O)
Fin de jeux (de P à Z)
Galerie de Mike Dafunk
Logos d'Obligement
Pubs pour matériels
Systèmes d'exploitation
Trombinoscope Alchimie 7
Vidéos


Téléchargement

Documents
Jeux
Logiciels
Magazines
Divers


Liens

Associations
Jeux
Logiciels
Matériel
Magazines et médias
Pages personnelles
Réparateurs
Revendeurs
Scène démo
Sites de téléchargement
Divers


Partenaires

Annuaire Amiga

Amedia Computer

Relec


A Propos

A propos d'Obligement

A Propos


Contact

David Brunet

Courriel

 


Programmation : Assembleur - Réaction aux événements/messages d'Intuition
(Article écrit par Max et extrait d'Amiga News Tech - mai 1989)


Nous avons vu le mois dernier de quelle manière nous pouvions, grâce à Intuition, ouvrir de nouveaux écrans et de nouvelles fenêtres. En revanche, ce que l'on ne sait pas toujours, c'est comment l'on peut réagir aux différents événements qui peuvent survenir à chaque instant.

L'Amiga, c'est comme la Samaritaine : il s'y passe toujours quelque chose. Vous pensiez sans doute que déplacer une souris sur un bureau était une chose tout à fait anodine, que de dérouler un menu ne présentait aucune difficulté, ou encore que d'agrandir une fenêtre n'entraînait aucune conséquence particulière. Du point du vue utilisateur, vous aviez entièrement raison. Mais côté logiciel, même la plus petite action de votre part entraîne tout un chambardement du côté d'Intuition.

Les événements

Prenons un exemple tout simple : vous cliquez sur le bouton droit de votre souris pour faire apparaître la barre de menus, puis déplacez le pointeur jusqu'à cette barre afin d'en dérouler les options, choisissez celle qui vous convient, puis enfin relâchez le bouton pour valider. Temps maximal évalué : 2 à 3 secondes. Mais qu'a fait Intuition pendant ce temps-là ?

Il s'est d'abord rendu compte que vous aviez appuyé sur le bouton droit de la souris et en a prévenu le programme concerné (Workbench ou autre, par exemple Deluxe Paint). Il s'est ensuite chargé de vérifier si ce programme possédait bien un menu, et si oui, en a affiché les différents titres. Intuition a ensuite patiemment attendu que le pointeur de la souris arrive jusqu'à cette barre, en informant continuellement le programme de sa position (celle de la souris, pas de la barre). Puis, lorsque le pointeur est arrivé sur un titre, Intuition a affiché le menu correspondant, se chargeant de sélectionner les différentes options au fur et à mesure que vous déplacez la souris.

Enfin, lorsque le bouton a été relâché, Intuition a prévenu le programme, et si une option du menu a été choisie, lui a précisé de laquelle il s'agissait. Et comme c'est un travailleur très consciencieux, il a également fourni au programme, un rapport sur l'état du clavier et plein d'autres petites choses. Lorsqu'il a besoin de communiquer à un programme de tels événements, Intuition lui envoie ce que l'on appelle "un message", c'est-à-dire une suite d'octets structurés d'une manière particulière, contenant tous les renseignements nécessaires.

Les événements sont de différents types : ils peuvent concerner l'écran en général (appel d'un menu, action sur une fenêtre), le clavier (toutes appuyées ou au contraire relâchées), le(s) lecteur(s) de disquette (disquette éjectée, changée...), ou encore les différentes interfaces connectées à ce moment-là. Le cas qui nous intéresse est donc celui des fenêtres.

Fenêtre ou pas fenêtre...

Heureusement, comme nous l'avons vu le mois dernier, chaque programme est libre de définir, grâce aux drapeaux IDCMP lors de l'ouverture de la fenêtre, le type de messages qu'Intuition sera autorisé à lui envoyer. Le mot "fenêtre" doit être pris ici au sens large : il inclut les gadgets, fenêtres de requêtes, etc.

Concrètement, comment recevoir les messages d'Intuition ? Simple : il suffit d'appeler la fonction GetMsg (bibliothèque Exec, décalage -372) avec pour paramètre, l'adresse de la source de l'événement désiré dans a0. Késako, "source de l'événement correspondant" ? Encore une fois, c'est très simple : Intuition n'a aucun moyen de savoir, à priori, quel(s) événement(s) le programme désire tester, c'est pourquoi il nous faut lui préciser un truc du genre : "hé, ma jolie, j'ai ouvert une fenêtre et j'aimerais bien que tu me dises si on y a touché". En l'occurrence, où trouver cette adresse ? Rappelez-vous le mois dernier, nous avons sauvegardé, après l'appel de notre routine OpenW, un pointeur sur une structure Window, crée par la fonction OpenWindow. Cette structure n'a pas été détaillée, mais il vous suffit de savoir qu'au décalage 86 figure ce que l'on appelle "le port utilisateur" de notre fenêtre (en anglais : User Port). Et c'est justement ce port qu'il faut envoyer à la fonction GetMsg :

Assembleur

En retour, GetMsg renvoie dans d0, un pointeur sur une structure "Intuition Message", si un événement concernant notre fenêtre a eu lieu, sinon 0. Dans le premier cas, le mot long figurant à partir du 20e octet de cette structure contient le type de l'événement : ce ne sont ni plus ni moins que les drapeaux IDCMP, correctement positionnés (voir, encore une fois, le mois dernier). On le teste ainsi :

Assembleur

Les menus du père dodu

Un autre point important d'Intuition est les menus déroulants. Tout programme plus ou moins professionnel les utilise, d'une part parce que c'est un moyen simple, pratique et efficace de donner le choix à l'utilisateur entre plusieurs options, et d'autre part, parce que c'est nettement plus esthétique qu'un long texte du genre : 1 - Charger, 2 - Sauver, 3 - Quitter, etc. Mais l'on a rien sans rien et si la programmation et la gestion des menus sous Intuition ne présentent aucune difficulté particulière, elles sont assez longues à mettre en oeuvre.

Précisons d'abord un fait assez important : les menus sont reliés aux fenêtres qu'un écran donné contient, et non à cet écran lui-même. En d'autres termes, chaque fenêtre d'un écran peut avoir, si besoin est, son menu propre. Ce qui entraîne également une autre constatation : sans fenêtre, point de menu. Même si vous n'avez pas un besoin particulier d'une fenêtre, il vous faudra cependant en ouvrir une pour pouvoir disposer d'un menu, quitte à la déclarer de la même taille que l'écran, BORDERLESS (sans bords) et immobile.

Pour mettre en oeuvre un menu, on appelle la fonction SetMenuStrip (bibliothèque Intuition, décalage -264) qui n'attend que deux paramètres : dans a0, l'adresse de la structure du menu à activer et, dans a1, l'adresse de la structure Window de la fenêtre à laquelle le menu appartiendra. Elle ne renvoie aucun paramètre de retour. Voici un exemple d'appel de la fonction SetMenuStrip :

Assembleur

Mais la place me manque, il est temps de laisser la parole aux autres. Ce qui me permet de vous annoncer le contenu de notre prochaine leçon : dans un premier temps, la description d'une structure Menu et, dans un second temps, l'exploitation de ce menu et la réaction aux choix des options. A bientôt donc pour de nouvelles aventures.


[Retour en haut] / [Retour aux articles] [Article précédent] / [Article suivant]