le 11-18-2013 04:04 AM
@ouadji wrote:
Labview estime donc qu'un fil brisé des deux côtés manquerait quelque peu de Noblesse.
Remercions le d'être magnanime, et de nous faire grâce d'accepter un seul côté brisé.
Cette phrase est magnifique.
Par définition, j'ai du mal à voir l'inerret d#un fil sans type. En cas de placement d'un terminal, il faudra re-connecter les deux côtés du fil, soit deux fois plus de travail. Autant le supprimer 🙂
le 11-18-2013 09:09 AM
En plus, un fil sans rien des deux cotés n'est donc assigné à aucune "variable" coté C++, donc il est logique qu'on ne puisse pas le placer dans une "structure"
11-18-2013 09:19 AM - modifié 11-18-2013 09:20 AM
Quand je désire modifier une partie du code (faire un petit test vite fait) et en même temps conserver "dans un petit coin"
le code d'origine ... je sélectionne cette partie du code, j'en fait une copie ("ctrl-drag") et je l'entoure d'une structure disable.
Si la modification "tourne mal" ... je peux récupérer facilement le code d'origine.
J'entends par là ... que je garde sous les yeux une copie du code de départ ...
que je peux ainsi facilement reconstruire comme à l'origine.
" ... j'ai du mal à voir l'intérêt d'un fil sans type ... il faudra re-connecter les deux côtés du fil, soit deux fois plus de travail "
non ... je ne reconnecte rien ... car je ne réutilise pas réellement cette copie du code d'origine (si la modification ne fonctionne pas)
Je reconstruis le code en regardant le code d'origine que j'ai mis de côté.
la présence de TOUS les fils, me permet de voir exactement "quoi était connecté à quoi" dans le code d'origine.
Si on efface les fils (brisés d'un ou des deux côtés) ... il ne reste plus qu'un amas de fonctions,
... le mode d'emploi pour recabler ces fonctions "comme à l'origine" à disparu.
Donc, un fil sans type, brisé des deux côtés, à toute son importance (aussi).
11-18-2013 10:29 AM - modifié 11-18-2013 10:31 AM
Salut,
Pour ma part, le comportement ne me choque pas vraiment. Toi qui a pas mal touché au scripting, je suis sûr qu'il y a une explication derrière tout ça.
De mon point de vue, j'imagine que le scripting utilise les noeuds pour définir le code qui se trouve à l'intérieur de la structure, et dans le cas d'un fil qui n'est connecté à aucun noeud, cela doit passer à la trappe!
Cependant, je ne considère pas que cela soit un bug, dans le sens où c'est plutôt ton diagramme qui est bugué si il y a un bout de fil qui n'est connecté à rien, je ne vois pas l'intérêt de le conserver dans une structure disable, et donc un Ctrl-B est tout à fait propice!!
Quand je désire modifier une partie du code (faire un petit test vite fait) et en même temps conserver "dans un petit coin"
le code d'origine ... je sélectionne cette partie du code, j'en fait une copie ("ctrl-drag") et je l'entoure d'une structure disable.
Tu ne le sais peut-être pas, mais tu n'as aucunement besoin de déplacer ton code que tu désires modifier. Et c'est là ou la structure disable prend tout son intérêt.
Ta structure peut accepter plusieurs sous diagrammes, dont un seul peut être activé à un instant T. Tu peux donc superposer plusieurs solutions de codes tests, qui auront des entrées et des sorties communes, sans supprimer les autres tests précédents!!
PS: Si tu souhaites changer de sous-diagramme actif, clic droit sur le sous-diagramme en questions et "activer le sous-diagramme"
A+
Olivier L. | Certified LabVIEW Developer
le 11-18-2013 11:02 AM
petite précision (déjà faite, mais je reprécise)
Une structure_disable ne refuse pas de désactiver un fil sans type (qui n'est connecté à rien)
Le problème vient de la structure elle-même et non du fil ... j'explique :
quand tu étires une structure_disable pour "englober" un fil sans type,
la structure_disable "refuse" de prendre ce fil sans type "dedans" ... le fil reste "derrière" (en dessous)
et comme il est "derrière", la structure n'agit pas sur lui.
mais ...
si tu fais la manip "inverse", et que tu places toi même le fil (sans type) dans la structure,
alors ... le fil est bien dedans, et le fil est désactivé ... le vi n'est plus broken.
donc, la structure_disable est tout à fait capable de mettre OFF un fil sans type.
mais ... elle refuse de l'incorporer quand tu étires la structures.
Pour le reste :
mise à la masse réglementaire Olivier ! Echec et Mat ! ![]()
c'est fou comme on va en profondeur dans certaines choses, et que l'on (je) passe à côté de choses simples et élémentaires.
Je n'avais jusqu'à présent jamais regardé cette Structure_Disable avec attention. Juste pour mettre "OFF" certaines parties du code,
de temps en temps, sans plus, et pas souvent à vrai dire.
Je viens de m'apercevoir que cette structure peut avoir plus de deux sous-diagrammes,
et que je pouvais renommer ces sous-diagrammes comme je voulais, passer de l'un à l'autre,
avec toujours un seul "actif", que je choisis moi même.
Ne tournons pas autout du pot, je pense que c'est ma plus grosse "mise à la masse" depuis bien longtemps ![]()
Tu viens de me faire découvrir cette Structure que je n'avais jamais réellement regardé.
C'est un outil extraordinaire !
Il y a des moments comme ça, de grande solitude ... ![]()
le 11-18-2013 05:02 PM
voila, j'ai eu le fin mot de l'histoire par notre ami "altenbach".
Ce n'est pas une question de "fil", mais bien de "structure"
Que ce soit un fil "normal", un fil brisé d'un côté, ou un fil sans type (brisé des deux côtés) ... le problème est le même.
et ce comportement n'est pas spécifique à la Structure_Disable ... mais commun à toutes les structures.
soit,
une Structure, quelle qu'elle soit, n'autorise pas, en l'étirant, d'incorporer un fil (uniquement un fil) à l'intérieure d'elle-même.
Un fil "en l'air" étant "aussi" un fil ... la structure_disable (comme toutes les structures) ne l'accepte pas.
et donc puisque le fil reste "en dessous" ... pas de disable pour ce fil.
Je parle bien "en étirant" ... et pas en plaçant le fil soi-même à l'intérieure.
Il y a même une idée-proposition à ce sujet. (drag et CTRL-drag pour permettre les deux comportements)
OUF, la Dignité de notre fil brisé n'est donc pas en cause ! hello Luc ... ![]()