Adapt to Reference Input not enabled

[Dirk@LV]

Somehow a type conflict occured with my strictly-typed VI reference during development (LV 2012). So there are red dots on some in/outputs of the Call by reference node.
Consequently, I made sure that the correct VI interface type is selected (via "Strictly typed VIs" or "Browse by path"). No change. Then I tried to create new constants directly via right-clicking the terminals on Call by reference. The type-def constants are greyed out then, too (although I am sure there is nothing wrong with them). I also tried to replace the Call by Reference with a new one, it does not help.

Only if I place a new Call by Reference node on the block diagram and re-wire it, it is possible to create constants and connections without red dots. This is tedious, as I have a lot of VIs with some dots (which I suspect to cause some other trouble, so I'd rather like to get rid of the red dots).

The Adapt to Reference Input function on the Call by Reference sounds as if it could help, but it is always greyed-out. Any way to get it operational ?

D.

[tst]

I generally prefer to use a static reference to a specific VI in order to get the type, because that keeps it linked to the VI if the connector pane changes. You can try that to see if it helps. To do that, you drop a static ref, drag a VI into it, right click it and make it strict. I think you can even wire it directly into the CBR node to run the VI, although then you might as well run the subVI directly.

[Dirk@LV]

Thanks, TST, but that is not solving the problem. 

Actually I do it in a similar way in the real code: the ref is coming from an array of refs to (preallocated) clones of the VI, stored in a shift register. The refs are generated via Open VI reference using a static strictly typed ref and the x08 option.

When something goes wrong with some kind of type conflict, and ultimately one decides to do an in-diagram Replace with a new CBR node, one would expect that LV takes an empty CBR node, places it in the diagram, performs kind of "Adapt to reference" to get the terminals and re-wires all the existing wires. Instead, what seems to happen is that the replacing CBR inherits some information from the to-be-replaced, "defective" CBR and the problem persists. (Not always, but in this particular case.) 

This is another example that sometimes LV does not clean up things properly when VI references are involved, and conflicts propagate until one finally rewrites parts of code from scratch.

The Adapt to Reference Input function (via right-mouse click on the CBR) sounds promising from the wording, IF it wouldn't be grayed-out...

D.