Has anyone seen this before? ("Select User Defined Tag Type")

[Sparkette]

I used scripting to create a constant from a "RIO Device" type descriptor, using Flattened String to Variant. But now it's giving me some kind of I/O name control I've never seen before. The down-arrow on the right is disabled, and when I right-click it, there's a new menu item that says "Select User Defined Tag Type". I googled it and didn't find anything. That menu contains "crioRefnumTag", "Data Exchange", "Variable", several FPGA-related items, "RIO Resource", and "System Config". When I select one, it seems to change into an I/O name control of that type, and the menu goes away. Has anyone seen this behavior? I've attached a control that has that menu on it in case anyone else wants to mess with it.

 

TagType.ctl

EDIT 1/26/22: Here's a VI containing the user-defined refnum/tag controls, as well as four private nodes that look relevant.

Useful Objects.vi

Edited January 27, 2022 by flarn2006
Attached VI with relevant controls and private nodes to copy

[hooovahh]

That's neat, never seen this functionality before.  I have a bunch of other possible choices for XNet things too.  XNet Database / Device / Frame / Signal / Cluster / Session etc.  So I'm guessing it queries your system somehow to show what types of I/O references it can be.  I really expected DAQmx to be in the list but it isn't.

[Sparkette]

I tried turning on "View as Icon" on its terminal, and it shows up like a normal I/O name control would, only it says "TAG" instead of, say, "RIO".

[Rolf Kalbermatter]

I tried turning on "View as Icon" on its terminal, and it shows up like a normal I/O name control would, only it says "TAG" instead of, say, "RIO".

 

It's a generic user tag refnum. The functionality behind it is relying on information found in the resource/objmgr directory inside LabVIEW. Basically the rc files in there can define an object hierarchy and for each object type you can define methods, properties and events that map to specific exported functions from a shared library.

 

Once the generic tag refnum has been selected to represent a specific object type from one of the object hierarchies it is not generic anymore and you can not select other object types anymore from other object hierarchies. Also flags in the object type inside the rc allow to specify if the user is allowed to even select any other object type within the object hierarchy. It's all pretty involved and complicated (a single error in the rc file usually makes it completely useless and you can go and start guessing were the error is.

 

To interface in a shared library to a LabVIEW VI user tag refnum you also either need to use some private diagram nodes to register the session handle returned from your shared library to a user tag refnum and also one to deallocate it, or use internal LabVIEW manager functions to do that.

 

But unless you write drivers for some kind of interface in external shared libraries, the user tag refnum has no practical meaning for you at all. And it requires your shared library to be explicitly written to work with LabVIEW, it's not a means to interface LabVIEW to standard shared libraries at all.

[Sparkette]

It's a generic user tag refnum. The functionality behind it is relying on information found in the resource/objmgr directory inside LabVIEW. Basically the rc files in there can define an object hierarchy and for each object type you can define methods, properties and events that map to specific exported functions from a shared library.

 

Once the generic tag refnum has been selected to represent a specific object type from one of the object hierarchies it is not generic anymore and you can not select other object types anymore from other object hierarchies. Also flags in the object type inside the rc allow to specify if the user is allowed to even select any other object type within the object hierarchy. It's all pretty involved and complicated (a single error in the rc file usually makes it completely useless and you can go and start guessing were the error is.

 

To interface in a shared library to a LabVIEW VI user tag refnum you also either need to use some private diagram nodes to register the session handle returned from your shared library to a user tag refnum and also one to deallocate it, or use internal LabVIEW manager functions to do that.

 

But unless you write drivers for some kind of interface in external shared libraries, the user tag refnum has no practical meaning for you at all. And it requires your shared library to be explicitly written to work with LabVIEW, it's not a means to interface LabVIEW to standard shared libraries at all.

 

By "private diagram nodes" do you mean private methods and properties? As in the brown property/invoke nodes? Is there a tutorial for this anywhere?

[Rolf Kalbermatter]

By "private diagram nodes" do you mean private methods and properties? As in the brown property/invoke nodes? Is there a tutorial for this anywhere?

 

No, private nodes are yellow LabVIEW nodes that are not available in the standard palette (but can be generated with your "Generate VI Object method"). The idea is that your external shared library somehow creates an object reference somehow (usually a pointer to whatever your shared library finds suitable to manage your object) and then this object reference needs to be assigned to the user tag reference. This can be either done on the LabVIEW diagram with such a node after the call to the shared library function to create the object reference or inside the shared library itself by calling undocumented LabVIEW manager functions.

 

Consequently there are matching LabVIEW diagram nodes or manager API calls to deregister an object reference from a user tag.

 

But again unless you intend to start writing shared libraries (C/C++ programming) to allow access to some sort of device, or other functionality, this really isn't interesting at all to you.

 

[Sparkette]

No, private nodes are yellow LabVIEW nodes that are not available in the standard palette (but can be generated with your "Generate VI Object method"). The idea is that your external shared library somehow creates an object reference somehow (usually a pointer to whatever your shared library finds suitable to manage your object) and then this object reference needs to be assigned to the user tag reference. This can be either done on the LabVIEW diagram with such a node after the call to the shared library function to create the object reference or inside the shared library itself by calling undocumented LabVIEW manager functions.

 

Consequently there are matching LabVIEW diagram nodes or manager API calls to deregister an object reference from a user tag.

 

But again unless you intend to start writing shared libraries (C/C++ programming) to allow access to some sort of device, or other functionality, this really isn't interesting at all to you.

 

 

Generate VI Object? You mean like through scripting, right? I mainly just want to see what's hidden in LabVIEW, as I believe I've made pretty obvious in my other posts.

I have seen some interesting stuff in the Style list. Like who's Simon, and why does he have his own gauge? And there's this thing called "User Item" that appears as an I32 indicator, but it's just a box that says "38x38" and can crash LabVIEW. Also there's an "Array Interface Control" which looks like an empty array control, but it's kind of slow, and when I put a control in there it turns yellow. Yes, I know I'm kind of getting off-topic; I'll stop now

Edited September 26, 2014 by flarn2006

[Jordan Kuehn]

Like who's Simon, and why does he have his own gauge? 

https://decibel.ni.com/content/people/SimonH?view=profile

https://decibel.ni.com/content/groups/ui

I believe he was also heavily involved with VI Snippets.

[Rolf Kalbermatter]

Generate VI Object? You mean like through scripting, right? I mainly just want to see what's hidden in LabVIEW, as I believe I've made pretty obvious in my other posts.

I have seen some interesting stuff in the Style list. Like who's Simon, and why does he have his own gauge? And there's this thing called "User Item" that appears as an I32 indicator, but it's just a box that says "38x38" and can crash LabVIEW. Also there's an "Array Interface Control" which looks like an empty array control, but it's kind of slow, and when I put a control in there it turns yellow. Yes, I know I'm kind of getting off-topic; I'll stop now

 

Some of these objects have existed in LabVIEW for a long time and never done much more than crashing it! 

I assume they are cruft left over from some experiments that either were abandoned at some point or the guy who sneaked them in had suddenly left and nobody ever noticed it. The whole LabVIEW code base is huge and no single person on this world has a complete overview of everything that is inside it. 

[lordexod]

Object Manager tags list (*.rc and *.rch file tags).

objmgrtags.txt