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

[PJM_labview]

I don't know if anybody else feel the same way, but I would like to have a visual indication [somewhere on my VI] of class member access scope (public, private, protected). May be a glyph in the lower left corner (where project namespace/instance is usually located) or somewhere else will really be useful.

or

Alternatively a word (public, private or protected) in the title bar (possibly activate through an ini key) will be good as well.

PJM

[crelf]

QUOTE (PJM_labview @ Aug 28 2008, 10:00 PM)

I don't know if anybody else feel the same way, but I would like to have a visual indication [somewhere on my VI] of class member access scope (public, private, protected).

You're not alone - I would like the ability to added a dynamic glyph to the VI icon, and then I can see scope when they're subVIs. It's be nice to have the colors of those glyphs be the same as the class too...

[LAVA 1.0 Content]

Why is everyone forgetting LVLIB's and XCTL's when they are talking about 'private' and 'public'?

Ton

PS I think this is a good feature request

[Donald]

Good suggestion!

I'm also using more and more the lvlib public/private access scope when refactoring old(er) code in LV8+ environments. I like to protect functional globals to be used directly in the main diagram and wrap then in a public VI for each 'method' of the functional global.

I must admit I have been thinking also about such a 'dynamic' glyph for reentrant VIs (a bold red R...)

[Aristos Queue]

[Writing as G progammer, not as LV R&D developer]

Strikes me as a strange request. Why do you care when you're writing the function what the scope of the function is? I can understand being interested in that when *calling* a function (ie, an annotation on the subVI call), but not when writing it. I don't know of any programming language that has that sort of notation in its code nor any language's IDE that provides that kind of visual feedback when writing the function.

To me, the "I am Reentrant" glyph is a more useful request since a reminder that this VI is reentrant changes what I might write on this VI's block diagram (ie, don't use that control on the front panel as a storage location since it won't be the same control the next time you're called).

[crelf]

QUOTE (Aristos Queue @ Aug 29 2008, 11:21 AM)

Why do you care when you're writing the function what the scope of the function is? I can understand being interested in that when *calling* a function (ie, an annotation on the subVI call), but not when writing it.

I definately agree that seeing the scope when using the VI as a subVI would satisfy most of my use cases, and I'd be very happy if just that functiaonlity was introduced. That said, I think having the scope displayed during development of the item would serve to remind me where it is in the scope of things, eg: "Oh crap, I'd meant to set this as private to this lvlib, but there's no key glyph". I know that info is available in the project explorer and when I'm thinking scope then it's relative to a context there, but as the VIs are scope aware (they know what they belong to) I figure it wouldn't be too difficult to include a scope glyph on the VI somewhere?

[PJM_labview]

QUOTE (Aristos Queue @ Aug 29 2008, 08:21 AM)

...Strikes me as a strange request. Why do you care when you're writing the function what the scope of the function is? I can understand being interested in that when *calling* a function (ie, an annotation on the subVI call), but not when writing it. I don't know of any programming language that has that sort of notation in its code nor any language's IDE that provides that kind of visual feedback when writing the function...

I agree that when writing a vi for the first time this is not useful at all (but this will be in future editing). I also agree with the glyph suggestion on the SubVI call (this is actually a great idea :thumbup: ).

Note: In the my previous post entry, the screenshots were never intent to mean that I need the glyph on untitled VI. I guess I should have use an existing VI to add the glyph to. Sorry about that confusion.

Basically, at any given time a typical LabVIEW developer has a fair amount of VIs opened (which he may not have written). There is currently no (quick, at a glance) way to know what is the scope of opened VIs.

These VIs may have been opened through various mechanism (lvclass project view, VI Tree, Explorer ...); they may or may not be member of the class, they may or may not be utility reuse code.

At the moment, the only reliable way find the access scope is to use the "locate in project" openg utility.

So I think there is also a need for knowing the access scope of opened VIs (along with the "glyph on SubVI call" idea).

PJM

[JDave]

QUOTE (crelf @ Aug 29 2008, 09:30 AM)

I definately agree that seeing the scope when using the VI as a subVI would satisfy most of my use cases, and I'd be very happy if just that functiaonlity was introduced. That said, I think having the scope displayed during development of the item would serve to remind me where it is in the scope of things, eg: "Oh crap, I'd meant to set this as private to this lvlib, but there's no key glyph". I know that info is available in the project explorer and when I'm thinking scope then it's relative to a context there, but as the VIs are scope aware (they know what they belong to) I figure it wouldn't be too difficult to include a scope glyph on the VI somewhere?

The Icon Editor I created allows for placing images in the corners. It wouldn't be that hard to automatically place the proper image in the desired corner. However, this would probably require knowing the VI ref so you could query. (I haven't looked into this, so I am not sure that it is available for querying...) This is just another reason why it would be nice to know what VI the Icon Editor is manipulating.

My current method for getting the VI ref works pretty well, but doesn't handle calling the Icon Editor from an Invoke Node. I use a background process monitoring for the rusty nail VI Activation event.

[LAVA 1.0 Content]

QUOTE (JDave @ Aug 30 2008, 06:54 AM)

It wouldn't be that hard to automatically place the proper image in the desired corner. However, this would probably require knowing the VI ref so you could query.

Yes it would.

Let me explain:

The VI itself is unaware of it's 'privatism' (as http://forums.lavag.org/Visual-Indication-of-VI-access-scope-On-the-VI-Itself-t11825.html&p=51201#' target="_blank">AQ pointed), so you should get a reference to the item in the LVLIB, get's it status from the lvlib (if the VI itself is 'public' you should check every owning folder as well).

Not very easy.

Ton

[crelf]

QUOTE (Ton @ Aug 30 2008, 07:47 AM)

The VI itself is unaware of it's 'privatism' (as AQ pointed)...

I don't see anywhere inthat post where Stephen says that - are you sure you're linking ot the right post? Anyway, are you sure that a VI doesn't know it's scope? It knows that it's a member of a library/class/etc, so I'm not convinced that it doesn't know it's public/private scope as well...b

QUOTE (JDave @ Aug 30 2008, 12:54 AM)

The

http://forums.lavag.org/-t11537.html&view=findpost&p=49250'

target="_blank">Icon Editor

I created allows for placing images in the corners.

Just so I'm clear - I'd prefer that the icon not atually be edited, I want the scope/re-entrancy/etc glyphs to be on a layer above the base icon, so the image information isn't destroyed by the glyph (eg: if I make a VI re-entrant and then I make it non-re-entrant, then I want the original icon that was under the re-entrant glyph to be preserved).

[LAVA 1.0 Content]

QUOTE (crelf @ Aug 30 2008, 03:54 PM)

I don't see anywhere inthat post where Stephen says that -

I think 'hinted' would be a better word to indicate what I've read.

The 'privatism' of VIs is set in the library properties and nowhere else, this strengthens my believe a VI doesn't know it's state. Furthermore if you use a private VI outside it's scope the owning VI is broken and not the private VI.

Ton

[Aristos Queue]

QUOTE (crelf @ Aug 30 2008, 08:54 AM)

I don't see anywhere inthat post where Stephen says that - are you sure you're linking ot the right post? Anyway, are you sure that a VI doesn't know it's scope? It knows that it's a member of a library/class/etc, so I'm not convinced that it doesn't know it's public/private scope as well...

Ton is correct. The VI itself has no idea of its scope. The library is what defines and controls the scope of the items within that library, and you have to query the library item reference for that information. In fact, it goes further than that... just because a VI is public inside its owning library, that owning library could itself be private inside its owning library, and so any caller VI has to check with the entire ownership chain. Checking protected scope is even more complex -- the code in C++ stretches to a couple pages.

Asking a VI "are you a private VI" is easy enough -- use the VI ref to get the lib item ref and then ask for scope, which will take care of checking virtual folder settings. But asking "can this VI call that VI" is a much more complex step and I don't know of any property/invoke API that will allow you to query for that information.

This is another aspect of why the publicness/privateness of a VI is irrelevant when writing the VI itself... its callability varies depending upon the other VIs that you're talking to.

PS: Since the library is what knows the scope of a VI, if a VI claims to be a member of a library and the lib is missing, we assume the VI is private.

[Jim Kring]

QUOTE (Aristos Queue @ Aug 29 2008, 08:21 AM)

[Writing as G progammer, not as LV R&D developer]

Strikes me as a strange request. Why do you care when you're writing the function what the scope of the function is? I can understand being interested in that when *calling* a function (ie, an annotation on the subVI call), but not when writing it. I don't know of any programming language that has that sort of notation in its code nor any language's IDE that provides that kind of visual feedback when writing the function.

To me, the "I am Reentrant" glyph is a more useful request since a reminder that this VI is reentrant changes what I might write on this VI's block diagram (ie, don't use that control on the front panel as a storage location since it won't be the same control the next time you're called).

AQ,

I don't find PJM's request (making the access scope visible somewhere on a VI's FP window) strange at all. LabVIEW isn't like other programming languages/IDEs. When one interactively develops and run a LabVIEW application, they often have their VI front panels and block diagrams open. Knowing the access scope of VIs is very important, in this respect.

Based the argument you provided, it would follow that LabVIEW users shouldn't care which Application Context a VI is in (when they're writing it), either, so why doe LabVIEW show the context name in the lower left corner of each VI? The answer is that this information is useful during and after development, when one presses the run button and needs to know (beforehand) in which context the VI will run. Similar utility would come from knowing the access scope of a VI when looking at a VI's FP or BD.

Other programming languages don't give developers a tangible way of interacting with functions, the way that LabVIEW does. LabVIEW is different and special. Things that don't make sense for text-based environments, might make great sense in LabVIEW.

Thanks,

-Jim

[crelf]

QUOTE (Jim Kring @ Aug 30 2008, 11:51 AM)

When one interactively develops and run a LabVIEW application, they often have their VI front panels and block diagrams open. Knowing the access scope of VIs is very important, in this respect.

Well said Jim - that's what I was trying to get at.

[Aristos Queue]

Which context the VI is in makes a huge difference in how it will behave when it runs. Whether the VI is private or public makes *zero* difference to how it behaves when you run it. None. Zilch. Nada. You can change the scope from public to private, even to protected, and the behavior of the VI will be unchanged.

[Jim Kring]

QUOTE (Aristos Queue @ Aug 30 2008, 11:01 AM)

Which context the VI is in makes a huge difference in how it will behave when it runs. Whether the VI is private or public makes *zero* difference to how it behaves when you run it. None. Zilch. Nada. You can change the scope from public to private, even to protected, and the behavior of the VI will be unchanged.

True, but whether the VI is private or public makes a huge difference to how a caller (calling VI) will behave when you try to run that calling VI. For example, if the caller is not a member of the same lvlib as the callee, then the scope of the callee (e.g., if it's private) can cause the caller to be broken. When one is trying to debug and resolve this problem by opening up the VIs in question, there is neither a graphical indicator of the problem nor an easy way to resolve it, without going through the (relatively painful*) process of locating the callee in it's lvlib and changing it's scope.

* Note that the http://wiki.openg.org/Ogedit_file_locate_in_project' rel='nofollow' target="_blank">OpenG Locate File in Project tool makes this somewhat less painful.

[Aristos Queue]

QUOTE (Jim Kring @ Aug 30 2008, 01:21 PM)

True, but whether the VI is private or public makes a huge difference to how a caller (calling VI) will behave when you try to run that calling VI. For example, if the caller is not a member of the same lvlib as the callee, then the scope of the callee (e.g., if it's private) can cause the caller to be broken. When one is trying to debug and resolve this problem by opening up the VIs in question, there is neither a graphical indicator of the problem nor an easy way to resolve it, without going through the (relatively painful*) process of locating the callee in it's lvlib and changing it's scope.

And that's why I was suggesting that something on the subVI node itself was more useful -- you wouldn't have to open up the subVI at all in that case. And, as I mentioned above, if you did open the subVI, you might not see any private marking because of the sublibrary problem: A.lvlib owns B.lvlib owns C.vi. C.vi is public in B.lvlib and so wouldn't have a private flag. But B.lvlib is private in A.lvlib. So a caller D.vi that is not in A.lvlib would be broken. Having the indication on the subVI would be useful, but having it on the subVI when you opened it would not be.

[Jim Kring]

QUOTE (Aristos Queue @ Aug 30 2008, 01:27 PM)

And that's why I was suggesting that something on the subVI node itself was more useful -- you wouldn't have to open up the subVI at all in that case. And, as I mentioned above, if you did open the subVI, you might not see any private marking because of the sublibrary problem: A.lvlib owns B.lvlib owns C.vi. C.vi is public in B.lvlib and so wouldn't have a private flag. But B.lvlib is private in A.lvlib. So a caller D.vi that is not in A.lvlib would be broken. Having the indication on the subVI would be useful, but having it on the subVI when you opened it would not be.

I didn't say that being able to see the scope while looking at a subVI is a bad thing -- I think it would be great and I support that feature. My take home point is that (and, maybe I'm just an old-timer, but) I think that most LabVIEW users interact with VI's, primarily, and with projects (.lvproj) and libraries (.lvlib), secondarily (especially in the context of debugging). As such, having ways to identify and modify VI settings (and, yes, I realize that this is an lvlib setting associated with a VI) easily from the VI, itself, is important -- especially, when the setting impacts the way that the application, as a whole, will run (or not run).

If LabVIEW is going to limit feature visibility and access to the project/library environment, then it needs to do a much better job of allowing LabVIEW users to quickly get to the project/library from the context where they are programming their applications. For example, how come it is so hard to locate a VI inside of the project/library/class from a VI's front panel or block diagram? How come there is no way to open a class from the class hierarchy window? I think that there are several usability roadblocks with respect to libraries/classes and PJM's suggestion stems from trying to bridge them.

That's why I don't think Philippe's request is "strange" (as you suggest). While it might not make sense, theoretically, it does make sense in practice. And, those of us who echoed support for PJM's request spend a lot of time practicing LabVIEW.

That reminds me of a great quote I read today in http://www.codinghorror.com/blog/archives/001166.html' rel='nofollow' target="_blank">Jeff Atwood's blog article on deadlock:

QUOTE ("Jeff Atwood")

In theory there is no difference between theory and practice. In practice there is.

Cheers,

-Jim

[Aristos Queue]

QUOTE (Jim Kring @ Aug 30 2008, 05:07 PM)

How come there is no way to open a class from the class hierarchy window?

Double click on the class in the class hierarchy window. Same as you do for a VI in the VI Hierarchy window to open the VI.

QUOTE

While it might not make sense, theoretically, it does make sense in practice.

No, it still doesn't make sense, even in practice. What it does is highlight other aspects of LV that need improvement. But let's fix what's broken, not create workarounds that don't do what you think they do.

QUOTE

And, those of us who echoed support for PJM's request spend a lot of time practicing LabVIEW.

As do I... although to be fair to you, I don't practice all of LabVIEW. But programming in the particular corner called LabVOOP is a large chunk of my professional work these days. Maybe someday I'll be able to call myself a LabVIEW programmer , but I do think the title of LabVOOP programmer is one I have rights to already.

[Michael Aivaliotis]

QUOTE (crelf @ Aug 30 2008, 06:54 AM)

Just so I'm clear - I'd prefer that the icon not atually be edited, I want the scope/re-entrancy/etc glyphs to be on a layer above the base icon, so the image information isn't destroyed by the glyph

I think the word you're looking for is "overlay"

[crelf]

QUOTE (Michael_Aivaliotis @ Aug 31 2008, 01:30 AM)

I think the word you're looking for is "overlay"

It is indeed.

[JDave]

QUOTE (Aristos Queue @ Aug 30 2008, 01:27 PM)

And that's why I was suggesting that something on the subVI node itself was more useful -- you wouldn't have to open up the subVI at all in that case. And, as I mentioned above, if you did open the subVI, you might not see any private marking because of the sublibrary problem: A.lvlib owns B.lvlib owns C.vi. C.vi is public in B.lvlib and so wouldn't have a private flag. But B.lvlib is private in A.lvlib. So a caller D.vi that is not in A.lvlib would be broken. Having the indication on the subVI would be useful, but having it on the subVI when you opened it would not be.

I don't use libraries so I'm a bit confused by this. If I understand correctly, and if the feature of overlaying the access scope on the icon were developed, C.vi is would show up as public if dropped on a vi within B.lvlib. C.vi would show up as private if dropped on a vi withing A.lvlib. And C.vi would break a vi (possibly different overlay) if placed elsewhere. Is this correct? And that is the issue, that the access scope actually changes based on where it is called?

David

[Aristos Queue]

QUOTE (JDave @ Aug 31 2008, 08:13 PM)

I don't use libraries so I'm a bit confused by this. If I understand correctly, and if the feature of overlaying the access scope on the icon were developed, C.vi is would show up as public if dropped on a vi within B.lvlib. C.vi would show up as private if dropped on a vi withing A.lvlib. And C.vi would break a vi (possibly different overlay) if placed elsewhere. Is this correct? And that is the issue, that the access scope actually changes based on where it is called?

David

I think you summed it up rather nicely. Except I wouldn't say "the access scope changes based on where it is called" so much as "multiple access scopes can affect the same VI depending on the caller."

Think of libraries as containers of VIs. Some VIs are at the edge of the container, others are deep inside. The containers can contain smaller containers. So if a VI is on the edge of a deep container, it might still not be on the edge of the outer container. VIs inside the outer container can see the inner container and that VI, but VIs outside cannot.

[crelf]

QUOTE (Aristos Queue @ Aug 31 2008, 09:40 PM)

Think of libraries as containers of VIs. Some VIs are at the edge of the container, others are deep inside. The containers can contain smaller containers. So if a VI is on the edge of a deep container, it might still not be on the edge of the outer container. VIs inside the outer container can see the inner container and that VI, but VIs outside cannot.

That's the best description I've heard of lvlibs so far :thumbup:

[LAVA 1.0 Content]

QUOTE (Aristos Queue @ Aug 30 2008, 10:44 AM)

Ton is correct. The VI itself has no idea of its scope. The library is what defines and controls the scope of the items within that library, and you have to query the library item reference for that information. ...

This is another aspect of why the publicness/privateness of a VI is irrelevant when writing the VI itself... its callability varies depending upon the other VIs that you're talking to.

PS: Since the library is what knows the scope of a VI, if a VI claims to be a member of a library and the lib is missing, we assume the VI is private.

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?

Ben

[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!]