It could be nice to have a context help on coercion dots to see what is the expected type of the data that is supposed to be wired to. This way you can rapidly determine what kind of conversion to use to avoid the coercion dots.
That would certainly be helpful. However, it could get quite complicated for polymorphic functions or indicators that accept many datatypes.
For example if you wire a complex 1D array to a waveform graph, we get a coercion dot, but the accepted data type is a really long list, e.g. 1D or 2D arrays of DBL, EXT, I32, U8, waveforms, arrays of waveforrms, dynamic data, etc. etc.
I suggest to modify this suggestion a little bit and instead display the datatype to which the data is coerced to in each particular instance.
(GregS: I don't understand what you mean by "output wire". Where would that be in the figure above?)
Oops, I might have been still half-asleep when I wrote that :-)
I don't think GregS has made it clear how to do this, so let's have this suggestion added. I don't know how many times I've dropped a million conversion functions til I found the one that made the dot go away. It's that, or having to open help, look up the data type, then go back to LabVIEW and make the correct conversion. Either way is much more tedious than having the pop-up tell you the incoming data type and the coerced data type. Kudos!
Hey, why can't you click on a coercion dot and have an "insert conversion function" option that would drop the appropriate conversion function and wire it up? Even better!
A coercion dot is not always worse than the conversion function and there are cases where the coercion is actually faster and more efficient than the explicit conversion. (I'll have to dig out an example and I'm sure I have one).
I tend not to insert explicit conversion unless the output branches into several coercions. Especially with scalars, the difference is negligible anyway.
Here's a case where coercion is significantly faster than explicit conversion. The conversion forces another buffer allocation!(code in this example simply zeroes all negative values of a 2D array)
You are collapsing my entire foundation of data coercion in LabVIEW. You mean, I NEED to leave coercion dots on large datatypes??? It is distressing to think that I need to benchmark "bad" programming practice against "good" because the "bad" may be more efficient.
From the help file on coercion dots: "Coercion dots can indicate points where a VI uses more memory and increases its run time." From altenbach: "Coercion dots can indicate points where a VI uses less memory and decreases its run time."
Why does the compiler not interpret both snippets the same?
If you do not post a product suggestion within the next few days, I may... As a habit, I eliminate the coercion dots just to pretty up the diagrams (even on scalars).
Hi Jack, Since I did not want to hijack (no pun intended!) this idea thread with a much more fundamental discussion, I started a new discussion in the LabVIEW forum. Let's continue the discussion over there.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.