MCC à l’écoute d’un répertoire
15 sujets de 1 à 15 (sur un total de 15)
-
Salut, j’ai toujours trouvé hallucinant le fait que les posts à tendance “flamesque” (cherchez c’est un nouveau mot qui ne sera que dans le robert version 2009
obtenaient à une vitesse proche de celle de la lumière des dizaines de réponses tandis que des posts à vocation plus sérieuse (comme le tiens ou ceux de gilloo par exemple) n’en obtiennent aucune !Bref je te propose de poser ta question sur Guru-meditation (ha bhein tiens non ça doit plus exister) et si tu ne crains pas l’anglais va sur UtilityBase tu aura plus de chances d’avoir une réponse.
gurumed n’est pas en forme
C’est vrai que les sujets comme ceux là ont rarement de réponses : il faut la compétence, il faut prendre le temps d’investiguer éventuellement, … pourtant c’est sur ces posts qu’il faut se mobiliser si on veut que ça porte ses fruits.
Pour le problème posé, le plus simple serait à mon avis de commencer par obtenir la notification dans un programme normal qui irait appeler une méthode de la classe MUI.
Peut-être que la classe MUI pourrait créer un process qui se chargerait de ce boulot …
Il faudrait demander sur la ML MUI ou sur utilitybase …
@Alex Heureusement que toutes les questions n’ont pas de réponse… il n’y aurait plus de chercheur
@Rmais96 Je ne pratique pas les classes… mais je peux peut être t’aider avec ce qui suit:En regardant les includes dos/notify.h, intuition/intuition.h et les autodoc ad hoc,
tout s’explique facilement.
Si on compare un IntuiMessage à un NotifyMessage, on s’aperçoit que les 3 premiers
éléments nm_ExecMessage <=> ExecMessage, nm_Class <=> Class, nm_Code <=> Code sont communs.
Le reste de la structure est différente, mn_NReq est une addresse sur un NotifyRequest,
mais quelquefois on a bien une addresse dans le IAddress d’un IntuiMessage.
De plus les classes NOTIFY_CLASS=0x4000000 et code NOTIFY_CODE=0x1234 ne correspondent
pas à un IDCMP.
Alors pourquoi pas utiliser la classe NOTIFY_CLASS dans la boucle de traitement des messages IDCMP?
Petit exemple:
#include stdio.h
#include stdlib.h
#include string.h
#include dos/notify.h
#include intuition/intuition.h
#include proto/exec.h
#include proto/dos.h
#include proto/intuition.h
int main(int argc, char *argv[])
{
struct Window *w ;
struct IntuiMessage imessage, *imsg ;
struct NotifyRequest mynotifyrequest ;
BOOL loop ;
w = OpenWindowTags(NULL,
WA_Width, 400,
WA_Height, 100,
WA_CloseGadget, TRUE,
WA_SizeGadget, TRUE,
WA_DragBar, TRUE,
WA_DepthGadget, TRUE,
WA_Title, (ULONG)”StartNotify/EndNotify”,
WA_IDCMP, IDCMP_CLOSEWINDOW,
TAG_DONE) ;
if (w != NULL)
{
memset(&mynotifyrequest, 0, sizeof(mynotifyrequest)) ;
mynotifyrequest.nr_Name = “ram:filou.txt” ;
mynotifyrequest.nr_Flags = NRF_SEND_MESSAGE ;
mynotifyrequest.nr_stuff.nr_Msg.nr_Port = w->UserPort ;
StartNotify(&mynotifyrequest) ;
printf(“Start notification for “%s”n”, mynotifyrequest.nr_Name) ;
loop = TRUE ;
do
{
WaitPort(w->UserPort) ;
imsg = (struct IntuiMessage*)GetMsg(w->UserPort) ;
if (imsg != NULL)
{
imessage = *imsg ;
ReplyMsg((struct Message*)imsg) ;
switch(imessage.Class)
{
case IDCMP_CLOSEWINDOW :
{
loop = FALSE ;
break ;
}
case NOTIFY_CLASS :
{
struct NotifyMessage *mynotifymessage = (struct NotifyMessage *)&imessage ;
/* Le NotifyMessage est plus petit que l’intuimessage : pas propre mais on s’en tape */
printf(“Notify !!n”) ;
if (mynotifymessage->nm_NReq != NULL)
{
printf(” Class 0x%08lxn”, mynotifymessage->nm_Class) ;
printf(” Code 0x%04lxn”, mynotifymessage->nm_Code) ;
printf(” Name
“%s”n”, mynotifymessage->nm_NReq->nr_Name) ;printf(” FullName:”%s”n”, mynotifymessage->nm_NReq->nr_FullName) ;
}
break ;
}
}
}
} while (loop) ;
printf(“End notification for “%s”n”, mynotifyrequest.nr_Name) ;
EndNotify(&mynotifyrequest) ;
CloseWindow(w) ;
}
return 0 ;
}
A partir de ce petit programme, on peut créer un fichier ou un répertoire dans ram:filou.txt
On recevra une notification à chaque création/mise à jour/déplacement/suppression du fichier.
Le hic c’est que l’on s’attendrait à savoir ce que ce bougre d’utilisateur a fait avec ce fichier.
Or j’ai bien l’impression que l’on ne peut pas le savoir…
Cela doit être utile pour savoir qu’un fichier de paramètres à été modifié.
J’ai enlevé les fioritures des includes mais vous saurez bien les remettre…
A dodo et soyez sages sinon Sébastien Chabal va venir vous gronder…
Alors, un post qui ne fait que résumer…
La 1ère solution peut probablement marcher au sein d’un event handler classique avec ce qu’a écrit Gillou, bien que je trouve ça limite comme détournement, mais pourquoi pas.
La 2nde solution peut être réalisée en utilisant un sous process qui implèmenterait lui même la boucle d’attente du signal, comme l’a suggéré corto, mais c’est peut être un peu compliqué à mettre en oeuvre niveau synchronisa
La 3ème solution est évidemment très simple à réaliser mais peu adaptée pour une mcc. Pour exemple, Ambient gère le dosnotify en écoutant dans la boucle principale (entre autres) le signal associé au port sur lequel le message dosnotify est envoyé, et agit en conséquence lors de son activation.
Et sinon, il n’y a en effet pas de moyen de connaitre la nature de l’opération effectuée sur le fichier, et c’est bien regrettable. Ca pourrait être une évolution intéressante de l’API sur les OS encore développés.
Fab1 a écrit :
La 1ère solution peut probablement marcher au sein d’un event handler classique avec ce qu’a écrit Gillou, bien que je trouve ça limite comme détournement, mais pourquoi pas.
Certes, je programme comme je joue au rugby… mais si un NotifyMessage ressemble à un IntuiMessage ce n’est pas uniquement pour des pruneaux: ca sert à ça et il faut bien spécifier que l’on veut un message et pas un signal lors de la notification.
Dans ma jeunesse j’avais même réussi à détourner les messages wb avec AlohaWorkbench() dans le userport d’une fenêtre, mais ça ne fonctionne plus à partir du 2.0
Comme ça je pouvais déplacer une icône de projet dans une de mes fenêtres et afficher le fichier correspondant bien avant que windows ou OS2 ne fasse de même, huhuhu
Et tu peux demander aussi sur la mailling list amiga-C2, il y plein de programmeurs talentueux dessus
va voir là : Amiga-C2
ou inscris toi directement [email]Amiga-C2-subscribeATyahoogroupsPOINTcom[/email]
Le multithreading et MUI s’entendent bien. La seule “contrainte” est d’utiliser un pushmethod pour agir sur l’objet depuis un thread. Pushmethod, dont la taille de la file est limitée.
Mais par exemple, sur ambient, je me suis amusé à faire intervenir jusqu’à 6 threads simultanés qui agissent sur les différentes colonnes des listers (icones, filetypes, md5, version, taille des répertoires, preview vidéo).
Au sujet de la classe DOSNotify de Feelin :
Lorsque la classe est crée, elle créee un Thread qui sera utilisé pour recevoir les messages de notification émis par le DOS. Lorsque le thread reçoit un message, tout ce qu’il fait c’est mettre l’attribut Update de l’objet correspondant au nom du fichier/dossier en audit.
Au développeur d’ajouter la notification qui lui convient sur l’attribut de l’objet DOSNotify.
En ce qui concerne la concurrence, ce n’est que dans des cas très précis et heureusement rares qu’elle intervient. Pour bloquer une objet il suffit d’utiliser la méthode Lock et pour le libérer la méthode Unlock. C’est pas bien compliqué.
Bref, n’hésite pas à utiliser mon code, il est pas open-source pour rien
15 sujets de 1 à 15 (sur un total de 15)
- Vous devez être connecté pour répondre à ce sujet.
