In general, in case of an error, I use pass-through wires, not default values. The idea being that the error is going to be handled down the road and any VI in between should not mess up with any of the original data fed to the first VI generating the error.
I could see the point in having a way to create constants connected to all unwired tunnels in a given case, but generally, time saving occurs only if you have to do that for many cases, and then the obvious solution is to do it once for one case and just duplicate that case as many times as needed and modify only the values you need in the other cases. But that is clearly beyond what you are suggesting.
Take a look at what pops up in the Search for "Use default values if unwired" in the Idea Exchange Forum for many ideas (and links to other ideas) related to this topic. You'll see that this has been a heavily discussed topic.
This request has been explicitly rejected by multiple reviews of this feature.
As others have noted, creating all those constants and setting the tunnels to "use default if unwired" are functionally identical. The advantage of "use default" is that it is easier to just wire things across for items whose value does need to be preserved (i.e. pass-through refnums).
We have asked customers multiple times about default values for tunnels, and overwhelmingly they tell us they would rather have the VI broken and let them fix things up. One (of many) examples of this is the kudos on this idea which is to do the exact opposite for Event Structure.
I chose a different option when I wrote some of my right-click plug-ins that you can download ( http://ni.com/lvmenus ) for LV 2015, but that's my personal preference, and I figured in a plug-in that people can edit, they can choose to do what they want. If those plug-ins ever became a shipping part of LabVIEW, we'd probably disable the "use default if unwired" option.
Personally, I continue to be surprised that more people don't agree with us, patibandla. But that's the way it goes.
AQ, this request is for creating the constants on demand, not for the tunnel to output default values (at least that's what the image shows). Even I don't object to that idea.
It could still be dangerous if people create defaults for multiple tunnels and one of those shouldn't be the default, but because this is an explicit action taken by the user, I'm OK with that.
patibandla, as AQ mentioned, in LV 2015 you can write custom right click menu plugins. It's certainly possible to write one which will appear for tunnels with unwired values and will then create constants for all of them, so if you have 2015, you can write this yourself today. In earlier versions you can do this as a Quick Drop shortcut.
Quick Drop's Ctrl+D doesn't do it (just tried in 2014 SP1)
There are only two ways to tell somebody thanks: Kudos and Marked Solutions Unofficial Forum Rules and Guidelines "Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
The Quick Drop Ctrl-D shortcut currently does not work on tunnels. Do y'all think it should? If it did, I imagine we'd want it to only process the inner terminals of the selected tunnels on the currently visible frame of multi-frame structures.
If y'all think this would be useful functionality to add, let me know. As often as I use Ctrl-Space-Ctrl-D, I can see it being useful for tunnels too, I'd just have to re-train myself to know it's available.
Any idea that has received less than 3 kudos within 3 years after posting will be automatically declined.