Stephen >The VI in LabVIEW that just returns a constant is compiled by our >compiler to be equivalent to having that constant directly on all the >caller VIs. The VI is not a function call, but merely a syntax vehicle for >getting one value out to lots of places across many diagrams.
Thank you, that puts to rest my objection quite nicely. I admit to not having read the user manual or online performance tuning info - is this explained somewhere? Perhaps in the same document that explains conditions for data forking vs inplaceness into and out of subVIs? >Instances of a typedef do not change their value when the default value of >the typedef changes. Nor would you want them to 9 times out of 10. Stick >with the VI returning a constant. Dang good point. I'd overlooked that, what a trap. >Is it easier to drop one constant [from the palette or file system] and >then select which subpiece to use than it is to just select which constant >you want [from the palette or file system] in the first place? I'm not >opposing your general comments that a simpler way to define and then drop >constant values would be useful, I just don't think that the proposed >solution goes very far toward simplifying the situation. It's not only about editing convenience, surely. The issue to me is clarity and reviewability on the diagram. Succinctness is king, so getting rid of the unbundle is desirable. Agreed, not essential, but desirable. Blair
