Potential bug: VI class adaptation in non-malleable VIs (.vim)

[skaley]

Two unrelated classes (with no inheritance relationships) that have a dynamic-dispatch VI of the same name will mirror VI adaptation behaviors as if they were malleable VIs.

See attached code for an example (LabVIEW 2020):

Class 1.lvclass has dynamic dispatch VI "do.vi" (with no other inputs)

Class 2.lvclass has dynamic dispatch VI "do.vi" (with a numeric input)

Drop Class 1:do.vi on the block diagram

Drop Class 2 class constant on the block diagram

Wire Class 2 constant into the class input of Class 1:do.vi

The "do.vi" will adapt to the Class 2 implementation of "do.vi".

Moreover, the inputs of the "do.vi" will not update (ie show the numeric input) until the VI is saved/compiled.

This was also tested (and reproduced) with interfaces.

Is this intended behavior? If so, why? The classes have no relationship to each other and the VIs are not classified as .vim's.

[crcarlin]

I imagine at its heart this is intended behavior, except for the inputs not updating.

Think about other times you've used dynamic VIs when class type became significant.

For example, given children A and B of the same parent, if I make an array of A and then add an instance of B to the array, the wire type coming out of the array will automatically cast to the parent. Any dynamic VI operating on members of that array will also update to verify that they can work on the parent class.

LabVIEW recomputes these dependencies as you change things on the block diagram to both see whether the vi is breaking and to give the programmer feedback on what it thinks they're doing.

I don't think it's surprising that the vi updated in your example. But yes, it might be a bug that the connector pane wasn't updated with the rest of the VI.