[Résolu] Extraction de donné dans un AppleEvent
tablier
Membre
Je ne suis pas sur que ce message soit au bon endroit!! je n'expose ici qu'une petite partie du problème.
Je souhaite commander toast en direct par des AppleEvents. Toast étant ouvert par ailleur et son PSN étant connu, l'équivalent du script:
s'écrit comme ci-dessous. Il s'agit donc d'envoyer un apple Event, et de récupérer l'apple event de retour. cela marche très bien:
A ce point du fonctionnement, Toast est correctement réglé et j'ai dans "reponse" l'AppleEvent de retour dont la représentation dans la console est:
Comment fait-on cela? Eventuellement qui aurait un exemple plus complexe que ce qu'il y a dans la doc?
Je souhaite commander toast en direct par des AppleEvents. Toast étant ouvert par ailleur et son PSN étant connu, l'équivalent du script:
global ToastBase
tell application "Toast Titanium"
set ToastBase to make new ISO 9660 disc
end tell
s'écrit comme ci-dessous. Il s'agit donc d'envoyer un apple Event, et de récupérer l'apple event de retour. cela marche très bien:
OSErr err;
AppleEvent diskEvent;
AppleEvent reponse ;
err = AEBuildAppleEvent( kAECoreSuite, kAECreateElement,
typeProcessSerialNumber, &Toastpsn, sizeof(Toastpsn),
kAutoGenerateReturnID, kAnyTransactionID, &diskEvent, NULL,
"'kocl':type('dI96')") ;
if (err == noErr)
{
err = AESend(&diskEvent, &reponse, kAEWaitReply | kAECanInteract,
kAENormalPriority, kNoTimeOut, NULL, NULL) ;
(void) AEDisposeDesc(&diskEvent);
A ce point du fonctionnement, Toast est correctement réglé et j'ai dans "reponse" l'AppleEvent de retour dont la représentation dans la console est:
Cet AppleEvent contient l'index du disque à remplir (ici: 1). Et je n'arrive pas à extraire cet index. J'ai beau lire, relire et faire différents essais, je ne m'en sort pas >:({ 1 } 'aevt': aevt/ansr (ppc ){
return id: 64815107 (0x3dd0003)
transaction id: 0 (0x0)
interaction level: 112 (0x70)
reply required: 0 (0x0)
remote: 0 (0x0)
target:
{ 1 } 'psn ': 8 bytes {
{ 0x0, 0x5e0001 } (Toast Titanium)
}
optional attributes:
< empty record >
event data:
{ 1 } 'aevt': - 1 items {
key '----' -
{ 1 } 'obj ': - 4 items {
key 'want' -
{ 1 } 'type': 4 bytes {
'Disc'
}
key 'from' -
{ -1 } 'null': null descriptor
key 'form' -
{ 1 } 'enum': 4 bytes {
'indx'
}
key 'seld' -
{ 1 } 'long': 4 bytes {
1 (0x1)
}
}
}
}
Comment fait-on cela? Eventuellement qui aurait un exemple plus complexe que ce qu'il y a dans la doc?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Donc tu dois utiliser la function AEGetParamDesc pour extraire le contenu de la donnée de key 'seld' (je pense que c'est cette clé qui contient l'index que tu veux).
Logiquement, je pense qu'il faut extraire le paramètre (le descripteur de l'objet??) puis aller chercher sa spécification 'seld'. Et là , il me reste beaucoup de questions et je n'arrive pas à écrire le code!
Il faut donc extraire l'argument sous forme de liste, puis parcourir chaque index de cette liste jusqu'à trouver l'index de clé 'seld' pour en extraire sa valeur.
Voici un code non testé, mais qui doit en gros t'indiquer la marche à suivre :
C'est minimaliste. Chaque fonction AE retourne un code erreur qui doit être testé.
J'ai aussi des doutes sur la récupération du type long de la clé 'seld'. J'ai choisi de ne pas faire de conversion (type typeWildCard) en espérant que ça retourne effectivement une valeur de type long. Sinon, il faudra approfondir la doc pour passer le juste type.
Il me reste une intérogation: porquoi l'index va de 1 à 4 et non pas de 0 à 3 comme en C standard?
L'Apple Event Manager date de Système 7.
La toolbox du Mac à cette époque été très imprégnée du Pascal.
Les premières versions de la toolbox (celles datant du Lisa) étaient écrites en Pascal.
Même si à l'avènement du Mac, la toolbox a été ré-écrite en C (pour gagner en taille de code et de rapidité), la philosophie est restée la même (que ce soit pour les formats de chaines de caractère, les appels aux fonctions, ou la gestion des tableaux - en Pascal, le premier indice est toujours 1- ).
PS : je trouve ton code pas très propre.
En effet, si la liste ne contient aucune donnée, on ne passe pas dans la boucle. Or tu testes ensuite la variable seld qui se trouve non initialisée...
les guillemets simples c'est en général pour des caractères uniques, pas des chaà®nes, et le "==" pour comparer des chaà®nes, ben heu, bof quoi...
J'ai dû louper un épisode :P
Donc aucun problème à priori.
Réapprendre le C ?
'x' = 1 char ou 1 octet ou 8 bits,
'xy' = 2 char ou 1 mot ou 16 bits,
'xyzt' = 4 char ou 1 int ou 32 bits,
etc...
int main (int argc, const char * argv[]) {
unsigned short t=(unsigned short) 'xy';
unsigned int u='a'*256*256*256+'b'*256*256+'c'*256+'d';
if(t=='xy' && u=='abcd'){
puts("equality");
} else {
puts("non equality");
}
return 0;
}
% gcc pgm.c -o pgm -Wno-multichar
% pgm
equality
%
Bien sûr je connaissais le 'A' représentation alternative du char de valeur 65, code ascii de A.
Mais 'AB' pour la représentation alternative d'un short = 65*256+66 je connaissais pas, et pareil pour 'ABCD' et les long
A quel point c'est sensible à l'endianness, ce truc, d'ailleurs ? 'AB' représente le short 65*256+66 sur toutes les architectures (et donc ainsi représenté en mémoire par 0x41 suivi de 0x42 sur les archis bigendian, l'inverse sur les little endian) ? ou 0x4142 dans tous les cas (et j'imagine que c'est plutôt ça) ?
Enfin bon, comme quoi on en apprend tous les jours (et toutes les nuits aussi ;D)
#include <stdio.h>
int main (int argc, const char * argv[]) {
unsigned short t= 'xy';
char c=*((char*) &t );
putchar(c);Â Â Â // affiche 'y' en little endian
return 0;
}
Je n'ai pas trouvé de confirmation mais j'imagine aussi que little endian et big endian c'est de la "cuisine arrière" et que dans le code c'est la "lecture humaine" qui est privilégiée.
[EDIT] la norme ISO/IEC 9899 (6-4-4-4) déclare l'évaluation de ces multibytes "implementation-dependant"Â