Re : XControl (question sur "data in")

[ouadji]

J'ai construit un XControl (indicateur)

(ceci dit, pas facile d'aborder les XControl ... pas beaucoup de docs, peu d'explications, Il faut chercher par soi-même)

J'ai besoin de lui envoyer 2 données ... un U32 et un booléen.

J'ai configuré "data in" (type def data 1.ctl) comme étant un cluster comprenant (1xU32)+(1xbooléen)

Unbundle dans le XControl ... ça fonctionne.

ma question :

Serait-il possible de ne pas utiliser de cluster pour "passer" mes 2 données au XControl ? ... il me faudrait alors 2 entrées.

Autrement dit,

"data in" me donne une entrée ... que je peux configurer en U32

Serait-il possible de créer une 2eme entrée de données au XControl ?

Je pourrais alors configurer cette 2eme entrée en booléen (via un 2eme type def).

et me passer du Cluster.

Cela ne me dérange nullement d'utiliser un Cluster d'entrée.

Simplement dans un contexte théorique et d'apprentissage de LV, je me pose cette question.

Merci à tous.

[DaHelmut]

Bonjour,

"Data In" défini le type de donnée de votre contrôle. Un XControl ne peut avoir qu'une entrée (et une seule sortie). Le cluster est la seule solution pour avoir directement vos 2 types de données pour l'entrée.

Pour passer des données "auxiliaires" vous pouvez créer des noeuds de propriétés il me semble, à vérifier.

Cordialement,

[ouadji]

Le Cluster est donc la seule solution pour "injecter" plusieurs data dans un XControl (du même type ou de types différents) ... ok, merci.

"... Créer des noeuds de propriété" ... ok, j'irai "explorer" de ce côté là également.

Merci Helmut.

EDIT

en fait je sais ajouter une entrée ... j'ai cabler une entrée en plus au XControl ... (pour "voir")

mais cette entrée n'est pas reconnue par l'event "data change" ... ce qui ne m'arrange pas.

Par contre une modif sur une des données contenue dans le Cluster est reconnue.

[DaHelmut]

Bonjour,

Un exemple ?

Vous ajoutez une entree via le connecteur du VI d'affichage du XControl ?

Cordialement,

[ouadji]

Oui.

j'ai ajouté une entrée (un booléen) sur le VI de base du XControl. (sans autres précautions ... pour "voir")

Ce booléen "entre" bien dans le XControl et "fait bien son job" ... mais ...

Le soucis est que "mon code" dans ce XControl se trouve dans l'event "Data Change".

.. et que ce "nouveau" booléen ne déclenche pas cet event (Data Change).

Ceci dit ... quand je provoque cet event via un changement de donnée dans "data in" (l'entrée "origine" du XControl)

alors "mon code" s'exécute AVEC le booléen (qui est donc bien entré dans le XControl)

[DaHelmut]

Bonjour,

Certes mais cela reste inutile pour moi parceque lorsque vous utiliserez votre XControl dans un VI vous n'aurez acces (sur le diagramme) en entree (indicateur) ou sortie (commande) qu'au type de donnees defini dans le control Data Input...D'ou le probleme d'evenement que vous soulevez...

Cordialement,

[ouadji]

absolument.

J'ai même essayé (on peut rêver ) d'ajouter mon entrée sur le schéma des connecteurs d'entrées/sorties du XControl (à gauche de l'icône)

... il accepte ... mais résultat final, aucune entrée n'est ajoutée sur l'icone (quand je l'utilise sur le BD).

Donc, oui ... pour plus d'une entrée (ou sortie) ... le Cluster.

J'aurai essayé. Maintenant "je sais" ... ça c'est le principal.

merci Helmut.

[Olivier-JOURDAN]

Bonjour ouadji,

je vois que tu es en train de découvrir les XControls, je me permets donc un ou deux conseils car s'ils sont puissants, la programmation de ces derniers demande d'être vigilant sur certains points.

1. Les XControls permettent d'ajouter du code à un objet
2. Ils sont très utilles pour "séparer" des parties de code dans un programme et éviter trop de duplication de code
3. Cela impose de bien faire la différence entre le développement du XControl et du reste du code --> ne pas confier au XControl des tâches autre que celle liées à l'affichage des données.
4. A mon avis le type de données lié au XControl doit être le plus simple possible et le plus proches des types de données habituelles utilisée dans LabVIEW.
5. Le type de donnée doit permettre à l'utilisateur du XControl de modifier les données affichées par le XControl, pas la manière dont elles sont affichées.
6. Pour modifier la manière dont sont affichées les données on utilisera le cluster "State", l'événement "display state change" et des propriétés
7. Il ne faut pas hésiter à s'inspirer des objets LabVIEW existant pour définir au mieux son XControl (type de donnée, propriété et méthodes).

Dernière chose, je pense que tenter de modifier le connecteur du Facade.vi est voué à l'achec car il faut bien être conscient qu'il y a tout un mécanisme "au dessus" de ce à quoi LV nous donne accès qui permet au XControl de fonctionner. L'interface entre ton XCntrol et cette surcouche est forcément clairement défini et ne peut pas être modifier.

Cordialement,

[ouadji]

Bonjour Olivier,

Toujours très chouette tes interventions.

Oui, en effet, je me frotte aux XControl, passionnant comme tout le reste.

Avant cela, j'ai touché un peu aux VIs Polymorphes ... une récréation à côté des XControls

Pour les XControls la doc est rare et peu approfondie sur le Net, il faut "y aller" par soi-même.

"Dernière chose, je pense que tenter de modifier le connecteur du Facade.vi est voué à l'achec"

Oui, bien sur ... "tout cela" est géré par LV en arrière plan (je l'ai parfaitement compris),

vouloir ajouter un connecteur d'entrée à un XControl ... autant vouloir ajouter un 2eme compteur d'itérations à une boucle For.

Je reprends tes remarques :

1) oui, ça j'ai compris.

2) ça je comprends moins.

    un XControl sert à créer un Control ou un Indicateur personnalisé, avec un comportement particulier.

    Mais ... pour "séparer" les parties de code ... je ne "sens" pas la chose.

    Cela ne me semblait pas être le "but premier" d'un XControl ... mais plutôt des sous-VIs.

3) super remarque.

4) comprends pas ... De toutes façons il m'est impossible d'utiliser un autre type de données que ceux repris dans LV.

5) et 6) super remarque ... à écrire sur le mur, derrière l'écran.

7) s'inspirer des objets LV ... ? ... à quels objets penses-tu (par exemlpe)

J'ai construit un XControl perso pour commander un afficheur 7 segments,

ça fonctionne tip-top, mais cela reste un XControl assez simple.

Pour le moment je regarde de près 2 exemples du Net ("LedXCtrl" de Aristos Queue et "BlinkingLed")

J'ai déjà fait connaissance avec le Cluster "state" et avec "Display State Change" ... je commence "à voir".

Pour les Propriétés et Méthodes que l'on peut ajouter à un XControl ...

J'y arrive ... la bête est juste devant moi, on se regarde

[Olivier-JOURDAN]

---

ouadji a écrit :

2) ça je comprends moins.

    un XControl sert à créer un Control ou un Indicateur personnalisé, avec un comportement particulier.

    Mais ... pour "séparer" les parties de code ... je ne "sens" pas la chose.

    Cela ne me semblait pas être le "but premier" d'un XControl ... mais plutôt des sous-VIs.

---

Imagine que les XControls n'existent pas et que tu aies à coder ton afficheur 7 segments dans un VI, c'est tout à fait possible. Imagine maintenant que tu aies à utiliser cet afficheur à plusieurs endroits dans ton code, cela va créer de la duplication de code. Imagine que tu aies à travailler en équipe avec un autre développeur, pas facile de partager le travail. Imagine encore plein d'autres situations. Maintenant pense à ce que t'apporte le XControl :Séparation du code spécifique à ton afficheur du reste de ton code. Test unitaire simplifié, partage du code simplifié, réutilisation de ton afficheur dans d'autres programmes simplifié...

---

ouadji a écrit :

4) comprends pas ... De toutes façons il m'est impossible d'utiliser un autre type de données que ceux repris dans LV.

---

En gros, j'essayerais d'éviter les clusters et de rester sur des types de données "simples" type booléen, numérique, chaines...

---

ouadji a écrit :

7) s'inspirer des objets LV ... ? ... à quels objets penses-tu (par exemlpe)

---

Il faut essayer de ne pas réinventer la roue. L'utilisateur de ton XControl voit celui-ci comme un objet LV qu'il pourrait trouver dans la palette fonction. Les propriétés, méthodes et autres fenêtres de configuration devraient se rapprocher au maximum des habitudes d'un développeur LV. Note bien que cette réflexion est très influencée par une optique réutilisation de code/toolkit (voir ici), mais un XControl peut également être utilisé pour répondre à un besoin plus "primaire" et faire l'impasse sur ce genre de considération.

Bonne continuation,