Please make it so that an unconnected bundle is an error. Below is an example of current behavior, where even though the bundle by name is disconnected on the output, it does not cause an error.
I wouldn't vote for a warning on the grounds that no customer I've ever visited has had "show warnings" turned on. Warnings are invisible. If it isn't an error, it doesn't exist. I'd back VI Analyzer or error... which reminds me... I need to post a new idea I had to the Idea Exchange... let me go do that...
I turned on Warnings for the first time due to this post, after thousands of hours of LabVIEW usage with it off. It provides so much garbage that I'm going to turn it off. That's my 2cents.
Edit: Don't get me wrong, it could be an excellent tool. The implementation of warnings makes them useless, unfortunately, because like elset says, "it warns me of a lot of things I don't care about"
Message Edited by JackDunaway (mechelecengr) on 09-08-2009 05:41 PM
It should be an error, just as having a local variable disconnected causes a broken Run arrow. Why are NI dragging their feet on this? Currently, a local variable set in Read mode will throw an error if it's not connected to something (to actually use its value). If this is considered worthy of throwing an error (and I agree it is), then so is the disconnected output of the Bundle or Bundle By Name function.
Another option to improve it (though not critical): Make the yellow terminals a different color when not connected. Maybe red - or better yet, make them flash (no color-blindness issues), though that would be a first for NI (and no, a flashing control on a running front panel isn't the same).
Also - regarding temporarily turning off an update by disconnecting the output as a troubleshooting step: Use the Diagram Disable or Conditional Disable structure, as it's more "visible" than this, and is easily swapped with the original, intended code.
Because there are a lot of things way more important than this. With infinite time and infinite staff, this would get addressed, but the truth is that this node has worked this way for 30+ years, and it isn't a burning crisis to fix (like some other issues raised on this forum) nor is it likely to drive significant upgrades. That is not to say this will never get fixed -- groups of nodes tend to get revisited every five to eight years and tweaks like this get included in those passes, when we've got enough work in one area of the code to justify the development effort.
Keep your eyes open at NIWeek 2013. I think you'll see where we're spending our development resources and approve.
