Stilulus 02 Le GEM a bon DOS, et c'est MagiC!
Stilulus 02 Le GEM a bon DOS, et c'est MagiC!
par Shadow272 Lun 16 Nov - 15:00
Le GEM a bon DOS, et c'est MagiC!
(et tout ça en GFA)
Tout d'abord, milles excuses pour les imperfections du premier article sur la programmation GFA. J'en impute (non c'est pas un gros mot) la cause à la transcription HTML maladroite faite sous WebExpert sur PC, à partir d'un article au format ASCII Atari. Pour ceux qui voudraient la version corrigée : vous n'avez qu'à cliquez ici. Cet article n'était pas facile à comprendre, je vais donc essayaer de rectifier le tir. Si vous voulez toutefois persévérer, il y a un exemple source au format LST d'un de mes programmes sur le cédérom 02 de l'excellent STraTOS (dans le dossier Internet : GFAMENU). [12/12/97: je viens de m'apercevoir que j'ai envoyé le source de la version 1.2 de Joe à STraTOS 3 !]
Cette fois-ci, on va parler des noms de fichiers longs gérés par MagiC 5. Enfin, pas quelque chose d'officiel ; je vais juste raconter ce qui m'est arrivé pour pouvoir gérer les noms longs pour la version 1.30 de mon Joe adoré.
Malheur ! mais c'est compatible !
Ben oui. Les fonctions GEMDOS traitant des manipulations de fichiers acceptent les noms longs sans problèmes sous MagiC 5. GEMDOS(60,61,62,63,64,65,66,...) marchent donc sans problèmes quand on leur indique un nom de fichier long. Et vu que les fonctions FILE du GFA dérivent du GEMDOS, on peut les employer sans anicroches.
C'est plutôt cool de la part des auteurs talentueux de MagiC. Merci à eux, car on ne va pas trop se fatiguer. Seule une attention particulière doit être exigée lors de la programmation, il faut réserver assez de place mémoire pour pourvoir gérer des noms de fichiers plus longs.
Mais il y a un hic...
Evidemment, la facilité n'est pas un chose qu'on offre à nous, pauvres coders.
Si vous voulez ne pas planter votre joli programme GFA, il faut augmenter la sécurité avant tout appel par OPEN ; on rajoute donc un EXIST(fichier). et là, ça ne marche pas. On dit que cette fonction est buggée. remplaçons-là donc par celle corrigée de Emmanuel Baranger :
'
' n$ est une chaine C, se terminant par un nullbyte
'
FUNCTION s_exist(n$)
IF LEN(n$)=0
RETURN FALSE
ELSE
IF GEMDOS(78,L:V:n$,0)=0 ! =FSFIRST(fichier)
RETURN TRUE
ELSE
RETURN FALSE
ENDIF
ENDIF
ENDFUNC
Qui ne marche toujours pas avec les noms longs. S_exist revoie FALSE, ce qui fait dire que les fonctions FSFIRST et FSNEXT ne peuvent utiliser que les noms 8+3 de MSDOS. Je suppute que les auteurs de MagiC ont bricolé des fonctions permettant le passage des noms longs aux 8+3 et inversement. L'avenir nous le dira.
Pour avoir toujours notre EXIST, bien utile en GFA, il faut ruser. Les adeptes C ne l'utilisent jamais, parce que seule la fonction GEMDOS(61) est nécessaire. Si le fichier n'existe pas, le GEMDOS renvoie une valeur négative pour le handle (équivalent du #numéro du GFA) signifiant qu'il y a un problème.
Qu'à cela ne tienne, on va pomper sur le C :
'
' le nom de fichier doit se terminer ici par un nullbyte comme en C.
' pour ceux que ça gène, faire terminer par un nullbyte
' le nom dans le GEMDOS(61)
'
FUNCTION s_exist(exist_name$)
LOCAL existe&
IF LEN(exist_name$)=0 OR exist_name$=CHR$(0)
RETURN FALSE
ELSE
existe&=GEMDOS(61,L:V:exist_name$,W:0) ! on ouvre
IF existe&>0 ! si c'est positif
~GEMDOS(62,W:existe&) ! on renferme
RETURN TRUE ! et on dit que c'est bon
ELSE ! si problème
RETURN FALSE ! on dit qu'il n'y a rien
ENDIF
ENDIF
ENDFUNC
Et après on peut ouvrir le fichier avec le nom long.
Mais comment obtient-on ces noms longs de fichiers ?
C'était la question philosophique du mois, et je me remercie de l'avoir posé. On l'obtient en :
créant tout bêtement le fichier
par DRAG_DROP
par VA_START
par le FILESELECTOR de MagiC.
Le Drag n' Drop étant une technique difficile à faire expliquer, je ne vous parlerai que des deux dernières méthodes.
VA_START
C'est une méthode par tube GEM (donc interapplication, vive le multitache) qui constiste à se passer des noms de fichiers entre programmes. Magxdesk, entre autres, en fait une grande utilisation (tout comme Joe avec CAB, vous croyez comment qu'il l'appelle quand les deux sont déjà en mémoire ?). Donc, pour prendre exemple avec Joe et CAB,
Joe envoie un message VA_START via APPL_WRITE,
et CAB est averti par EVNT_MULT qu'il a un nom de fichier à piquer dans le mémoire. CAB le prend, et prévient ensuite par AV_STARTED (parce qu'il est poli) via APPL_WRITE qu'il a récupéré le nom et que Joe peut libérer la mémoire qu'il a alloué pour le buffer contenant le nom.
C'est pas clair ? Exemple en GFA plus ou moins correct :
du côté de Joe
n_adr%=GEMDOS(72,L:LEN(n$))
buf_adr%=GEMDOS(72,L:16)
ap_id_cab&=APPL_FIND("CAB ")
INT{buf_adr%}=18193 ! VA_START
INT{buf_adr%+2}=ap_id_joe&
LONG{buf_adr%+6}=n_adr% ! adresse où se trouve la chaine du nom de fichier
~APPL_WRITE(ap_id_cab&,16,buf_adr%)
Et du côté de CAB
evnt&=EVNT_MULTI(.....buf_msg%....
IF BTST(evnt&,4)
SELECT INT{buf_msg%}
CASE 10
gestion_menu
CASE 20
redraw
CASE 18193
appel_par_va_start
ENDSELECT
ENDIF
et plus loin dans CAB...
PROCEDURE appel_par_va_start
adr_nom%=LONG{buf_msg%+6}
ap_id_prg_appelant&=INT{buf_msg%+2}
IF adr_nom%>0 ! juste un petite sécurité
'
' on récupère le nom du fichier
'
nom_de_fichier$=CHAR{adr_nom%}
'
' on confirme au programme appelant qu'on a récupéré quelque chose
'
nettoyage_buf_msg
INT{buf_adr%}=18232 ! VA_STARTED
INT{buf_adr%+2}=ap_id_prg_appelant&
LONG{buf_adr%+6}=adr_nom% ! l'adresse qui nous était donnée par tube GEM
~APPL_WRITE(ap_id_prg_appelant&,16,buf_msg%)
'
charger(nom_de_fichier$)
'
ENDIF
RETURN
Et Joe reçoit VA_STARTED par ENT_MULTI et libère la mémoire qu'il a alloué.
le FILESELECTOR de MagiC
Là, on s'amuse. Il existe depuis la version 4 de ce système d'exploitation un sélécteur de fichiers pouvant gérer les noms longs, les sélections multiples, le pré-emptif (on peut appeler le sélecteur de fichiers dans une fenêtre !)... Prière donc d'appeler Application Systems France. Dites leurs que vous programmez sous MagiC (de préférence un petit éditeur HTML nommé Joe) et ils vous envoyent illico presto des docs développeurs (malheureusement en allemand et seulement celles qu'ils ont en stock, mais on peut se débrouiller avec la doc de MagiC 4)...
Ça donne en GFA :
'
' toutes les chaines se terminent par un nullbyte (CHR$(0))
'
PROCEDURE fslx_do(fi_titre$,fi_path$,fi_name$,fi_masque$,VAR fs_name$)
'
rub$=fi_path$+"U:\"+CHR$(0)+"C:\CLIPBRD\"+CHR$(0)+CHR$(0)
'
' fi_masque$ et rub$ sont des chaines C, chaque ligne se termine par un nullbyte,
' la chaine totale se termine par deux nullbytes
'
fi_path$=fi_path$+SPACE$(300) ! de la place
fi_name$=fi_name$+SPACE$(100) ! écartez-vous
'
GCONTRL(0)=194 ! nouvelle fonction AES
GCONTRL(1)=4 ! avec tout ses paramètres
GCONTRL(2)=4
GCONTRL(3)=6
GCONTRL(4)=2
'
GINTIN(0)=128 ! longueur du chemin dans la boite du fileseletor
GINTIN(1)=33 ! longueur du nom de fichier (dans le chemin) dans le fileselector
GINTIN(2)=0
GINTIN(3)=0
'
ADDRIN(0)=V:fi_titre$ ! titre de la boite
ADDRIN(1)=V:fi_path$ ! nom du chemin
ADDRIN(2)=V:fi_name$ ! nom du fichier sans le chemin
ADDRIN(3)=V:fi_masque$ ! masques possibles (prière de voir la doc)
ADDRIN(4)=0
ADDRIN(5)=V:rub$ ! chemins par défaut
'
GEMSYS
'
fsd%=ADDROUT(0) ! on récupère un identificateur qui
' servira à fermer le FILESELECTOR (c'est un handle)
IF GINTOUT(1)=1 ! si l'appel a marché
' on récupère le nom de fichier (avec chemin)
fs_name$=CHAR{V:fi_path$}+CHAR{V:fi_name$}+CHR$(0)
ELSE
fs_name$=CHR$(0)
ENDIF
'
IF GINTOUT(0) ! on referme proprement l'appel
GCONTRL(0)=191 ! c'est en fait fslx_close()
GCONTRL(1)=0
GCONTRL(2)=1
GCONTRL(3)=1
GCONTRL(4)=0
'
ADDRIN(0)=fsd%
'
GEMSYS
ENDIF
'
RETURN
Avant que j'aille me coucher...
MagiC 5.13 offre (comme MacOS System 7, semble-t-il) la possibilité de réduire la fenêtre à un simple barre de déplacement. A la manière des programmes bien ficelés de Rémi Vanel, sauf qu'il faut un double clic sur la barre de déplament pour réduire ou agrandir la fenêtre. C'est pratique, sauf quand on fait afficher par exemple un curseur texte toutes les secondes dans son petit éditeur préféré. Il faut alors tenir compte de deux messages supplémentaires que vous envoye le memory manager à propos de la gestion des fenêtres.
Il y avait :
20 REDRAW
50 SHUT_DOWN
18193 VA_START
etc...
Il y a maintenant, sous un nom non officiel
22360 réduction à la barre de déplacement
22361 retour à la taille normale
C'est tout pour ce soir et pour cette fois. Je part au lit, parce que demain, je prend tôt le TGV pour Paris et le Salon ATARI. Bonne nuit.
Rajah Lone
nef@mygale.org
Le 6 Décembre 1997
(et tout ça en GFA)
Tout d'abord, milles excuses pour les imperfections du premier article sur la programmation GFA. J'en impute (non c'est pas un gros mot) la cause à la transcription HTML maladroite faite sous WebExpert sur PC, à partir d'un article au format ASCII Atari. Pour ceux qui voudraient la version corrigée : vous n'avez qu'à cliquez ici. Cet article n'était pas facile à comprendre, je vais donc essayaer de rectifier le tir. Si vous voulez toutefois persévérer, il y a un exemple source au format LST d'un de mes programmes sur le cédérom 02 de l'excellent STraTOS (dans le dossier Internet : GFAMENU). [12/12/97: je viens de m'apercevoir que j'ai envoyé le source de la version 1.2 de Joe à STraTOS 3 !]
Cette fois-ci, on va parler des noms de fichiers longs gérés par MagiC 5. Enfin, pas quelque chose d'officiel ; je vais juste raconter ce qui m'est arrivé pour pouvoir gérer les noms longs pour la version 1.30 de mon Joe adoré.
Malheur ! mais c'est compatible !
Ben oui. Les fonctions GEMDOS traitant des manipulations de fichiers acceptent les noms longs sans problèmes sous MagiC 5. GEMDOS(60,61,62,63,64,65,66,...) marchent donc sans problèmes quand on leur indique un nom de fichier long. Et vu que les fonctions FILE du GFA dérivent du GEMDOS, on peut les employer sans anicroches.
C'est plutôt cool de la part des auteurs talentueux de MagiC. Merci à eux, car on ne va pas trop se fatiguer. Seule une attention particulière doit être exigée lors de la programmation, il faut réserver assez de place mémoire pour pourvoir gérer des noms de fichiers plus longs.
Mais il y a un hic...
Evidemment, la facilité n'est pas un chose qu'on offre à nous, pauvres coders.
Si vous voulez ne pas planter votre joli programme GFA, il faut augmenter la sécurité avant tout appel par OPEN ; on rajoute donc un EXIST(fichier). et là, ça ne marche pas. On dit que cette fonction est buggée. remplaçons-là donc par celle corrigée de Emmanuel Baranger :
'
' n$ est une chaine C, se terminant par un nullbyte
'
FUNCTION s_exist(n$)
IF LEN(n$)=0
RETURN FALSE
ELSE
IF GEMDOS(78,L:V:n$,0)=0 ! =FSFIRST(fichier)
RETURN TRUE
ELSE
RETURN FALSE
ENDIF
ENDIF
ENDFUNC
Qui ne marche toujours pas avec les noms longs. S_exist revoie FALSE, ce qui fait dire que les fonctions FSFIRST et FSNEXT ne peuvent utiliser que les noms 8+3 de MSDOS. Je suppute que les auteurs de MagiC ont bricolé des fonctions permettant le passage des noms longs aux 8+3 et inversement. L'avenir nous le dira.
Pour avoir toujours notre EXIST, bien utile en GFA, il faut ruser. Les adeptes C ne l'utilisent jamais, parce que seule la fonction GEMDOS(61) est nécessaire. Si le fichier n'existe pas, le GEMDOS renvoie une valeur négative pour le handle (équivalent du #numéro du GFA) signifiant qu'il y a un problème.
Qu'à cela ne tienne, on va pomper sur le C :
'
' le nom de fichier doit se terminer ici par un nullbyte comme en C.
' pour ceux que ça gène, faire terminer par un nullbyte
' le nom dans le GEMDOS(61)
'
FUNCTION s_exist(exist_name$)
LOCAL existe&
IF LEN(exist_name$)=0 OR exist_name$=CHR$(0)
RETURN FALSE
ELSE
existe&=GEMDOS(61,L:V:exist_name$,W:0) ! on ouvre
IF existe&>0 ! si c'est positif
~GEMDOS(62,W:existe&) ! on renferme
RETURN TRUE ! et on dit que c'est bon
ELSE ! si problème
RETURN FALSE ! on dit qu'il n'y a rien
ENDIF
ENDIF
ENDFUNC
Et après on peut ouvrir le fichier avec le nom long.
Mais comment obtient-on ces noms longs de fichiers ?
C'était la question philosophique du mois, et je me remercie de l'avoir posé. On l'obtient en :
créant tout bêtement le fichier
par DRAG_DROP
par VA_START
par le FILESELECTOR de MagiC.
Le Drag n' Drop étant une technique difficile à faire expliquer, je ne vous parlerai que des deux dernières méthodes.
VA_START
C'est une méthode par tube GEM (donc interapplication, vive le multitache) qui constiste à se passer des noms de fichiers entre programmes. Magxdesk, entre autres, en fait une grande utilisation (tout comme Joe avec CAB, vous croyez comment qu'il l'appelle quand les deux sont déjà en mémoire ?). Donc, pour prendre exemple avec Joe et CAB,
Joe envoie un message VA_START via APPL_WRITE,
et CAB est averti par EVNT_MULT qu'il a un nom de fichier à piquer dans le mémoire. CAB le prend, et prévient ensuite par AV_STARTED (parce qu'il est poli) via APPL_WRITE qu'il a récupéré le nom et que Joe peut libérer la mémoire qu'il a alloué pour le buffer contenant le nom.
C'est pas clair ? Exemple en GFA plus ou moins correct :
du côté de Joe
n_adr%=GEMDOS(72,L:LEN(n$))
buf_adr%=GEMDOS(72,L:16)
ap_id_cab&=APPL_FIND("CAB ")
INT{buf_adr%}=18193 ! VA_START
INT{buf_adr%+2}=ap_id_joe&
LONG{buf_adr%+6}=n_adr% ! adresse où se trouve la chaine du nom de fichier
~APPL_WRITE(ap_id_cab&,16,buf_adr%)
Et du côté de CAB
evnt&=EVNT_MULTI(.....buf_msg%....
IF BTST(evnt&,4)
SELECT INT{buf_msg%}
CASE 10
gestion_menu
CASE 20
redraw
CASE 18193
appel_par_va_start
ENDSELECT
ENDIF
et plus loin dans CAB...
PROCEDURE appel_par_va_start
adr_nom%=LONG{buf_msg%+6}
ap_id_prg_appelant&=INT{buf_msg%+2}
IF adr_nom%>0 ! juste un petite sécurité
'
' on récupère le nom du fichier
'
nom_de_fichier$=CHAR{adr_nom%}
'
' on confirme au programme appelant qu'on a récupéré quelque chose
'
nettoyage_buf_msg
INT{buf_adr%}=18232 ! VA_STARTED
INT{buf_adr%+2}=ap_id_prg_appelant&
LONG{buf_adr%+6}=adr_nom% ! l'adresse qui nous était donnée par tube GEM
~APPL_WRITE(ap_id_prg_appelant&,16,buf_msg%)
'
charger(nom_de_fichier$)
'
ENDIF
RETURN
Et Joe reçoit VA_STARTED par ENT_MULTI et libère la mémoire qu'il a alloué.
le FILESELECTOR de MagiC
Là, on s'amuse. Il existe depuis la version 4 de ce système d'exploitation un sélécteur de fichiers pouvant gérer les noms longs, les sélections multiples, le pré-emptif (on peut appeler le sélecteur de fichiers dans une fenêtre !)... Prière donc d'appeler Application Systems France. Dites leurs que vous programmez sous MagiC (de préférence un petit éditeur HTML nommé Joe) et ils vous envoyent illico presto des docs développeurs (malheureusement en allemand et seulement celles qu'ils ont en stock, mais on peut se débrouiller avec la doc de MagiC 4)...
Ça donne en GFA :
'
' toutes les chaines se terminent par un nullbyte (CHR$(0))
'
PROCEDURE fslx_do(fi_titre$,fi_path$,fi_name$,fi_masque$,VAR fs_name$)
'
rub$=fi_path$+"U:\"+CHR$(0)+"C:\CLIPBRD\"+CHR$(0)+CHR$(0)
'
' fi_masque$ et rub$ sont des chaines C, chaque ligne se termine par un nullbyte,
' la chaine totale se termine par deux nullbytes
'
fi_path$=fi_path$+SPACE$(300) ! de la place
fi_name$=fi_name$+SPACE$(100) ! écartez-vous
'
GCONTRL(0)=194 ! nouvelle fonction AES
GCONTRL(1)=4 ! avec tout ses paramètres
GCONTRL(2)=4
GCONTRL(3)=6
GCONTRL(4)=2
'
GINTIN(0)=128 ! longueur du chemin dans la boite du fileseletor
GINTIN(1)=33 ! longueur du nom de fichier (dans le chemin) dans le fileselector
GINTIN(2)=0
GINTIN(3)=0
'
ADDRIN(0)=V:fi_titre$ ! titre de la boite
ADDRIN(1)=V:fi_path$ ! nom du chemin
ADDRIN(2)=V:fi_name$ ! nom du fichier sans le chemin
ADDRIN(3)=V:fi_masque$ ! masques possibles (prière de voir la doc)
ADDRIN(4)=0
ADDRIN(5)=V:rub$ ! chemins par défaut
'
GEMSYS
'
fsd%=ADDROUT(0) ! on récupère un identificateur qui
' servira à fermer le FILESELECTOR (c'est un handle)
IF GINTOUT(1)=1 ! si l'appel a marché
' on récupère le nom de fichier (avec chemin)
fs_name$=CHAR{V:fi_path$}+CHAR{V:fi_name$}+CHR$(0)
ELSE
fs_name$=CHR$(0)
ENDIF
'
IF GINTOUT(0) ! on referme proprement l'appel
GCONTRL(0)=191 ! c'est en fait fslx_close()
GCONTRL(1)=0
GCONTRL(2)=1
GCONTRL(3)=1
GCONTRL(4)=0
'
ADDRIN(0)=fsd%
'
GEMSYS
ENDIF
'
RETURN
Avant que j'aille me coucher...
MagiC 5.13 offre (comme MacOS System 7, semble-t-il) la possibilité de réduire la fenêtre à un simple barre de déplacement. A la manière des programmes bien ficelés de Rémi Vanel, sauf qu'il faut un double clic sur la barre de déplament pour réduire ou agrandir la fenêtre. C'est pratique, sauf quand on fait afficher par exemple un curseur texte toutes les secondes dans son petit éditeur préféré. Il faut alors tenir compte de deux messages supplémentaires que vous envoye le memory manager à propos de la gestion des fenêtres.
Il y avait :
20 REDRAW
50 SHUT_DOWN
18193 VA_START
etc...
Il y a maintenant, sous un nom non officiel
22360 réduction à la barre de déplacement
22361 retour à la taille normale
C'est tout pour ce soir et pour cette fois. Je part au lit, parce que demain, je prend tôt le TGV pour Paris et le Salon ATARI. Bonne nuit.
Rajah Lone
nef@mygale.org
Le 6 Décembre 1997
Shadow272- Admin
- Messages : 329
Date d'inscription : 28/12/2017
Age : 65
Localisation : Hainaut Belgique -
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum|
|
|