Envoyé par
pedestre
ProcessMessages ou Sleep ne donnent rien (ça me paraît assez normal car une valeur de loop différente de 0 est reconnue et interprétée sans qu'il soit nécessaire de faire un retardement et pourquoi 0 demanderait un traitement différent ?).
J'en sais rien, c'était vraiment pour te faire tester parce que je n'ai pas trop le temps de me pencher là-dessus...
Je pensais qu'il fallait un peu de temps au composant pour charger le fichier (parfois très gros) et qu'ensuite il prendrait en compte les options, bah, une idée comme une autre, en tout cas un grand bravo puisque tu as pu trouver la solution
Envoyé par
pedestre
J'ai trouvé la solution suivante: faire suivre le "play" de la suite des 2 instructions "loop:=1; loop:=0". Cela fonctionne bien à condition toutefois que la valeur de loop dans l'inspecteur d'objets ne soit pas 1 (je mets loop à 0 dans l'inspecteur d'objets et l'instruction "loop:=1" va bien donner quelque chose puisque la nouvelle valeur (1) est différente de l'ancienne - voir le code de la procedure TCustomMPlayerControl.SetLoop que tu m'as envoyé: si on a mis loop à 1 dans l'inspecteur d'objets, cette valeur est quand même entrée d'une certaine façon et lorsqu'on cherche à entrer un nouvel 1 on a "exit").
Ainsi il semble bien que l'instruction loop:=0 soit acceptée et fonctionne comme requis à condition que loop ait été mis auparavant à une valeur strictement supérieure à 0, cette valeur préalable devant être aussi entrée lorsqu'on est en "running".
Et je me demande même s'il n'y aurait pas moyen de forcer un "default", là :
property Loop: integer read FLoop write SetLoop default -1; // -1 no, 0 forever, 1 once, 2 twice, ...
Comme ça le composant arriverait avec FLoop positionné à une valeur et le code n'aurait plus qu'à passer une fois une "value", la bonne, celle voulue en tenant compte de ma remarque ci-après et roule ma poule !
Nan ?
Envoyé par
pedestre
Cela m'étonne quand même puisque le composant TMPlayerContol utilise mplayer (du moins, je le pense) et l'utilisation de mplayer en ligne de commande avec loop (il suffit de faire suivre le path du fichier à jouer de "-loop xx") fonctionne sans problème aussi bien avec xx=1,2,.. qu'avec xx=0...
En fait, pour bien comprendre ce compteur de loops, il faut remplacer dans sa tête le mot "loop" par le mot "pass", en tout cas c'est ce que je constate en LdC sous Linux : si je mets -loop 1 c'est comme si je ne mettais pas l'option : ça joue le fichier 1 fois (= 1 pass) ; par contre, si je mets -loop 2, il va être joué 2 fois, et si je mets 0 ça ne s'arrête pas.
Ce qui est rigolo, c'est que si je mets -1 le fichier est quand même joué une fois.
Partager