Configuring Reentrancy Options in Virtual Folder

[dgdgomez]

Sometimes you want to have a set of VI with the same properties of reentrancy, for this, we can consider the option of having a virtual folder with the option of reentracy desired, as it happens with the option of access scope.

I propose to have the option to define a virtual folder with a properties of reentracy and that VIs are contained in it, change its property. In this way, I think it is easier to know the properties of the VIs reentrancy.

Regards.

[RavensFan]

What should happen if you move a VI back out of that virtual folder?  Would it remain re-entrant, or lose that setting?

Supposed you accidentally drop a VI into that folder, what should happen?

What about a VI that is in a virtual folder of one project, but is also used in another project where it is not in a virtual folder.

I don't like the idea that properties of VI's be controlled by something as disconnected as the properties of a virtual folder in a project.  It seems too dangerous.

[dgdgomez]

What should happen if you move a VI back out of that virtual folder?  Would it remain re-entrant, or lose that setting?

When entering a VI into the virtual folder, it adapts its reentrancy properties to that of the virtual folder, extracting the VI from the virtual folder would have no effect on changing the reentrancy configuration.

Supposed you accidentally drop a VI into that folder, what should happen?

The virtual folder should have some icon representative of the reentrancy configuration, just as it happens when you select the access scope option to a virtual folder.

What about a VI that is in a virtual folder of one project, but is also used in another project where it is not in a virtual folder.

Good question. Maybe you should limit the scope for virtual folders contained in library.

[AristosQueue (NI)]

> Good question. Maybe you should limit the scope for virtual folders contained in library.

That would *definitely* have to be a requirement.

Overall, this isn't a bad request, but it isn't a slam-dunk either.

First: if there are any showstopper issues, I suspect it will be in the area of having the VI saving a setting and the library storing an override of that setting and what happens when those are in conflict. Even if the LV editor enforced that they always match, there's the possibility of someone saving one and not the other or reverting one file but not the other using source code control. We've had problems in LV before with files who save duplicate settings that need to be kept in sync and coming up with rules for resolving them. I'd need some folks to do some serious brainstorming for, "What tools would this break?" before I'd say it's a good idea. (This might be more viable for LabVIEW NXG where the component files [.gcomp] are much more "in command" of the VI files [.gvi].) I am not saying there is a showstopper issue, just noting where analysis is needed.

Second: There's some UI issues to work out. Virtual folders can define access scope. Now they can define reentrancy. Can a given folder only define one attribute? If a folder can define multiple attributes, how does that display in the project tree (not a lot of space in the icon)?

Third: What makes reentrancy so special? Execution system? Debugging enabled? Inlining? In other words, does this feature need to be designed to take into account just one attribute or does it need to consider an arbitrary set of attributes?

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.