Obligement - L'Amiga au maximum

Vendredi 17 novembre 2017 - 22:18  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

 · Accueil
 · A Propos
 · Articles
 · Galeries
 · Glossaire
 · Hit Parade
 · Liens
 · Liste jeux Amiga
 · Quizz
 · Téléchargements
 · Trucs et astuces


Articles

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

 · Articles in english
 · Articles in other languages


Twitter

Suivez-nous sur Twitter




Liens

 · Sites de téléchargements
 · Associations
 · Pages Personnelles
 · Moteurs de recherche
 · Pages de liens
 · Constructeurs matériels
 · Matériel
 · Autres sites de matériel
 · Réparateurs
 · Revendeurs
 · Presse et médias
 · Programmation
 · Développeurs logiciels
 · Logiciels
 · Développeurs de jeux
 · Jeux
 · Autres sites de jeux
 · Scène démo
 · Divers
 · Informatique générale


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


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


Partenaires

Annuaire Amiga

Amedia Computer

Relec

Hit Parade


Contact

David Brunet

Courriel

 


Programmation : MUI - introduction aux classes personnalisées
(Article écrit par Jérôme Fleury extrait d'Amiga News - janvier 1997)


Introduction

Si vous êtes programmeur ou que vous vous intéressez aux applications utilisant MUI, vous savez probablement ce qu'est une Custom Class (classe personnalisée). Pour résumer, une application MUI se décompose en objets, chacun ayant sa propre fonction et ses propres attributs, les plus courants étant les boutons, les listes, etc., mais aussi (surtout) la fenêtre et l'application qui sont eux-mêmes des objets aux yeux de MUI.

Avant MUI 2.0, les programmeurs étaient limités à ces objets internes à MUI pour construire leurs applications, ce qui pouvait être frustrant pour certaines applications, par exemple imaginez une fenêtre dans laquelle l'utilisateur peut dessiner avec la souris. MUI n'offre pas un tel objet, et avant MUI 2.0, il était donc impossible pour le programmeur de placer un tel objet dans son application. Mais aujourd'hui, avec les classes personnalisées, cela devient presque un jeu d'enfant. Vous l'aurez compris, une classe personnalisée permet de créer sa propre classe d'objet.

La programmation de classe personnalisée était jusque-là encore marginalisée car jugée peu utile pour une application simple. Mais l'arrivée, avec MUI 3.0, de la notion de "Drag & Drop" ("Glisser et Déposer") a rendu obligatoire l'écriture de classe personnalisée pour le programmeur qui veut utiliser cette nouvelle possibilité dans son application, vous verrez pourquoi.

Description

L'écriture d'une classe personnalisée ne nécessite pas de grandes connaissances en programmation, elle impose par contre de suivre des règles strictes dans son élaboration. Je vais essayer avec un exemple concret, de vous expliquer les rudiments de la programmation objet et de la création de vos propres objets.

Pour le programmeur, il peut être intéressant de distinguer deux types de classes personnalisées : celles issues d'objets standards MUI comme les boutons, les cellules de saisie, les listes, etc., auxquelles on ajoutera des attributs et des fonctionnalités divers (comme par exemple le glisser & déposer), et celles issues de la classe Area, qui est la classe parente de tous les objets MUI. Les premières sont faciles à mettre en oeuvre, les secondes sont plus difficiles. Nous commencerons évidemment par les premières.

Une classe personnalisée est composée de trois éléments essentiels:
  • La SuperClass : c'est la classe à laquelle votre objet appartient, ainsi il deviendra une sous-classe de la SuperClass.
  • Le Dispatcher : comme son nom l'indique, il s'agit d'une fonction dont le rôle est de distribuer les différentes "actions" (appelées "Methods") appliquées sur votre objet vers d'autres fonctions.
  • L'Instance Data : il s'agit d'une structure qui contient... ce que vou voulez :-). Cette structure pourra vous servir par exemple pour stocker les attributs actuels de votre objet. Nous verrons son importance capitale.
Voyons comment tout ça s'articule. Pour ça, je vous propose un petit programme d'exemple qui contient deux classes personnalisées. La première est un bouton situé dans une fenêtre principale qui ouvre une autre fenêtre lorsqu'on clique dessus, cette nouvelle fenêtre étant elle même une classe personnalisée.

Pour bien comprendre la notion d'"objet" il faut voir que notre bouton est bien plus qu'un simple bouton. Si nous devions décrire notre objet en une phrase cela donnerait : "Objet de type bouton dont le rôle est de s'occuper de l'ouverture et de la fermeture de fenêtres". Car comme on peut le voir dans le source, notre classe prend en charge aussi bien l'ouverture que la fermeture des fenêtres, même si visuellement rien ne nous le laisse deviner. Notez bien également que la création d'un tel objet permet l'ouverture illimitée de fenêtres simultanément, sans que leur fermeture pose un quelconque problème.

Identifions maintenant les éléments principaux de nos deux classes personnalisées :

La SuperClass de notre objet "Bouton" est la classe "Text", en effet, il n'y a pas à proprement parler de classe "Bouton" dans MUI. Un bouton n'est en fait qu'un objet "Text" disposant de certains attributs. Quant à notre objet fenêtre, sa SuperClass est bien entendu la classe "Window".

Le Dispatcher de notre objet "Bouton" s'occupe de trois fonctions propres à notre objet : sa création (méthode OM_NEW), l'ouverture d'une fenêtre (MUIM_Button_NewWindow) et sa fermeture (MUIM_Button_Finish). Quant à notre objet "Fenêtre" nous n'avons qu'à nous préoccuper de sa création via la méthode OM_NEW.

L'Instance Data de notre objet "Bouton" est vide car nous n'en avons pas besoin. Toutefois, il est obligatoire d'en avoir une pour créer la classe personnalisée, ce qui explique le pointeur "dummy" qu'elle contient. Notre objet "Fenêtre" possède lui un Instance Data qui contient un pointeur sur notre objet "Bouton". Nous nous servons de ce pointeur lors de la fermeture de la fenêtre. En effet, nous devons communiquer avec l'objet "Bouton" pour lui indiquer de fermer cette fenêtre, par conséquent nous devons avoir son adresse.

Vous noterez qu'un grand nombre de fonctions utilisées proviennent directement du système BOOPSI sur lequel MUI se base presque entièrement. Je vois renvoie donc aux autodocs de l'amiga.lib pour comprendre leur fonctionnement et leur utilisation. A noter qu'un grand nombre de documentations sur BOOPSI sont dorénavant disponibles sur le CD Développeur d'Amiga Technologies.

Conclusion

La place me manque pour vous expliquer tout ce qui concerne les classes personnalisées avec MUI. Citons notamment le problème des sous-classes de Area qui sont les plus ardues à mettre en oeuvre mais qui permettent d'envisager les objets les plus intéressants. D'autre part, j'aurais aimé vous parler de la gestion des attributs (les fameux MUIA_) via les Method OM_SET et OM_GET. Enfin, si vous avez complètement assimilé la création de classes personnalisées privées, rien ne vous empêchera plus d'en créer des publiques (comme Listtree.mcc et Busy.mcc fournies avec MUI 3) qui seront utilisables par tous. Mais cela c'est une autre histoire...

Code source

MUI
MUI
MUI
MUI


[Retour en haut] / [Retour aux articles]