Visual Indication of VI access scope (On the VI Itself)

[Aristos Queue]

QUOTE (neB @ Sep 1 2008, 06:44 AM)

[OT:Q Does anyone know how to use a VI template that is a member of a class? Knowing that would let me reduce the scope of most of the sub-VIs back to what I originally intended, Thanks!]

A library (.lvlib) is a collection of VIs. A class (.lvclass) is a collection of VIs dedicated to the purpose of defining a data type. An XControl (.xctl) is a collection of VIs dedicated to defining a new control. A state chart (.lvsc) is a collection of VIs dedicated to defining a state chart.

Anything that is true of a library should be true of all of these types. I am not aware of any exceptions to that statement, but I can only really speak to classes.

So, having said that, a VI Template that is a member of a class should work the same as a VI Template that is a member of a library.

QUOTE

I recently reported what I thought was a bug. A VI created from a template (where the template is a member of a class) using the Open VI >>> Invoke node run mtehod will not run if it has protected or private methods on its diagram. The invoke node returns an error and looking at the VI created from the template shows errors on the class wires. But the emplate does not have a broken run arrow. It looks like the template is being created "outise of the class Library" so its use of bundle, etc are not allowed. I worked around this issue by creating public accessor VIs and I was able to move on,

BUT

This bug seems to bear witness to the fact the VI itself does not know it should be part of the class library.

So maybe what I reported was not a bug?

This is a matter of some debate. VI Templates are not the same as Reentrant VIs. A VI Template, when instantiated, is a real, savable, editable VI, one that is disconnected from the template that spawned it.

The new VI *does* become a member of the library if the library is unlocked. But allowing it to become a member of the library requires an edit to the library, which cannot happen if the library is password protected and/or locked. And a library is always locked when it is running. So most programmatic instantiations of the VI Template fail to join the library because the library itself is reserved for running at that point.

Should we somehow allow templates to be instantiated such that they can still access the internals of the library that spawned them? That seems very wrong -- we would then have privileged VIs that could be saved, meaning any library that exposed a .vit would suddenly have a hole that other users could use to gain access to all the library internals. Perhaps an instantiation only has access during this launch of LV? That would mean a VI that works great unless you save and re-load it, at which point it is broken. Again, that seems strange.

This is a case where I would strongly encourage investigation of reentrant VIs instead of VI Templates. Since reentrant VIs now have full front panels (as of LV8.2 I think, but it might be 8.0), the cloning of a front panel that used to require a template can now be done without one. The reentrant clones do have access privileges since they are still connected back to their original reentrant VI.

[LAVA 1.0 Content]

QUOTE (Aristos Queue @ Sep 1 2008, 09:51 AM)

...

reentrant VIs instead of VI Templates. Since reentrant VIs now have full front panels (as of LV8.2 I think, but it might be 8.0), the cloning of a front panel that used to require a template can now be done without one. The reentrant clones do have access privileges since they are still connected back to their original reentrant VI.

Hmmmm.... Opening them with the 8 (?) switch and run as the sub-VI of a template maybe.

I'll have to think obuout how I can do this. I'm trying to instaciate Active Objects of a class and am trying to figure it out as I go.

Thanks,

Ben

[LAVA 1.0 Content]

QUOTE (neB @ Sep 1 2008, 05:11 PM)

Hmmmm.... Opening them with the 8 (?) switch and run as the sub-VI of a template maybe.

Ben, you should really start tagging, it took 10 minutes to find this http://forums.lavag.org/Video-Objects-and-Classes-t11336.html#' target="_blank">post

Containing this way to instantiate an active object via reentrant clones:

Ton

[LAVA 1.0 Content]

QUOTE (Ton @ Sep 1 2008, 02:19 PM)

Ben, you should really start tagging, it took 10 minutes to find this http://forums.lavag.org/Video-Objects-and-Classes-t11336.html#' target="_blank">post

Containing this way to instantiate an active object via reentrant clones:

Ton

Tagging? How about retiring. I should have remebered that. How to old ways die hard.

Ben

[PJM_labview]

Back on topic,

I created a small utility that add a temporary overlay on the VI icon of the active VI (see images below).

I put this thing together rather quickly so there is no warranties that it will work in every situations.

Before

After

I use the following convention:

Attached is the utility.

Installation Instruction: Copy the entire "LVOOP Utilities" folder under your "project" folder in LabVIEW and then you will have a new menu under tools (once LV restart) as seen here -->

Note: OpenG Libraries are required

Download File:post-121-1220470490.zip