Discussions au sujet de NI LabVIEW
Erreur dans l'aide?...
Tous les passionnés de LV (j'en suis) sont par essence des défenseurs inconditionnels de l'outil, des Don Quichotte. Nous sommes tous prêts à nous couper un bras pour trouver une justification saine et logique au moindre comportement qui semble ne pas l'être. Et je dois bien admettre que dans 99% des cas, il est possible de replacer tout comportement dans le cadre d'une même pensée unique. Ceci dit, en l'occurrence, si on intègre l'ensemble de ce post, même en me coupant un bras je n'arrive pas à en sortir glorieux. Le comportement d'une Table est le bon, son premier indice, l'indice n°0, l'indice colonne, est en première position. Un Tableau, quel que soit le nombre de ses dimensions, devrait se comporter de la même façon ... et de même pour toutes les fonctions Tableau ... l'indice colonne devrait immuablement être le premier, ceci malgré l'extensibilité vers le bas de ces fonctions. L'aide contextuelle est conforme à cette logique, mais la réalité du code est différente. Le remaniement de LV à ce sujet est des plus improbable, la compatible descendante serait une catastrophe. Cela n'interdit pas de raisonner et de constater. Le minimum serait peut-être de rendre l'aide contextuelle conforme à la réalité. Une aide contextuelle complète, claire et précise à ce sujet, aurait le mérite de lever toutes les ambiguïtés pour les utilisateurs (débutants), et ce pour un impact bien moindre que de modifier l'ensemble du comportement de LV lui-même.
La remarque pourrait-elle être remontée ? NI pourrait-il se pencher sur cette idée ?
merci .imb pour cette différence entre Tableau et Table (je n'avais jamais remarqué), ainsi que ton lien associé (intéressant / surprenant)
@AllanB54 wrote:
Mais comment faire remonter la remarque justement?!
Je vais faire remonter vos commentaires, je travaille chez NI.
Malheureusement, c'est vrai qu'il est très improbable que la modification soit faite (du moins dans la génération actuelle de LabVIEW, il faudra que je vérifie le comportement dans LabVIEW NXG).
@Allan: " mais comment faire remonter la remarque ? "
La voie royale pour "proposer" (quoi que ce soit) est le forum LabVIEW Idea Exchange. Sur ce forum tu peux y faire part de toute modification qui te semblerait intéressante pour "améliorer" LV. L'équipe de développement NI est particulièrement attentive à ce forum ... réellement, et cela fonctionne ... régulièrement, certaines propositions sont évaluées et au final, intégrées à LV. J'ai déjà eu moi-même le cas, et franchement, chapeau pour l'interactivité NI-utilisateurs. Encore faut-il posséder un niveau d'anglais suffisant pour pouvoir décrire de façon précise ce que tu proposes.
Merci beaucoup à .imb (de chez NI) de bien vouloir faire l'interface vers les couches supérieure. 
Le cas (particulier) de l'auto-indexation (qui "prélève" en premier lieu la dimension la plus grande) n'est pas incompatible, dans l'absolu, avec l'ensemble des remarques reprises dans ce post. Pour un Tableau à N dimensions, l'indice colonne peut parfaitement rester immuablement l'indice zéro. Pour le tunnel indexé, ce n'est qu'une question de comportement ... et donc simplement la façon dont ce tunnel à été programmé ... un tunnel indexé n'étant jamais que du code. En passant au code du tunnel la dimension N du Tableau, celui-ci pouvait très bien prélever cette dimension N en lieu et place de la dimension zéro actuelle. Et quelque part, il aurait été plus logique qu'un tunnel indexé prélève la dimension N (et non zéro). Le comportement actuel est "un choix" de la part des concepteur/développeur de LV (que je respecte) ... mais un comportement différent aurait été (à mon sens) parfaitement envisageable. Il est possible que le choix du comportement actuel ait permis un "code-tunnel" plus simple, plus compact et donc plus rapide (la rapidité étant un des atouts de l'indexation sous LV).
Tout cela pour dire quoi ?
Que je trouve la remarque de MaximeR parfaitement correcte, il est évident qu'une indexation doit prélever l'objet de dimension supérieure, je suis d'accord avec lui. Mais cela n'est pas incompatible avec une vue différente concernant l'attribution des numéro d'index ... bien entendu le tunnel indexé devrait, lui aussi, être adapté à cette vision différente des choses.
Ce post est-il de l'ergotage de puriste ?
oui, pour les utilisateurs qui envisagent en principal la finalité. Ce sont les plus nombreux, les professionnels de la programmation, dont le but est de répondre à des besoins, dont le but est trouver des solutions.
non, pour ceux qui peuvent se permettre de fantasmer sur des concepts de logique de fond.
(je programme juste pour le plaisir, donc je peux me permettre "ce luxe".)
) ... point final en ce qui me concerne. 
Bon code à tous.
