Allow Creating Constant from Control/Indicator

[X.]

Not available in LV 2103.

Why?

Case study:

I may not have a local variable, a PN  or a wire for the type of constant I need in a specific portion of my diagram.

Therefore, since I cannot SEARCH for either a LV or a PN for fear of not being able to easily come back to that part ..., I need to be resourceful.

A simple solution (provided I know where to find it on the FP) would be to go to the FP, select the appropriate control and choose "Create Constant" in order to then be able to drop it onto the diagram (WHERE I want, not randomly, because that would kill the purpose of this suggestion).

Now I know that LV is schizophrenic and you can not let it understand that the FP and BD are basically one and the same thing, but still, I musn't be the only one to bang my head against that infrangible wall!

EDIT: of course, you can COPY the control and PASTE it on the diagram. I am talking about consistency in the Ctrl-Right contextual menu behavior throughout the IDE.

[crossrulz]

Interesting.  It wires the constant up if the original wire is broken.  If the wire is not broken, the constant is not wired.  Which is why Ravens and I haven't seen this (or at least never noticed it).

[X.]

Why don't we have a "Darin. K's suggestions" page yet? I tag mine with "X_Idea", you should yours with a public tag.

[AristosQueue (NI)]

> It wires the constant up if the original wire is broken.

The comment in the code makes it clear this is intended behavior from the developers (goes back further than the source code control records, long before I joined NI). If the wire is broken, we assume that you're creating the constant in order to fix it. Either adding the constant directly fixes the wire (in the case where the wire has no source terminal yet) or after the contant is wired in, you'll be deleting the remaining broken segment, as is the case when you're changing code over during a refactoring.

[X.]

I had the case illustrated by Darin. K in mind all along. This is where the user doesn't want to fix the problem, but wants to do something totally different instead, namely go around a limitation where there is no simple way to create a named cluster by simply bundling elements together. I think there is an idea about this somewhere...

[crossrulz]

X, someting like these two ideas (which would be my preference):

Adaptive Bundle By Name

Allow cluster type to propagate upstream to "bundle" primitive

I think I found another one that you are more likely looking for, but I don't feel like doing the search again.

[Darren]

 Any idea that has not received any kudos within a year after posting will be automatically declined.