Wrap in Error Structure.llb

[smithd]

Author: smithd (NI)

Wraps code in a case structure, ties up error wire to the selector, and tries to wire any obvious things up in the error case.

uses code from this: https://decibel.ni.com/content/docs/DOC-43699

and this: https://decibel.ni.com/content/docs/DOC-22469

Before:

After:

_

Attachement is saved in LabVIEW 2015. For install instructions, go here.

Edit 8/18: Per mercer's suggestion, unwired terminals are now set to use default if unwired.

[AristosQueue (NI)]

Is there a reason that you decided to not set the "Basic Objects" output tunnel to "Use Default If Unwired"? I would have made that the default behavior myself.

[smithd]

just didn't think of it, I suppose you'd have to validate that the code made the right choices anyway so you're probably right. I'll make that change.

[tst]

I would actually be leery of changing this. While I can foresee wanting the default on many such cases, I think I would prefer having to make a conscious decision for what the value should be (and in many cases, I actually prefer having an explicit default value so that if additional cases are added, the code breaks. This isn't relevant for error cases, but their data type could change).

Setting it to default is only a couple of clicks if that's the result I actually want, so I would vote to leave it.

[vishots.com]

I agree, make outputs default if unwired. Of course having it user configurable is better, but not sure if there is an easy way to make an options window for these plugins. Was this ever considered for the framework?

[AristosQueue (NI)]

Michael Aivaliotis wrote:

but not sure if there is an easy way to make an options window for these plugins. Was this ever considered for the framework?

                   

Checking the LabVIEW config file is easy from G code. Use the VIs in:

     resource\dialog\lvconfig.llb

For the most part, though, I felt that options would better be handled either

a) by installing different plug-ins rather than creating some sort of configuration system OR

b) by telling users "if you want different behavior, open this VI, change this Boolean/enum constant, and save your VI."

Building any sort of common shortcut configuration pane didn't make a lot of sense to me. Most plug-ins that people proposed didn't need that, and if it wasn't an integrated part of Tools >> Options, I doubted people would ever find it.

[smithd]

could probably just store and yank stuff from the lv ini, but then these are all downloaded per-user anyway, so maybe it would be easier to just have a second copy with the appropriate code disabled.

[vishots.com]

I would like to make a suggestion for the next version of this plugin. The basic functionality is fine, however, the case structure created always needs fixing after the fact. The case structure is sized so that it's touching all the objects inside of it. it would be nice to size it so that there is at least a 15-20 px gap around the inside from all objects.