COURS209.TXT/fr
Jump to navigation
Jump to search
******************************************************************
* *
* COURS D'ASSEMBLEUR 68000 SUR ATARI ST *
* *
* par Le Féroce Lapin (from 44E) *
* *
* Seconde série *
* *
* Cours numéro 9 *
******************************************************************
Ce petit cours va être un peu spécial, car il va fournir des indi-
cations sur la façon de réaliser des programmes GEM qui fonction-
nent correctement.
Il y a en effet quelques "trucs" à respecter. Sur MAC, les pro-
grammeurs ont à leur disposition des bouquins traitant de l'ergo-
nomie des logiciels. Qu'est ce que c'est ? Et bien c'est simple-
ment un ensemble de règles à respecter afin que l'utilisateur ne
soit pas perdu d'un programme à l'autre. Il faut en effet bien se
souvenir que vous êtes programmeur et que votre ouvrage sera uti-
lisé par des utilisateurs! Réfléchissons un peu: qu'est ce que
l'utilisateur recherche dans un programme de dessin:
1) avoir une sauvegarde de fichier compressé avec un algorithme
spécial, qui compresse plus que les copains.
2) avoir la possibilité de récupérer le plus facilement possible
ces dessins dans d'autres softs.
Il paraît évident que c'est la seconde solution qui est la bonne!
Pourtant nous assistons à une prolifération de formats de fi-
chiers, tous plus débiles les uns que les autres! Ah bien sûr, le
fichier compressé avec le logiciel de dessin Bidulmuche est plus
petit que le fichier issu de Degas, mais il n'est reconnu par per-
sonne! Pourquoi chercher à épater la galerie avec des nouveaux
formats ? Pourquoi ne pas charger et sauver en PI1, PI2, PI3, PC1,
PC2, PC3 et c'est tout ? Première règle: il faut donc penser à
l'utilisateur et ne pas chercher de trucs tordus! Le premier menu
c'est celui du copyright, le second celui des fichiers avec tout
en bas l'option Quitter. Quelle merde de devoir chercher l'option
Quitter tout au bout d'un menu parce que le programmeur a voulu se
distinguer!
De plus, par convention, les entrées de menus qui débouchent sur
un dialogue seront suivis de 3 points.
Pensez aux grands écrans et au TT !!!!! Lorsque vous tapez dans
des adresses système documentées, prévoyez un adressage sur 32
bits. Par exemple $FF8800 marchera sur ST mais plantera sur TT.
C'est en effet une adresse invalide si on cherche à s'en servir en
32 bits (avec le 68030). Il faut donc utiliser $FFFF8800 qui mar-
chera sur toutes les machines.
Ne testez pas la résolution avec Xbios4 ! C'est périlleux car, en
cas de grand écran, vous recevrez n'importe quoi! Pour l'ouverture
maxi d'un fenêtre, demandez au GEM la taille de la station de tra-
vail (voir le source avec la fenêtre). Une copie de blocs à faire
? Utilisez la fonction Vro_cpy, mais si c'est une copie avec
l'écran, il y a une solution simple: vous serez obliger de fabri-
quer une structure FDB (Form Definition Block). C'est une struc-
ture qui indique la largeur de la surface de travail, sa longueur,
le nombre de plans etc... Au lieu de demander au GEM toutes les
données, remplissez la de 0, et le GEM saura de lui même que vous
voulez parler de l'écran, et se débrouillera tout seul!
Pour vos accessoires, testez vos ressources en basse résolution!
Un accessoire, comme son nom l'indique doit être accessoire,
c'est-à-dire fonctionner sans gêner le reste de la machine : Pe-
tite taille (un accessoire de formatage de 100Ko hum!!!).
Un seul fichier ressource. Cela implique de ne pas utiliser de
dessins et de construire sa ressource avec l'option SNAP active
dans K_Ressource. Cette option permet d'avoir les boutons bien
placés quelle que soit la résolution d'utilisation de la res-
source. Si possible placez la ressource à l'intérieur de l'acces-
soire en la relogeant (voir listing de relocation ci-joint) cela
évite d'avoir plusieurs fichiers à manier quand on déplace les ac-
cessoires.
N'hésitez pas à mettre des raccourcis clavier dans vos ressources.
Si vous utilisez K Ressources vous verrez qu'il y a un accès à des
bits inutilisés pour les objets. En effet, si l'on prend, par
exemple, les bits définissant les flags de l'objet, on se rend
compte que seul les bits 0 à 8 sont utilisés. Or le codage est
fait sur un word, il nous reste donc 7 bits de libres. Ces bits
sont laissés au programmeur pour y stocker ce qu'il veut. A titre
indicatif voici ce que j'y mets:
Extended_type scan code de la touche de raccourci pour
cet objet.
Extended_flag Touche(s) devant être enfoncée simultanément pour
rendre ce raccourci valide.
Bit 15 -> Alternate
Bit 14 -> Control
Bit 13 -> Shift gauche
Bit 12 -> Shift droit
Bit 11 et 10 -> position du soulignement.
(0=pas de soulignement, 1=on souligne la première
lettre etc...)
Extended_state Indication de la musique sur un octet
associé à la sélection de cet objet
0 pas de musique
1 clochette
2-63 digits
64-127 Xbios(32)
128-190 son au format Gist
191-255 musique format Mad Max ou Musexx
Tout ceci me permet d'avoir des raccourcis clavier inscrits DANS
la ressource ce qui permet des modifications ultra-rapide. Pour
les raccourcis, il faut utiliser de préférence la touche Alter-
nate, car son utilisation avec un autre touche ne génère aucun ca-
ractère. Cependant, 6 raccourcis claviers utilisent Control. Ils
sont issus du MAC et ont tendance à se généraliser. Ces raccourcis
sont utilisés dans les formulaires avec champs éditables (entre
autres choses) afin de faire du couper/coller entre ces champs.
CONTROL X | pour couper (place en buffer en l'effaçant
| au préalable)
SHIFT CONTROL X | pour couper (mettre à la suite dans le buffer);
CONTROL C et | Comme avec X sauf que, dans le cas de X, le
SHIFT CONTRL C | champ éditable est effacé, alors qu'avec C, il
| conserve son contenu.
CONTROL V | colle le contenu du buffer en effaçant au
| préalable le champ éditable.
SHIFT CONTROL V | idem mais sans effacement du champ éditable.
Une autre remarque concernant les formulaires avec plusieurs en-
trées éditables: j'ai remarqué que par habitude l'utilisateur
tapait RETURN quand il avait fini de remplir un champ, et que,
souvent, le bouton ANNULER est mis en défaut: l'appui sur RETURN
donc, fait sortir du formulaire!
J'ai donc décidé de supprimer les boutons défaut lorsqu'il y a des
entrées éditables et de gérer différemment RETURN qui permet alors
de passer au champ éditable suivant (comme TAB).
J'ai également rajouté quelques autres touches. Alors qu'avec TAB,
il est possible de passer d'un champ éditable au suivant, j'ai
ajouté Shift+TAB pour remonter au champ éditable précédent.
CLR HOME permettant de revenir au premier champ éditable du formu-
laire. Il serait possible d'ajouter UNDO.
Ré-écrire une gestion totale de formulaire (en prenant comme base
de départ un article de ST Mag qui faisait ça en GFA par exemple)
n'est pas très dur. Ce qui est sympa également c'est de rajouter
un petit carré en haut à droite, afin de déplacer le formulaire.
Pour toutes ces options, vous pouvez bien sûr faire ça à votre
propre sauce, mais les raccourcis clavier dont je parle sont déjà
un peu utilisés. Autant continuer afin que le système se
généralise, plutôt que de chercher à se distinguer par des trucs
mal commodes.
Je terminerai ce chapitre sur le GEM en vous invitant à découvrir
le Protocole de Communication GEM. Pour y avoir accès, décompactez
le fichier PROTOCOL.AR avec ARCHIVE.PRG. Vous placez ce fichier en
ram_disque (par exemple D). Vous préparez une disquette vierge,
vous lancez Archive vous choisissez Unpack avec D:\PROTOCOL.AR et
comme destination A:\*.* et vous attendez.
Il y a tous les sources, la biblio, la doc, les exemples etc...
Tous vos softs doivent être compatibles avec ce système s'ils veu-
lent être dans le coup!!! C'est facile et cela permet des délires
assez fabuleux!
Bons programmes GEM!!!!!
Back to ASM_Tutorial