[Bug] Controls created from primitives have the wrong default value

[Darin.K]

I feel like the scene in South Park where Kyles mom is in the Principal's office and the Principal asks "Good morning, what seems to be 'cheesing' you off today?"  Here is what is cheesing me off today:

When you create a control from a terminal in a primitive the default value of the control is not transferred to the created control like we are used to from subVIs.  Oh the label will certainly make you think that it is since it seems to be considered good style to write a small exposition about the default value inside parentheses. 

For example, drop 'Obtain Queue' onto a BD and create a control from the max queue size terminal.  The created control has the value -1 like you would expect, and the label says "max queue size (-1 which means the queue created in this case has unlimited size.  That seems like a reasonable thing to do)".  OK, maybe my memory is not clear on the actual label, but something like that.  Now from the fact that the default value of the terminal is '-1', and the label contains (-1 blah blah blah), and the current value is '-1' you may suspect that the default value of the control is '-1', but you would be wrong.  It is '0' the I32 default value.

This does not come up more often because 1. most default values tend to be default defaults (ie. false, 0, '') 2.  Usually I create constants first and change them to controls later which transfers the default value.

My recent encounter was in a VI that worked until I inlined it and then stopped working.  Man that was hard to diagnose.  I was like WTF do you mean I can not create a queue of size 0, I have a control with a value of '-1' sitting right there!  Finally I realized that inlining fed in the default value and then I tried 'reinitialize to default' and to my surprise saw the value change from -1 to 0.  What? What? What?!

[STASHkal]

So it looks like you are correct and that behaviour only exists with primitives.  I checked out the TCP and notifier VIs and they show the same thing.  However DAQmx VIs retain their values (although the values I checked there were timeout values).  

Definately worth noting so that I dont reinitialize into those states!!!

[STASHkal · Accepted solution]

Darin.K,

I thought you might like to know that I filed Corrective Action Request - #441061 in response to this forum post.  R&D is now aware of the issue.