Discussions au sujet de NI LabVIEW
Les micro-nuggets à la Française
Je suis totalement d'accord avec la solution de JB.
Je préfère également ne pas utiliser l'erreur comme source d'arrêt, surtout dans le cas où il y'a un log ou une remontée des erreurs.
Et la destruction de la référence à la fin est plus propre, car l'utilisation d'un timing peut être un peu aléatoire. Après, je conçois que dans le cas de sous VIs séparés, il est bien moins aisé de gérer ce cas de destruction de la référence.
Le but est le partage des manières de faire.
oui, oui ... moi aussi. Juste un échange de nos boîtes à outils 
c'est très chouette et très constructif.
Je vois ton code.
Avec un "retour" des lignes d'erreur avant le "Release", là, pas de soucis, ça tourne tip-top.
Pour être franc ... oui ... sur le principe, je préfère "aussi" avec une Notification. C'est plus "dans les règles".
Mais c'est vrai, que via l'erreur, ça fonctionne très bien aussi (et ça simplifie le code)
Le point faible avec la Notification d'arrêt est qu'il est plus difficile de rendre les boucles totalement indépendantes. (comme dans mon 2eme exemple sur le sujet)
Il faut être certain que toutes les boucles sont bien stoppées avant de faire le "Release"... et dans ce cas, pas moyen d'utiliser la ligne d'erreur comme confirmation d'arrêt.
Ceci dit, ce n'est pas impossible. Il faudrait une "Notification d'arrêt" dans un sens ... et une "Notification de confirmation d'arrêt" dans l'autre sens.
Il doit y avoir moyen de faire ça ... mais là, on arrive dans du code (inutilement) compliqué ! ... pour faire "ça", je change complètement de système d'arrêt et j'utilise un booléen dans une FGV.
"Set" pour le Master, "Get" pour les slave. Dans le jeu d'échec, j'utilise une FGV sur l'erreur ... et dès qu'il y a la moindre erreur (n'importe où dans le code) tout s'arrête, c'est très efficace (et facile).
Je te souhaite une belle journée JB et merci pour ton intérêt sur le sujet.
[edit] une belle journée pour Olivier également [/edit]
oui, les solutions sont multiples. Tes deux dernières solutions sont tout à fait efficace également.
bien ... que je n'aime pas trop l'idée de fait "aboart" après un délai (c'est un détail, chaque développeur à son propre feeling sur le sujet)
L'idée n'était pas de faire un exposé exhaustif sur toutes les bonnes pratiques pour stopper des boucles en //
mais simplement d'en donner "une" qui permet facilement :
- de cadencer, de stopper, et de stopper en interrompant la tempo de cadencement en cours.
Mais, au delà de "ça", j'aime beaucoup les solutions que tu as proposés.
(je taquine une dernière ... qui rencontre tous les avantages de la 1ere solution proposée :
- arrêt boucles multiples
- cadencement
- arrêt de la tempo de cadencement en cours
ET ... qui fonctionne avec le send d'une vraie info événementielle (et non un arrêt par le biais d'une erreur)
Pour comptabiliser le nombre de "sous-chaine" dans une "chaine"
Sans regex, sans boucle ... et point de vue vitesse, c'est très rapide.
Bonjour Michael,
oui, j'ai testé avec "%s" (approche qui me semblait également plus logique) ... mais curieusement, la vitesse maxi ne se trouvait pas là.
Sur une chaîne de 10E+6 caractères contenant 40% de chaînes à rechercher :
entrée array type = array U32 - %d = 0,57sec %s = 0,96sec
avec un format "%s", si tu veux retrouver le 0,57 sec, alors tu dois placer l'entrée "array type" avec un "array de string"
comme ceci :
rem : 0,56 / 0,55 ... les temps sont variables entre ces deux chiffres,
il n'y a donc pas de différence significative entre ces 2 chiffres (avec 0,93, là, oui)
Pour conserver la vitesse maximum et en même temps " l'aspect logique" ...on peut choisir "array string + %s"
(même vitesse que "array U32 + %d" ... mais "extérieurement" plus logique)
