LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
Showing results for 
Search instead for 
Did you mean: 

Context help on coercion dots to see what is the expected type

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.




Dany Allard

Active Participant
You can always find the expected type by looking at the context help on the output wire.
Knight of NI

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?)

Message Edited by altenbach on 06-11-2009 03:06 PM
Active Participant

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!

Message Edited by InternationAL on 06-15-2009 08:16 AM
Knight of NI

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. Smiley Wink

Knight of NI

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)


Message Edited by altenbach on 06-15-2009 02:14 PM
Trusted Enthusiast



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).




Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
Knight of NI

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. Smiley Happy



Active Participant
Status changed to: In Development
Grant H.
National Instruments
LabVIEW Product Marketing Manager
Active Participant
Status changed to: In Beta
Grant H.
National Instruments
LabVIEW Product Marketing Manager