Visual indication that VI will run even on error

[fabric]

This has been discussed in various places like here, but I couldn't find an idea for it...

There are quite a few LabVIEW primitives which will always run, even if presented with an error on the "error in" terminal. Common examples are "Close Reference" and "Close File". 

What would be really useful is to have some kind of visual indication of this behaviour. Ideally this would be a simple marking on the VI icon which could be easily replicated by LV users when we create such VIs ourselves. (It could possibly even be an option in the icon editor!)

 

Currently the only indication that a VI will run on error is this discrete line in the VI help:

I believe a visual indicator would be much more fitting for LabVIEW as a visual language, and would make this behaviour far more obvious to LabVIEW users.

[vitoi]

Have to be careful. If there are too many special indicators, it can get a bit busy. 

[fabric]

>> Have to be careful. If there are too many special indicators, it can get a bit busy.

Agreed - but luckily this applies to relatively few VIs.

[SteenSchmidt]

I use a small black on white arrow to indicate that a VI runs even when there is an error on error in:

In my experience we should be careful with colors on glyphs that indicate "standardized" behaviour. Especially in this case we could argue both for a green or a red glyph, so therefore I chose a black one some time ago. No transparancy and no see-through pixels either, to keep it clean. The purple border indicates a reentrant (shared) configuration by the way. Reentrant (preallocated) has a red border, while non-reentrant VIs have a black border. The border color is part of my company's design style guide, the glyph is my own (but as many other similar things might be to find in that style guide soon ).

But kudos from me for an indication of some sort. I'd also like better access to info about which of the built-in primitives are reentrant, and which are not.

Cheers,

Steen

[AristosQueue (NI)]

This idea comes on the heels of a long and intense debate about this sort of thing inside R&D. Based on all of the data collected during that process, we're now strongly leaning toward a standard table of glphps/tags that appear in the Context Help but NOT on the block diagram for things like run-even-on-error, reentrancy, inlining, etc.  We may create a standard glyph that means "run even on error" that would be user-discretion to add to the actual diagram icon (NI obviously would follow that convention and add it to our primitives/VIs).

The key problem is space on the icon and room for LV to automatically annotate the icons with our own glyphs. Putting even a single glyph may obscure a key part of a user's icon. And there are so many attributes we might consider annotating a node with, it could get very noisy in that small space.

Thoughts?

[JackDunaway]

---

@aq wrote:

...we're now strongly leaning toward a standard table of glphps/tags that appear in the Context Help but NOT on the block diagram... Thoughts?

---

Awesome - this would be really cool. I made a similar comment on a similar, popular Idea, and still think Context Help is a great place for the IDE to *automatically* enumerate a VI's settings/properties/attributes/behaviors. Kudos to this Idea for bringing awareness to a need, and for the implementation R&D's been kicking around rather "bedazzling" the BD.

[tst]

Well, one option would be for this to be configurable (through the options for each type of indication or though a toggle in the toolbar), but this doesn't solve the problem of noise and only makes the feature more complicated.

The overlays could be semi-transparent, like the image in the original idea, but that probably won't work with user icons.

You could have a single overlay which means "non-default behavior" (and maybe the user would be able to set it as well) and then the details would show up in the CH window. You could make this not obscure the icon by using the space outside the icon. For example, adding it as a halo (ugh) or a small extension such as a triangle sticking upwards from the top-right corner, which is generally unused.

Overall, I would say that using the CH window for these is preferable.

[SteenSchmidt]

Very elegant if the Context Help could indicate non-standard behaviour, the icon is very crowded as it is for sure. Pretty cool. Users would need some sort of interface to add tags to the Context Help then? I mean, execution system, priority and that sort can be grabbed from the VI Properties for automatic display, but run_even_on_error etc. might have to be specified by the user somehow, as it could be implemented a number of different ways?

Cheers,

Steen

[GregSands]

My problem with using the CH window for this is that it requires transferring attention from where the mouse is (on the sub-vi) over to the CH, then searching through all the other information (which I usually don't need) to find what I'm interested in.  Plus, if the CH is open, it always seems to be getting in the way!

My suggestion is to have a tool-tip pop up, similar to what pops up over terminals when wiring to a sub-vi:

Glyphs would be preferable to letters (probably), but I'll leave that to someone who can draw!  Glyphs could be greyed out to show it's not set, and perhaps the tool-tip could surround the VI rather than being to one side.  But I definitely prefer having the information at the mouse rather than in a side window.

[GregFreeman]

AQ -- this nullifies my idea of creating one of these myself via scripting . I was going to make myself something to put in the tools menu where I could just have checkboxes next to VI properties I wanted to display in the context help. However, the glyphs I would not have thought of, and I'm excited to see what NI comes up with!

[JÞB]

I like the CH idea.  My personal style is to add non-default settings to the CH and would rather have glyphs and text auto-assigned. Without me having to A) remember the settings.  B)update the documentation when I change it. AND it would remind me that (DUH! the spec said to disable debugging and set it to execute in the UI thread.

BRAVO Add Glyphs to context help (optionally: Add glyphs and text to context help)

Of course I'm no Arttist