Bonjour Je suis entrain de fabriquer un patch pour faire des présentations type powerpoint en utilisant Pure data et un Wiimote pour controler. Les slides sont des .jpg numérotés et défilent grace à un [ counter ].
Je cherche une fonction qui retourne un Bang à chaque message d'erreur que je lierais au message [destroy< du gemwin Comme ça quand le counter dépasse le nombre d'image du dossier la fenetre se ferme automatiquement.
une recherche google a été infructueuse alors je pose la question ici.
Hors ligne
Moi je mets des claques à mon ordi quand il se trompe.
Que de complications...
Pourquoi ne pas trouver le nombre d'images et mettre un [sel] qui te ferme la fenêtre ?
Regarde [hcs/folder_list *.jpg] ou [flatspace/folder_list *.jpg]
Avec ça tu peux déterminer le nombre d'éléments : [list length]
Aller en avant et en arrière en incrémentant un compteur qui va prendre l'élément correspondant dans la liste avec des [list split]
Hors ligne
Bien sur que ce serais tires facile comme ça. mais bon j'aime me compliquer la vie, juste pour aprendre de nouveau trucs.
J'aimerais tout de même savoir si une telle fonction existe (celle qui envoie un Bang s'il y a un erreur).
Hors ligne
Hé,
"une erreur" c'est trop vague comme déclencheur d'info... Ca dépend du contexte et des acteurs.
Toi ce que tu voudrais savoir c'est si l'objet dont tu te sers pour charger des images ([pix_image] j'imagine) n'arrive pas à charger le fichier demandé ; [pix_image] ne le fait pas, par exemple...
Donc il faudrait trouver une autre façon de savoir si tel fichier existe. Je ne connais pas d'objet tout fait pour ça, mais il y aurait plusieurs manières. Par exemple tu pourrais lire les 10 premiers octets du fichiers avec [soundfiler] -raw -maxsize 10 ; si il retourne "0" samples lus c'est que le fichier n'existe pas...
Hors ligne
ant1r a écrit:
"une erreur" c'est trop vague comme déclencheur d'info... Ca dépend du contexte et des acteurs.
Pour moi c'est foireux comme approche. Il faut travailler sur ce que l'on sait ou sur ce qu'on peut savoir plutôt que sur ce qu'on ne sait pas. Il y a des moyen de trouver l'information pour travailler de façon positive plutôt que d'attendre une éventuelle "erreur".
Si tu conduits une bagnole avec la même logique, je te raconte pas le problème quand tu arrives au bord du précipice... "Hé oui, il n'y a plus de route"
Hors ligne
pob a écrit:
travailler de façon positive plutôt que d'attendre une éventuelle "erreur".
Certains tests sont de nature négative, genre je vais à la pompe quand je n'ai plus beaucoup d'essence...
Dans une boucle comme :
while(fichier.existe()) { faire quelquechose avec le fichier fichier = fichier_suivant }
le test
fichier.existe()
est bien obligé de s'arrêter sur une réponse négative. Ca peut rendre service les erreurs !
Dernière modification par ant1r (2015-12-28 23:30:10)
Hors ligne
Oui, tu vas à la pompe en voiture quand la jauge te dit que t'es pas loin du fond à moins d'aimer la marche à pied avec un bidon à la main pendant 10km au bord de l'autoroute.
Dans l'exemple du code que tu proposes la différence, c'est que tu ne tentes pas de créer le fichier avant de te rendre compte qu'il existe déjà. Tu testes l'existence avant de l'écraser pour en créer un nouveau.
Dans l'idée originale de yecqo on tente une action et on arrête après l'erreur. On fonce dans le mur tête en avant et on ne s'arrête que lorsqu'on se cogne plutôt que de regarder où on va.
Ce que je soulève n'est pas d'avoir une réponse négative à un test avant une action, c'est d'agir avant de savoir si ce qu'on va faire est valide ou non. Mais bon, ça doit être dans l'air du temps de ne pas se poser de question avant d'agir...
Hors ligne