Show Names on Call Library Function Nodes

[JackDunaway]

Did you know you can make property nodes and invoke nodes smaller by not showing the names?

Well, forget you know, it's a terrible idea to hide that information! You lose the self-documentating nature of LabVIEW. I use this as a comparison for Call Library Function Nodes (CLFN) - by default, these are dropped on the block diagram without showing names. I propose that the default is to show names for CLFNs for the sake of documentation, and so you don't have to hover over each terminal to find the one you're looking for. The biggest perk is simply the name of the function on the banner of the node. YES, there is a tradeoff between BD real estate and documentation, but I think "Names" trumps space virtually all the time.

[Intaris]

I agree.

[AristosQueue (NI)]

Another of those rare "ideas I didn't know I needed". Kudos!

[GregR]

CINs don't have any way to define names for their parameters and are very unlikely to get that ability since they are being gradually phased out in favor of the call library node.

Also realize that the names on the call library node are user configured and not everyone bothers to configure them. Currently the people who do the extra work of configuring the names may also want to do the extra work of showing the names. With the new behavior it would be the people who don't bother configuring the names who would have to do extra work to hide the meaningless default names. Maybe that is a good thing and would encourage them to put in good names, but for those people this change could be annoying.

[tst]

I didn't even know that CLFNs could show names. I haven't dealt with any recently, but in the past, I resorted to creating a label for the function name and hovering over the I/O for those names. This is definitely better.

[JackDunaway]

GregR - You're absolutely right, I forgot CIN's do not have the ability to "Show Names". If you notice, I did not include CIN's in the thread title, but as an afterthought decided to add CLFN and CIN to the body. So, I have notified the moderator to remove the "and CIN" references in the post. Good catch!

[Darin.K]

Annoying.  Very, very annoying.  I turn on names <5% of the time, and I am pretty anal about configuring the parameters.  By the time you consider how many controls/indicators/constants are connected, many of those terminals are self-documented.  Add a couple of wire labels as desired and things are fine.

I would much rather have the info in the Context Help window so when I hover over a CLFN it shows it like a VI with names attached to wires instead of the generic picture you get now.

No way this should become default without an option to revert.  This is fine for those who sprinkle one or two of these on occasion, not for those of us who use a lot of shared libraries.  Property nodes can be compacted by resizing, multiple CLFNs are often required and each one is separate.  Real estate becomes an issue very quickly.

[JackDunaway]

@Darin.K - This is one of those examples where "big diagrams just gotta be big." (Other examples include ActiveX, .NET, anything with a 3D picture....) I have yet to see an instance, however, that could not contain the VI to the horizontal scrolling direction. A subVI wrapper around the DLL or group of DLLs helps clean things up (this is not news to you) to encapsulate the function of the DLL as a single block. I'm still going to stand by using names virtually 100% of the time.

[Darin.K]

I completely disagree that "big diagrams just gotta be big".  IMO that is a symptom of something being done in an unnatural fashion.  When my diagrams involving .NET stretch across two screens, that is a sign that there must be a better way.  What it is I do not know, but I am not the one being payed big bucks to figure it out.  In general I feel that adding text to G is almost always bad.  The push should be in the opposite direction.

If there is an option to leave it as it is, fine.  This is one of my last refuges for old-school programming and you are trying to Express-ify it.  I suppose that is progress.  I would much rather be able to actually pass-through an error cluster than have any changes like this.

[Manzolli]

Agree with Darin.K, as an option Kudos!

[AristosQueue (NI)]

Darin K: How would you feel about the ability to put an icon on a Call Library Node?