Jump to content

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


Recommended Posts

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.

Link to comment

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

Link to comment

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

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

Ben

Link to comment

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.

post-121-1220469924.png?width=400

Before

post-121-1220469932.png?width=400

After

I use the following convention:

post-121-1220469941.png?width=400

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 -->

post-121-1220470706.png?width=400

Note: OpenG Libraries are required

Download File:post-121-1220470490.zip

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.