Leaderboard

Feature. That kind of magical backpropagation is rare in LV but a few nodes have implemented it. There's a lot of internal debate about how good an idea it is. Myself, I would rather the type terminal be a required input.

While I agree 100% with this, I'm still on the fence. If there's a 'type' input, my personal preference is to be explicit and wire it up. But, then again, the fewer replacements I have to make if I change types later, the better. When it comes to remembering to modify the data originator, a broken run arrow in the receiver won't help my brain synapses work any better unfortunately. So, rather than vote bug or no-bug, I'd rather just push for consistency; Either give me the "magic" everywhere, or none at all. The inconsistency can definitely be cause for confusion:

Here's the scenario to create a bug: change the interface of the VI with banner "Files" and wired enum "Save Cues" to have a string filepath instead of a Filepath filepath (perhaps not the best example... consider changing say a DBL to a U32). Yet that change was not propagated back to the message sender, whatever is stuffing that queue. Now, you've got a bug that manifests itself as a run-time bug. Whereas, if the Variant to Data had the Filepath wired as its type, that case structure above would have broken when the "Files" VI ConPane was changed. Sure, you could change the Variant to Data type within that case and still forget to change the message senders, but since you're in the domain of changing message datatypes, you're much more likely to remember to change the senders also. Whereas, in the current implementation above, a change to the ConPane of the "Files" VI might not necessarily trigger the correct synapses in your brain to also change your message datatypes. I guess in a nutshell it just simplifies the mental ruleset and memory stack size required of developers when you're able to depend on the broken run arrow and compiler messages. And that probably means fewer possibilities for creating bugs.

I have the same issue. It's not changed by <LabVIEW>\resource\dialog\lvconfig.llb\LV Config Write Numeric (I32).vi or <LabVIEW>\resource\dialog\lvconfig.llb\LV Config Write String.vi It's changed just before the 'Getting Started Window' is shown It's changed when I open a project from the GSW It started recently. I suspect the f2 patch for 2011 (however my startup window says I only have the f1 patch installed) I have the following providers installed: ADDQ Symbio GOOP [*]It's stored as defaultConPane="4834" [*]I have WinXP with English OS with Dutch localization (a ',' as decimal sign) [*]LabVIEW 11.0.1f1 Ton

Although this "feature" is kind of cool, I believe the usage is a bit limited. What I do find magical about this function, however, is the following construct. Before discovering this trick I wrote a lot of unnecessary for loops.

Another thought on this matter: a broken run-arrow is your friend; the mentality of "avoid the broken run-arrow" to justify language features feels flawed (think: "auto-insert feedback node into cycles"). A broken run-arrow and strong, explicit typing is like a friendly heads-up at compile-time saying "you did it wrong". Compare this to the insidious manifestation of a run-time error, or even worse, unexplained or quirky behavior with no error, inadvertently introduced by automatic code mutations. The compiler constantly validates all syntax (yay!), whereas run-time, it's not so easy to exercise every execution path to flush out the bugs.