Discussions au sujet de NI LabVIEW
Conditional Disable Structure (comportement)
Une structure "Conditional Disable" accepte une condition comportant un Symbole qui ... n'existe plus.
Ce symbole a été créé, il "existait" ... mais il a été supprimé.
Une fois supprimé, les structures qui comportaient ce symbole dans leur condition ne génère aucun "code broken"
..... et labVIEW se base alors sur la "condition par défaut".
oui ... c'était une option (bof) ... mais est-ce la bonne ? trouvez-vous ce comportement " très sain " ?
Pour le moins ... générateur de pièges possibles à l'infini pour le développeur ... et surtout si le projet est développé en équipe !
Un Symbole qui n'existe plus devrait placer "broken" tout code ou VI le comportant.
L'option "par défaut" est valable quand le symbole ne peut pas être mis en concordance avec une valeur valide.
Mais ici ... c'est le symbole lui-même qui n'existe pas (plus) ... et LV continue de le "gérer" comme s'il existait.
votre avis ?
je suis comme toi j'aime pas!
en plus c'est la merde pour retrouver les structures qui utilisent le symbol en question. Donc le supprimer permetterait de le trouver.
Donc d'accord avec toi, même si sur le principe le cas par défaut permet au code de fonctionner.
A+
@Luc :
en plus c'est la merde pour retrouver les structures qui utilisent le symbol en question
Find and Replace .... je viens de tester, ça fonctionne.
encore faut-il se souvenir du nom précis du symbol .... qu'un autre a supprimeé il y a 8 jours et qui bien entendu est en congé. 
ceci dit :
même si sur le principe le cas par défaut permet au code de fonctionner.
Oui, dans la même idée ... pourquoi ne pas prendre des "choix par défaut partout" ... comme ça on aura jamais de broken.
Perso ... je suis totalement réfractaire au comportement de LV en pareil cas (et au choix des développeurs de LV)
Il est anormal qu'un code soit ok alors qu'il contient un symbole qui n'existe plus.
Une structure "conditional disable" qui contient un symbole qui n'existe pas devrait être broken.
@Eric :
heuu ..
suffirait de comparer la dite chaine à l'ensemble des chaines définissant les symboles déclarés,
et de s'apercevoir que la chaine, donc le symbole, n'existe pas.
Quand on fait un "Get Value" (noeud de méthode sur la Ref d'un VI) avec un nom de Contrôle qui n'existe pas ... le code génère une erreur.
Il a donc bien fallu qu'a un moment donnée labview fasse "le tour" des Controles et de leur nom ... et se rende compte que le dit nom est inconnu.
Le Noeud "Get Value" échoue car une "entrée" est inconnue.
Semblable comportement est tout à fait envisageable avec une structure "conditional disable" ....
en ce ... que le nom d'un symbole est une entrée de la structure.
Il faut différencier une erreur d'exécution et une erreur de compilation.
ok Eric ... je comprends parfaitement la différence entre les deux.
Je comprends que le compilateur ne puisse pas gérer cette histoire de symbole non existant. (c'est logique)
Ce "cas" ... est un cas particulier ... qui ne s'intègre ni dans la gestion des erreurs par le compilateur,
ni dans la structure globale de gestion des erreurs lors de l'exécution.
Ce choix ... (de prendre le code par défaut quand le symbole n'existe pas) ... me semble, lui aussi, être un choix par défaut" 😉
Je ne suis pas persuadé que les Développeurs de LV eux-mêmes trouvent se comportement parfaitement approprié.
Pour gérer la chose "autrement", il aurait peut être fallu créer, ce que je nommerai ... une autre classe d'erreurs
et ce, " u n i q u e m e n t " pour cette structure "conditional disable".
Il me semble que l'origine de ce choix est dans cette direction.
