Re : XControl (question sur l'initialisation)

[ouadji]

"Si l'utilisateur du XControl décide, après drop du XControl sur le FP de changer ce dernier ....."

Cette phrase m'interpelle.

1. mais avant, une question,

Un XControl pourrait-il intégrer les deux fonctions Control et Indicateur ?

Pas en même temps (bien entendu), l'un OU l'autre. (je pense que oui, pas certain à 100%)

2. Concernant cette phrase qui m'étonne,

Si le développeur fait en sorte que le XControl se positionne en Indicateur lors d'un drop,

c'est donc qu'il s'agit d'un XControl-indicateur. Dans ce cas pourquoi le ferait-on passer en Control ?

(Dans ce cas, personnellement, j'irais même jusqu'à le verrouiller dans "Direction Change")

Ou alors cet XControl peut être les deux, mais dans ce cas pourquoi le pré-positionner ?

3. "Le code du init.vi est fait pour être modifié" 

    C'est le genre de phrase que l'on ne trouve dans aucune doc.

    Maintenant, je sais que je peux, un pas en avant.

4. "facade.vi s'exécute dès qu'une instance du XControl est en mémoire" oui, j'ai remarqué ça (ça surprend au départ)

    "Par exemple modification de l'aspect du XControl en fonction du mode, exécution ou édition, du VI appelant."

     oui, via  <Display State Change / Container State / Run Mode ?>

     mais ... je ne vois pas quand cela peut être mis à profit ?

     Dans quel cas a-t-on besoin d'un XControl qui se comporte de façons différentes en Edition et en Exécution (?)

     Et surtout ... en quoi le comportement du XControl peut-il être important en mode Edition (?)

     (La, je sens que je passe à côté de qq chose d'essentiel.)

[Olivier-JOURDAN]

---

ouadji a écrit :

"Si l'utilisateur du XControl décide, après drop du XControl sur le FP de changer ce dernier ....."

Cette phrase m'interpelle.

1. mais avant, une question,

Un XControl pourrait-il intégrer les deux fonctions Control et Indicateur ?

Pas en même temps (bien entendu), l'un OU l'autre. (je pense que oui, pas certain à 100%)

2. Concernant cette phrase qui m'étonne,

Si le développeur fait en sorte que le XControl se positionne en Indicateur lors d'un drop,

c'est donc qu'il s'agit d'un XControl-indicateur. Dans ce cas pourquoi le ferait-on passer en Control ?

(Dans ce cas, personnellement, j'irais même jusqu'à le verrouiller dans "Direction Change")

Ou alors cet XControl peut être les deux, mais dans ce cas pourquoi le pré-positionner ?

---

Je me permet de te poser une question pour voir si je comprend bien ton blocage : As tu déjà placé sur le FP un "Numeric Control" puis fait un clic droit dessus pour sélectionner l'item "Change to indicator" ? Je pense qu'après cette manipulation, ma phrase devrait moins t'interpeller 🙂

Note bien que le seul objet LabVIEW ue je connaisse dont on ne puisse pas modifier l'état Indicateur/Controle est le Sub Panel, mais c'est aussi le seul objet qui n'est pas de terminal 😉 Tout ça pour dire qu'il e me semble pas conseiller "d'interdire" le "direction change".

---

ouadji a écrit :

3. "Le code du init.vi est fait pour être modifié" 

    C'est le genre de phrase que l'on ne trouve dans aucune doc.

    Maintenant, je sais que je peux, un pas en avant.

---

Comme tous les VI "abilities" d'un XControl (les abilities étant des VIs appelé à des moment très spécifique de la vie d'une instance du XControl comme init).

---

ouadji a écrit :

4. "facade.vi s'exécute dès qu'une instance du XControl est en mémoire" oui, j'ai remarqué ça (ça surprend au départ)

---

Ca surprend, mais c'est puissant 😉

---

ouadji a écrit :

    "Par exemple modification de l'aspect du XControl en fonction du mode, exécution ou édition, du VI appelant."

     oui, via  <Display State Change / Container State / Run Mode ?>

     mais ... je ne vois pas quand cela peut être mis à profit ?

     Dans quel cas a-t-on besoin d'un XControl qui se comporte de façons différentes en Edition et en Exécution (?)

     Et surtout ... en quoi le comportement du XControl peut-il être important en mode Edition (?)

     (La, je sens que je passe à côté de qq chose d'essentiel.)

---

 Si tu as installé ce package d'XControl, glisse le PaceHolderString sur un FP. En mode édition, tu peux faire un clic droit sur l'instance du XControl et faire apparaitre l'item More... Cet item permet de modifier en édition les propriétés du XControl (state.ctl) et modifier le comportement du XControl.

Cet item More... n'est plus disponible en mode exécution.

Il y a surement d'autre exemples, mais ils ne me viennent pas à l'esprit tout de suite.