Leaderboard

thank you Rolf and SmithD, this helps. I think he is making some progress now by compiling on the cRIO although it's not working yet. I've informed him of this thread and will update if we can get it working!

I"m not sure it's conflation only. Many seem to be focused specifically on the fact that LabVIEW GUIs don't look like the latest hyped Office version, which of course will be again different over 2 years when yet another modern style design guide claims that everything needs to be high contrast again, or maybe alpha shaded with psychadelic animations (you need to find reason to sell high end GPUs to spreadsheet jugglers). Your second point is indeed one thing I feel LabVIEW could have made more advances. Dynamic control creation while indeed complicated to get into the dataflow paradigma of LabVIEW would be possible with the VI Server reference model, although it would not be classical dataflow programming anymore for such GUIs at least for the part that you use such dynamic instantiation in. XControls was a badly executed project for an in principle good idea, Splitters are a God send for more dynamic UIs together with Subpanels, but to try to edit splitters once they are placed on a frontpanel really can be an exercise in self control. In doing so I feel the same frustration as when I'm forced to edit some Visio drawings. The editor almost seems to know what you want to do, because it always does the opposite of that, no matter what.

Yes, I remember when this feature came out. I was very happy about it. Then I foolishly trusted it. Then I discovered a bug in this feature by accident. The auto-mutation failed. So now I was burned again by a feature that I was suppose to trust to solve the original problem. You see why I'm shell-shocked.

It's definitely fixed in LabVIEW 2016, although it can be a pain. LabVIEW will break all VIs where a cluster or enum typedef is present whose elements contain values that it can not mutate unambigously. And you get a dialog that lists all those locations and it shows you an old and new view of the data (with a best guess for the new value) where you have to edit/select the new data value and then confirm to use that from now. This applies to enum values that somehow changed their name (or were removed) as well as to cluster elements with different name or a reordering that makes it impossible to reassign the old values unambigously. Simply removing an element in a cluster or enum does however leave the other elements data intact, so it does a reassignment based on label/name rather than just oridinal order of the data. It's a huge improvement, although it can feel a bit painful at times as an entire hierarchy can seem to break completely because of a minor edit in an enum label.