reentrant VI indicator

[GregFreeman]

I searched reentrant in this idea exchange and didn't see anything on it so here goes. I would like some sort of indicator showing that a VI is reentrant. Right now, as far as I know, you have to go into the properties and check. It would be nice if there could be either something on the icon, or a small label that would show if the VI was reentrant. Or maybe a slight "halo" around the VI, something to that effect. Any other ideas on how to do this are welcome.

Message Edited by for(imstuck) on 02-24-2010 10:00 AM

[JÞB]

I think the VI info is the only way to go for this.  Yes I want the re-enterancy, priority ect on my help window (right below the VI name)..  but only if they are not "default".  And someone else might not want this at all But require a SCC lable in the help.

And it seems that the consensus of the posters use information available in the context help window to distingush these features.  The lone disenter (Darin) uses hidden BD info of buffer allocations BUT color codes the VI icon border so he sees it in the context help too (Bet HE uses it to find stale context help)  

While I eluded to configurable auto-populating context help fields for a template in this Idea I thought that the demand might not support the evident work it would require.  I may have under-estimated the desire for better documentation featureing.

I'ld still keep these issues seperate thread- better tool is a Must to me.  Better useability of a full-featured tool is highly derireable 

[AristosQueue (NI)]

I decided to Kudos this idea, but only in the Context Help, as discussed in the comments. I'm still not fond of annotating the diagram directly. Don't ask me why... I'm not sure what my opposition is based on. Maybe it's the aesthetics of a floating R. Maybe I had a bad run-in with the Express VI halo when I was younger. I just don't like it. But the CH sounds like a good solution.

[Broken_Arrow]

The same idea, with respect to all comments, can be said to apply to VI's set to "inline' as well.

[gsussman]

This may warrant another idea altogether however I find that most of the time my need/desire to see the reentrancy or other similar property is short lived (i.e. during debugging).

The concept of listing these specific properties in the context help, automatically, is a great idea, however I would like to also see on the block diagram some visual indicator of the particular status. To address AQ's aversion to additional BD clutter (I am with you on this), why not make it something that we can turn on or off from the toolbar? Turn it on when needed to highlight those things we are interested in, and turn it off afterwards to keep the BD looking clean.

 

[EMR]

It'd also be super handy to know what KIND of reentrant it is. since i've been burned several times by preallocate vs shared when I meant to choose the other one.

I'd personally like both, a decal over the icon for reentrancy so I can see it in my VI heirarchies-at-a-glance, and a tiny text blob with details in the help/project view for execution settings. maybe it could be an option we could turn on?

[jlokanis]

I often find myself having to review the whole hierarchy of VIs looking for ones that I forgot to set to reentrant.  I have made tools that will build a list of these properties from VIs in memory or on disk but seeing them in the VI hierarchy screen would be the most useful.  So, I vote for some sort of visual indicator that can be turned on and off as needed.

[AristosQueue (NI)]

In the years since I posted my aversion to this idea, this community has discussed subVI reentrancy, dynamic dispatching, required/recommended terminals, inline settings, execution thread, and a host of other things.

Each of these is an aspect of a VI or its conpane that can change how the reader of the code interprets what is going on, but at the same time, none of these changes the main thrust of what a node on the diagram represents: a call to that functionality to do whatever it is that functionality does.

I can make the argument that the use of certain operations in a subVI changes how I perceive it -- does it have side effects through refnums or something. Should that be annotated on the call site? I don't think so. For one thing, there's not space. For another thing, the set of "interesting aspects of any node" is endless and really depends upon investigating that node.

I would like to steer the community's general brainstorming away from annotation on the call site and toward a few different things. One idea would be something like this:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Icon-editor-could-suggest-glyphs-to-include-based-on-V...

> having to review the whole hierarchy of VIs looking

> for ones that I forgot to set to reentrant. 

This isn't something that I would ever attempt by visiting block diagrams. That's definitely the job of a review tool like VI Analyzer. Not saying VI Analyzer is the right tool for this, but I am saying that some sort of editable spreadsheet view is the right vector, IMHO.

[jlokanis]

I agree that the call site should not be notated.  I was more interested in a setting in the VI Hierarchy window that would 'tag' VIs based on the property of my choice.  That way I have a visual cue to see if all the subVIs have that setting.

For me, the point is I need a set of code to be fully reentrant so multiple instances cannot block eachother.  The problem is making sure there are not some low level subVIs in the hierarchy that are still non-reentrant.  Sure I could build a table using VI server calls to all VIs in memory or using VI Analyzer but then I lose the information about the hierarchy.  Plus, a visual view is always better than a text based one, right?  

[AristosQueue (NI)]

> Plus, a visual view is always better than a text based one, right?

Maybe. If that visual view provides a way to make the edit, then, yes. If it is just a view with no easy way to fix the bug I see, I'd probably rather have the table.

[jlokanis]

For me, it is about finding them.  I can always open the VI from the view and then edit the properties.  I am ok with that.  My current method is to crawl the entire hierarchy from the top level down and press CTRL-I to see the properties (and fix them as needed) followed by a CTRL-S and CTRL-E to check the BD for more subVIs and then a CTRL-W to move on.  Not much fun and prone to errors.  There is no easy way to make a table that limits itself to the hierachy of a VI.  All VIs in memory will include all VIs in the project.  I suppose it could be done with scripting but that just leads to this:

Automation