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 : 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 standard
MUI comme les boutons, les cellules de saisie, les listes, etc., auxquelles on ajoutera des attributs et des fonctionnalités
divers (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 de "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
|
