Annoying Polymorphic VI bug - VI selector expands to full VI name

[ErikL68]

I've got a VI loaded into a panel of my main vi from a Template VI (.vit file), and all the instances of a polymorphic VI in it have had their VI selector names changed from the short options I have saved in the main Polymorphic VI, e.g., "Elem-End", to the full VI name (minus the ".vi"), e.g. "[Station] - Enqueue - Element at End".  The various structures they're in (cases, while loops, etc.) all expand to fit them, but it nearly doubled the width of the block diagram in doing so, and made LabVIEW slow to a crawl for a good 30 seconds as it expanded them.

I'm using LV 2016 32-bit.

I was hoping to leave the selectors visible as the icons aren't perfect (I used text, which is barely readable). Ah well. Fortunately hiding them prevented the stretching of the block diagram at least.

[Hooovahh]

Yeah NI hasn't given the Polymorphic VI Editor much love in many years.  I mentioned bugs and issues with it in the past on the idea exchange and it was clear that NI doesn't see many people using it, and it is a thing that is only needed early on in development.  NI likely doesn't see priority in fixing something so few people use, and one that is mostly a UX issue but not broken in a fundamental way.  I too wished NI improved it but I have gotten around some of its issues by using a different polymorphic VI editor, along with scripting, and VIMs when possible.

[ErikL68]

Well that's unfortunate. I'm not sure I'm seeing this as an error in the Editor, but I suppose it's calling back to the editor and the editor is returning the VI name rather than the menu with the correct selection.

I guess I'll just keep the selector hidden.

[Matthias_T]

We have exactly the same problem. Most of the time it is recognised by GIT as a change. I have taught myself to give the polymorphic VIs a special name format. This way, when a commit is made, you can immediately see that LabVIEW has once again changed a polymorphic VI.

What I don't understand is, NI offers platforms like idea exchange and others, why such bugs are not fixed although they are reported. This is the second time I read there are too few users and therefore nothing will change.

[santo_13]

One main reason these bugs are not fixed ASAP is that NI already has a backlog of tasks to work on and these bugs are not critical enough to be prioritized to the top of the queue. Whenever you create a fix, a few hundred hours of effort is required to make it release worthy to the users and it is expensive looking at the value you get by fixing it.

This is typical in any Agile development process where you prioritize tasks from backlog based on the value it provides and not because it is just there.

[Hooovahh]

To be fair, NI in the past has prioritized idea exchange items based on kudos.  If something is impossible it doesn't matter how many kudos it gets, but even the things that are easy to fix need some attention or NI won't see a need to fix it.  The number of people that develop polymorphic VIs is low, so the kudos are low, so NI isn't very motivated to fix it.  I too find it frustrating.  Just kudo the things you find important, and post new ideas for things you'd like changed.

[billko]

One thing I can say about the Idea Exchange is that it is a major source of new features.