Stimulus 03 Plus loin avec MagiC

Plus loin avec MagiC

(voire MiNT, mais je ne m'avance pas sur ce terrain)


Ce que je vous livre ci-après n'a pas été ni éprouvé par l'expérience, ni par les conseils d'une tierce personne. Une partie de l'article est donc sans valeur, mais je voulais vous faire partager ce que je viens de découvrir. Par manque de temps avant le bouclage, je n'ai pu programmer les routines, j'ai juste simplement zyeuté les docs (TOS.HYP, Compemdium cédérom et la doc-dev de MagiC téléchargée avec Internet sur le site d'Application Systems Heidelberg), essayé de traduire et de déduire.
Ces précisions concernent le début qui concerne...


Les noms longs de MagiC (suite)

Vous vous rappelez la dernière fois ? On avait presque tout appréhendé des noms longs. Presque tout car il manquait les fameux Fsfirt() et Fsnext() qui donnaient seulement des noms 8+3 majuscules de MSDOS.
Et bien, il ne faut plus les employer avec les noms longs ! Ça a le mérite d'être clair. D'après ce que j'ai compris c'est tabou ("tabu" en teuton) donc strictement interdit. De nouvelles fonctions existent depuis la version 0.90 de MiNT, pour nous il suffira de tester si on a une version de l'AES égale ou supérieure à 3.99, puisque MagiC (se voulant compatible avec MultiTOS) possède ces fonctions.

Ces nouvelles fonctions (provenant de MiNT, donc d'Unix) ont la caractèristique de considérer la FAT comme une réserve de simples fichiers. On peut trouver à côté de vieilles fonctions comme Dcreate (MKDIR ou GEMDOS(57)) :

Dopendir dirhandle%=GEMDOS(296,L:ad_nom_dir%,W:flag&)
ad_nom_dir% est l'adresse de la chaîne (terminée par un nullbyte) du chemin (sans le \ de fin), flag& est à 0 pour avoir le mode compatible (l'autre valeur est 1 pour Unix), dirhandle% est le handle du dossier ouvert (comme un fichier normal ou une fenêtre, quoi)

Dclosedir ~GEMDOS(299,L:dirhandle%)
Comme on est propre sur soi et qu'on respecte le système, il faut toujours fermer ce qu'on a ouvert, c'est la même chose pour un fichier normal ou une fenêtre.

Dxreaddir retour%=GEMDOS(322,W:taille_buffer&,L:dirhandle%,L:ad_buffer%,L:attr%,L:xr%)
Avec cet appel, le GEMDOS va lire la (V)FAT et déposer dans la zone mémoire ad_buffer% de taille taille_buffer&, le nom du fichier (qu'il soit long ou pas). Si la longueur de la chaîne de caractère est supérieure à la taille du buffer, retour% prend une valeur particulière. Si tous se passe bien, la fonction renvoie 0.
La fonction sert une fois pour un nom de fichier, si on veut le reste, il faudra mettre Dxreaddir dans une boucle dont on sort avec retour%<>0

Autre chose importante, la fonction charge également les attributs du fichier dans une structure XATTR qui est de la forme :

typedef struct xattr
{
   UWORD   mode;               /* Dateimodus                 */
   LONG    index;              /* Dateinummer                */
   UWORD   dev;                /* Gerätenummer               */
   UWORD   reserved1;          /* reserviert                 */
   UWORD   nlink;              /* Anzahl der Links           */
   UWORD   uid;                /* Benutzernummer             */
   UWORD   gid;                /* Gruppennummer              */
   LONG    size;               /* Dateilänge                 */
   LONG    blksize, nblocks;   /* Blockgröße/belegte Blocks  */
   UWORD   mtime, mdate;       /* Datum der letzten Änderung */
   UWORD   atime, adate;       /* Datum des letzten Zugriffs */
   UWORD   ctime, cdate;       /* Erstellungsdatum           */
   UWORD   attr;               /* TOS-Dateiattribute         */
   UWORD   reserved2;          /* reserviert                 */
   LONG    reserved3[2];       /* reserviert                 */

} XATTR;
Remarquez que cette structure contient l'attribut du fichier tel qu'on le connait dans le vieux TOS. Si l'offset +30 de l'adresse xattr% contient :
0 : fichier standart
1 : fichier en read only
2 : fichier caché
16 : dossier
Si l'attribution n'a pas marché xr% est différent de zéro.
Drewinddir ~GEMDOS(298,L:dirhandle%)
Revenir en début de liste !


Voilà, dommage que Fsfirst et Fsnext sont interdites, car elles nous aidaient bien pour le filtrage des fichiers ! Il faut donc le faire à la main. Voici donc, plus ou moins traduit en GFA de la doc-dev "officielle" de MagiC (écrite par Andreas Kromke himself) comment on fait :

dirhandle%=@Dopendir(adr_nom_dir%,0)
IF dirhandle%>0
 DO
   retour%=@Dxreaddir(taille_buffer&,dirhandle%,adr_buffer%,xattr%,xr%)
   '
   ' ici, test de INT{xattr%+30} (me suis-je trompé dans les offsets ?) pour
   ' déterminer la nature du fichier, éventuel filtrage : recherche de
   ' chaîne (utilisez UPPER$() pour éviter les problèmes de casse)
   ' puis    
   ' indexation dans une liste qu'on conservera ou traitement immédiat
   ' on récupère la chaîne de texte avec a$=CHAR{adr_buffer%}
   '
 LOOP UNTIL retour%<>0
 ~@Dclosedir
ENDIF
NB : Il est clair qu'on a alloué de la mémoire pour les buffers (adr_nom_dir%, adr_buffer%, xattr%), que les chaînes se terminent par des nullbytes, et que les fonctions sont quelques part sous la forme de GEMDOS(numéro,paramètres... quelque part dans votre programme GFA.
Je rappelle que tous cela n'a pas été vérifié, seulement tiré et déduit des docs que j'ai en ma possession.


Petite gâterie

Pour les besoins de Joe, j'avais besoin de contrôler une fenêtre qui ne m'appartenais pas (ouh, le vilain !), celle de CAB en particulier, afin de pouvoir la mettre en bandeau avec celle de Joe. Il me faut donc un handle de fenêtre inconnu pour pouvoir la manipuler. J'ai juste l'ap_id& de CAB.
Prise de tête... Cerveau en surchauffe... J'avais l'intuition qu'on pouvait le faire en GEM. Ne tenant plus avant quelques minutes, j'appelle au téléphone mon gourou, mon maître à penser, mon mentor : Emmanuel BARANGER. Celui-ci, toujours enclin à aider plus faible que lui, se décarcasse pour me trouver la réponse. Après dix minutes de recherche dans sa mémoire colossale, celui-ci me répond qu'il n'a pas trouvé, mais me conseille de chercher dans la doc-dev au niveau des fonctions de WIND_GET. Je le remercie, passe le bonjour à sa petite famille et raccroche.
Vite sur les doc-dev ! J'épluche tout ce que j'ai et je trouve quelques indices. En fait, il faut faire intervenir un ensemble de fonctions qui ont été upgradées avec MagiC et MiNT. Voici ci-après ce que ça donne :
FUNCTION cab_win
 '
 ' on récupère l'ap_id& de CAB
 '
 survey_bro&=APPL_FIND("CAB     ")
 '
 ' à qui appartient la fenêtre active ? sinon on récupère le
 ' handle (below_win%) de la fenêtre juste en dessous
 '
 ~WIND_GET(0,10,win%,app%,below_win%,dummy%)
 '
 '
 IF app%=survey_bro& ! bingo c'est la première
   '
   ' je teste les composantes, car celle que je veux a le bouton "fuller"
   '
   ~WIND_GET(win%,1,comp_win%,dummy%,dummy%,dummy%)
   IF BTST(comp_win%,2)
     RETURN win%
   ENDIF
 ENDIF
 '
 ' je teste à qui appartiennent les fenêtre en dessous
 '
 WHILE WIND_GET(below_win%,20,app%,dummy%,dummy%,win%)
   IF win%=0
     RETURN 0
   ENDIF
   IF app%=survey_bro&
     ~WIND_GET(below_win%,1,comp_win%,dummy%,dummy%,dummy%)
     IF BTST(comp_win%,2)
       RETURN below_win%
     ENDIF
   ENDIF
   below_win%=win%
 WEND
 RETURN 0
ENDFUNC
La fonction renvoie 0 si échec, ou le handle% de la fenêtre. Attention, ça ne marche que si une seule fenêtre de navigation de CAB est ouverte. S'il y en a plusieurs, c'est la première en avant plan qui sera prise.
De même, ne vous amusez pas à faire un WIND_SET brut et méchant. Comme en GEM il faut être propre sur soi et qu'on est pas des sauvages, on va demander à CAB via tube GEM (rappelez vous la dernière fois à propos du VA_START). Ça donne :
cab_win%=@cab_win
IF cab_win%>0 AND cab_win%<32000
 INT{m_adr%}=27     ! WM_SIZED
 INT{m_adr%+2}=ap_id_de_joe& ! on s'identifie
 INT{m_adr%+4}=0
 INT{m_adr%+6}=cab_win%
 INT{m_adr%+8}=screenx&+1     ! x
 INT{m_adr%+10}=screeny&+202  ! y
 INT{m_adr%+12}=screenl&-4    ! largeur
 INT{m_adr%+14}=screenh&-205  ! hauteur
 ~APPL_WRITE(survey_bro&,16,m_adr%)
ENDIF
m_adr% est un buffer de 16 octets qui est rempli comme le remplirait le Screen Manager (Vous savez, l'application invisible dont l'ap_id& est toujours 1, qui gère tout l'AES). C'est au tour de CAB d'accepter ou non le message. Je vous conseille de mettre l'ap_id& de votre programme plutôt que 1, car c'est malpoli de se faire passer pour quelqu'un d'autre.

Petite gâterie (bis)

C'est bien le multitache, surtout quand on a une fenêtre du bureau ouverte, dans laquelle on crée, modifie ou efface un fichier avec notre application. Petit problème, car à chaque écriture sur le disque, la fenêtre n'est pas réactualisée. Soyons civils, il suffit de prévenir le bureau (en l'occurence Magixdesk ou autre). Réponse, toujours par tube GEM :
PROCEDURE force_drive(force_drive$)
 INT{m_adr%}=72
 INT{m_adr%+2}=ap_id&
 INT{m_adr%+4}=0
 INT{m_adr%+6}=MAX(0,MIN(ASC(force_drive$)-65,25))
 INT{m_adr%+8}=0
 INT{m_adr%+10}=0
 INT{m_adr%+12}=0
 INT{m_adr%+14}=0
 ~APPL_WRITE(0,16,m_adr%)
RETURN
force_drive$ contient la lettre correspondant au disque logique (A pour le lecteur, C pour la partiction C:, etc...), c'est en fait un LEFT$(chemin$) qui est envoyé à cette fonction.

A bientôt pour de nouvelles aventures !

Cela-dit, essayez de vous procurer une doc-dev, c'est très facile quand on la veut vraiment. Cédéroms, commerce (mais c'est presque donné pour ce que ça vaut), Internet, relations... Je ne le répèterai jamais assez, mais ce genre de document est un trésor pour celui qui en détient un exemplaire. Non pas parce que d'autres ne l'ont pas et que vous si, mais parce que cela ouvre de nouveaux horizons. Votre relation avec votre Atari chéri en devient de plus en plus étroite au fur et à mesure que vous savez comment votre ordinateur fonctionne.
Ce n'est pas donné à tout le monde de connaître sa machine.


Rajah Lone
nef@mygale.org
écrit le 9 Mars 1998