[Malleable VIs] Changing type of inputs

[PinguX]

Hello there,

I am currently creating malleable VIs, with inputs whose types are indirectly linked to each other.

For example :

input 1 = DVR on map

input 2 = key

My question is : when I wire only the "DVR-map", is it possible that the type of "key" automatically adapt to the map ?

Like the native "Remove From Map" below :

I played a bit with Type Specialyzation structure, but I haven't find how to make it, yet.

Is that even possible ?

[raphschru]

Hi PinguX,

Sadly, a VIM's input cannot adapt based on another input.

That would be a great feature if it was implemented though.

Maybe you could post an idea in the Idea Exchange.

This would require some thinking for how it would integrate in LabVIEW.

Regards,

Raphaël.

[Kyle97330]

raphschru is correct, malleable VIs do not work this way.

The "type specialization structure" works by just evaluating each frame in order, based on the inputs given to the VI, until it finds one where the VI's code is not broken.  That's it.  There's not any reverse data type propagation and implementing something like that would likely be very problematic.

If you're trying to make a VI that could adapt to just a few pre-determined input types, like if you knew you only needed it to work for 3 different types of maps, then you could get close to what you want with a polymorphic VI that is set to "Adapt to data type" when choosing which instance to display, but it sounds like that's not what you're going for.

Just in general, I would advise against getting too invested in VIMs.  The idea was good, but the implementation often fails.  I do use VIMs, but I recommend that if you do so you keep the complexity of them to a minimum (no nested VIMs, no classes in VIMs, keep file sizes of VIMs as small as possible).

[raphschru]

---

@Kyle97330 wrote:

I do use VIMs, but I recommend that if you do so you keep the complexity of them to a minimum (no nested VIMs, no classes in VIMs, keep file sizes of VIMs as small as possible).

---

I agree with Kyle on these points:

 - For nested VIMs, I also try to avoid them. When I was initially testing VIMs in LV2018, I often had broken wires resulting from nested VIMs not being recompiled when needed. It has improved in the last versions, but I still kept the general idea of keeping the complexity as low as possible to prevent LabVIEW from hanging / crashing / breaking wires;

 - I sometime have VIMs that take classes as input / ouput, but they are not very useful in this case since they cannot access the private class data, even if the VIM belongs to the class;

 - My VIMs are usually very lightweight and only contain the "malleable" part, whereas the actual functionality is called in a "Core" (non-malleable) SubVI that has variant inputs / outputs.

[PinguX]

Hello,

This confirms what I didn't want to face.

---

@Kyle97330  a écrit :

I recommend that if you do so you keep the complexity of them to a minimum (no nested VIMs, no classes in VIMs, keep file sizes of VIMs as small as possible).

---

Yup that's my goal. 4 small VIs (between 27 and 70 KB, 1 and 4 cases of type structure) to use any maps by ref.

(datalog file reference of object for key input is just a placeholder)

The reverse propagation of data types was for QoL when using the VIs. It is not mandatory at all. 

Thanks for answers !