COURS209.TXT/fr
****************************************************************** * * * 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