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 : Assembleur - exploitation des types d'outils
(Article écrit par Frédéric Delacroix et extrait d'Amiga News - juin 1994)
|
|
Je vous propose ce mois-ci une méthode, assez optimisée, pour exploiter les arguments
passés à une commande. Nous ne nous attarderons pas cette fois-ci sur l'utilisation du
CLI et de la puissante fonction ReadArgs(), mais plutôt à l'utilisation - plus rare sans doute -
des types d'outils (tooltypes), aussi bien à partir du Worbench que du CLI (ou Shell, c'est pareil).
Les fichiers icônes
C'est bien connu maintenant, pour afficher une icône associée à un fichier,
le Workbench a besoin d'un fichier ".info" correspondant, contenant des informations
sur l'objet à afficher. Ce n'est plus vrai à partir du Kickstart 2.0 grâce à l'option
"Show all files", mais c'est un cas particulier que nous laissons de côté.
Nous laissons également de côté les fichiers nommés ".info" tout court que l'on
pouvait rencontrer jadis, au temps du Kickstart 1.3, qui semblaient contenir le
listing du répertoire concerné, et qui ont depuis disparu de nos contrées.
Voyons donc le contenu d'un fichier icône. Il s'agit en réalité principalement d'une
structure DiskObject, définie dans le fichier include workbench/workbench.[hi] :
La manière dont ces informations sont réellement stockées dans le fichier n'est pas
documentée et risque de changer dans des versions ultérieures du système. En conséquence,
l'accès aux fichiers icônes doit toujours se faire par l'intermédiaire de l'icon.library.
Cette bibliothèque possède par ailleurs quelques fonctions comme FindToolType()
ou FreeFreeList() qui sont très utiles dans certains cas.
Le cas qui nous intéresse
Nous voulons savoir si tel ou tel type d'outils
a été spécifié par l'utilisateur. Pour cela, il faut évidemment d'abord obtenir
la structure DiskObject. Pour ce faire, l'icon.library (sur disque jusqu'au Kickstart 1.3,
en ROM depuis), propose la fonction GetDiskObject(), à laquelle on fournit en
A0 le nom de l'icône à charger (sans le suffixe ".info"). On obtient en retour
la structure DiskObject correspondante. ou "0" s'il n'en existe pas, ou si une erreur
est survenue pendant le chargement (dans ce cas IoErr() en donne la cause).
Le premier problème se pose : comment savoir quelle icône charger ?
Cela dépend surtout de ce que l'on veut faire. En général, il suffit de charger
l'icône du programme lui-même, mais il peut s'avérer nécessaire par exemple pour
un programme lancé à partir du Workbench par une sélection multiple, d'examiner
toutes les icônes sélectionnées. Là, c'est le programmeur qui décide.
En général, un programme lancé à partir du Workbench examine le premier ou le
deuxième argument donné par la structure WBStartup reçue en début d'exécution à
son port de message. En général, il vaut mieux s'intéresser au second, étant donné
que cela signifie que l'utilisateur a soit fait une sélection multiple (grâce à la
touche "Shift") ou cliqué sur une icône projet dont l'outil par défaut était le
programme en cours d'exécution. Dans le premier cas, les arguments sont envoyés au
programme dans l'ordre de la sélection : dans le second, c'est l'icône de l'outil
par défaut en premier, puis l'icône projet qui a été cliquée.
Un programme lancé à partir du CLI a la tâche plus difficile, surtout si on n'utilise
pas le Kickstart 2.0. Il s'agit pour lui de trouver d'où il vient, c'est-à-dire son
répertoire (à priori, ce n'est pas le même que le répertoire courant) et l'exécutable.
Le Kickstart 2.0 rend les choses assez simples grâce aux fonctions GetProgramDir()
et GetProgramName() de la dos.library, évitant ainsi quelques migraines à se plonger dans
les pointeurs BCPL. Il suffit alors d'aller chercher l'icône grâce à l'icon.library.
A noter qu'il peut être judicieux de prévoir également le passage d'arguments par le
CLI, ces arguments surpassant alors ceux donnés en type d'outils. Il suffit alors d'examiner
l'icône de la façon la plus classique, à grand renfort de FindToolType() et MatchToolValue().
Un exemple !
Le programme que je vous propose ce mois-ci affiche tous les types d'outils d'une
icône dans la fenêtre du CLI, ou dans une fenêtre CON: si invoqué à partir du Workbench.
A partir du CLI, il se contente d'afficher les types d'outils de son icône à lui,
et à partir du Workbench affiche ses types d'outils, ou ceux du second argument s'il y en
a un. Il y a deux façons de donner un deuxième argument : soit cliquer sur l'icône du
programme puis "Shift-double-cliquer" sur l'icône à examiner, soit utiliser une icône
de type projet dont l'outil par défaut est le programme dont le listing suit.
J'oubliais : ce programme ne marche que sur Kickstart 2.04 et supérieur.
En guise de conclusion
Une dernière chose : lorsqu'un de vos programmes crée une icône projet,
il est de bon aloi de régler le bon outil par défaut. Ceci se fait, si on
vient du CLI, en réservant deux espaces contigus sur la pile (ou ailleurs,
mais la pile c'est bien pratique). Dans l'un on met le chemin du programme grâce
à GetProgramDir() et NameFromLock(), dans l'autre on y met le nom du programme
obtenu par GetProgramName(), et on réunit le tout dans le premier tampon mémoire
grâce à AddPart(). Il reste alors à mettre dans le champ do_DefaultTool de la
structure DiskObject le pointeur sur le tampon mémoire et à sauvegarder l'icône.
|
