Re : FP - control disabled

[ouadji]

Sur mon FP, j'ai besoin d'avoir UN Controle "enabled" (toto) ... et tous les autres "disabled".

Contexte : Je suis dans un sous-VI avec son propre FP ... mais je pilote la propriété "enabled-disabled" des Controles du Main.

ce que je fais pour le moment (et qui fonctionne)

a) Ref_VI_Main - Panel - Control [ ] - une boucle For avec le noeud de propriété "disabled" ... je désactive TOUS les Controles.

b) Je ré-active ensuite "toto" uniquement.

c) En sortie ... je récupère l'array Control [ ] (voir "a") ... et je ré-active tous les Controles ... et je ferme les Refs de Ctrl [ ].

"ça" fait beaucoup de code pour faire "un truc tout simple" (en tous cas, "graphiquement", ça prend pas mal de place)

question:

existerait-il une façon de faire "plus simple" ?

(je ne pense pas ... mais on ne sais jamais ...  )

[JB]

Pourquoi ne pas transmettre la référence du contrôle à désactiver au sous-VI par une entrée du connecteur de ce dernier ?

[ouadji]

Bonjour JB ,

Ce n'est pas "un" Contrôle que je dois désactiver

... mais tous ... sauf un.

(n'en laisser qu'un seul d'actif)

contexte:

sinon je mémorise des events sur la pile d'une structure event qui se trouve dans le Main ...

et quand je reviens dans le Main ... ces events "mémorisés" s'exécutent.

oui ... je pourrais utiliser la fonction "flush event queue" quand je retourne dans le Main,

mais j'aimerais ne pas utiliser cette fonction pour la compatibilité descendante.

[JB]

Ah oui, ce détail - qui n'en est pas un - m'a échappé !

[Eric.M · Accepted solution]

Quelque chose comme ça ?

[ouadji]

ah oui ... 

petite variante qui permet de "bypasser" le Controle qui ne doit pas être mis OFF ...  j'aime bien.

J'aime surtout ta façon (en sortie) d'indexer l'erreur (+ un merge), et non d'utiliser un SR.

merci Eric ... judicieux !

[Eric.M]

Le SR empêcherait l'exécution correcte des itérations suivantes si une erreur se produit, ce n'est pas souhaitable (ou alors il faut le gérer avec un terminal de sortie de boucle for) 🙂

[ouadji]

oui, oui ... j'avais compris.

La solution avec le "terminal d'arrêt" était ma solution pour ce genre de situation.

Je découvre "la tienne" ... et j'aime beaucoup également.

EDIT

après avoir re-re-lu ... "ou alors il faut le gérer avec un terminal de sortie de boucle for" ...

Je ne suis pas certain d'avoir bien compris ce que tu nommes "terminal de sortie".

[Kaleck]

Plop !
Je n'ai jamais vu de propriété d'un afficheur ou commande de face avant faire une erreur. A mon avis, il ne devrait pas y avoir d'erreur lors de l'exécution de ce code... selon moi ^^

Du coup la fusion d'erreur (qui n'est pas réellement une fusion car elle prend la première erreur trouvé dans l'ordre du tableau) n'est pas réellement utile. Donc on pourrait même utiliser pour l'erreur une sortie en boucle for de la dernière valeur ce qui prendrait moins de mémoire qu'un registre à décalage ou une indexation.
Le flux d'erreur serait donc ici juste un moyen de ne pas désactiver/activer les contrôles en face avant si il y a une erreur en entrée de VI.

Sinon ce type de fonction de désactivation de tous sauf d'une commande est souvent utiliser de mon coté pour initialiser un appareil. Le seul "bouton" au démarrage est "Initialiser" (pour connecter et préparer l'appareil) qui exécute un bout de code, puis une réactivation de toutes les autres fonctions qui dépendent de cette initialisation.