Malleable wrapper for Traverse for GObjects

[paul_cardinale]

Here's the whole thing reworked so it handles Generics (instead just GObjects).  Now it works with things like Pages and Flat Sequences (why aren't those GObjects anyway?).

[wiebe@CARYA]

---

@raphschru wrote:

---

wiebe@CARYA wrote:

Take a ClassSpecifierConstant, use AllTypes[]. Call another VI, with each class specifier type, run the VI with the variant magic, get the result, store it in a functional global.

---

I'm not exactly sure how you would do that.

AllTypes[] only gives you roughly a Class ID String (which is similar to my "Type Code" extracted from the variant but not exactly the same for all classes, e.g. GenClassTagFlatRef) and the Class Name.

So something is missing to link my refnum type code to the class name.

And how would you detect when the infos need to be refreshed ?

Everytime you use VI Server at runtime, microseconds turn into milliseconds, which I want to avoid for a such frequently used function.

---

So you can make a VI A that takes a class reference, and gets the enum value, right?

You can also get a list of all classes.

So, set the class of VI A, collecting the result. Repeat for all classes.

This will build a LUT, and this will take forever. That's why you do this once, and store the results in a buffer. If the buffer is full, use the buffer, if not, fill it with the slow algorithm.

You can even make it more fancy. For each request, check the buffer. If the item is there, use it. If not, get the result with the slow algorithm and store it in the buffer. Not that this is better per se, it will be faster to start, but slow for new items.

[wiebe@CARYA]

---

@raphschru wrote:

A lot better: 100-160µs !

There's still this weird class called "GenClassTagFlatRef" that does not work because its type code (16469) is different from its class ID (122).

I don't know what this class represents, but that's another point in favor of the static LUT 🙃.

Both my script and runtime subVI use the refnum type code to link to the class name, so there's always a match.

---

Not sure if this helps, maybe a little:

[paul_cardinale]

I more often need to Find an Object by Label than to find all objects of a particular type.  Here it is.

[paul_cardinale]

---

wiebe@CARYA wrote:

---

@raphschru wrote:

---

wiebe@CARYA wrote:

Take a ClassSpecifierConstant, use AllTypes[]. Call another VI, with each class specifier type, run the VI with the variant magic, get the result, store it in a functional global.

---

I'm not exactly sure how you would do that.

AllTypes[] only gives you roughly a Class ID String (which is similar to my "Type Code" extracted from the variant but not exactly the same for all classes, e.g. GenClassTagFlatRef) and the Class Name.

So something is missing to link my refnum type code to the class name.

And how would you detect when the infos need to be refreshed ?

Everytime you use VI Server at runtime, microseconds turn into milliseconds, which I want to avoid for a such frequently used function.

---

So you can make a VI A that takes a class reference, and gets the enum value, right?

You can also get a list of all classes.

So, set the class of VI A, collecting the result. Repeat for all classes.

This will build a LUT, and this will take forever. That's why you do this once, and store the results in a buffer. If the buffer is full, use the buffer, if not, fill it with the slow algorithm.

You can even make it more fancy. For each request, check the buffer. If the item is there, use it. If not, get the result with the slow algorithm and store it in the buffer. Not that this is better per se, it will be faster to start, but slow for new items.

---

Like this?

[Hooovahh]

Just for completeness I thought I'd mention I did make this for XNodes over here before VIMs were an official thing.  It works by specifying the type with a right click menu that is made at run time.  My method for building the menu is done by having a Class Specifier Constant, then getting the All Types property of it, then rebuilding a menu using its results.  I did it this way because some of the classes that a developer has access to might change depending on their environmental settings, so I didn't want just a hard constant of accessible classes there.  This way it will have the classes that the developer could actually use.  Sorta like Paul was suggesting.

Mine is quite inefficient, could probably be improved in many ways, and is using an undocumented feature of LabVIEW.  Having a VIM for this is a great idea as an alternative.

[paul_cardinale]

---

@paul_cardinale wrote:

I more often need to Find an Object by Label than to find all objects of a particular type.  Here it is.

---

That version throws an "invalid reference" error if the object can't be found.  To be consistent with the built-in "TRef Find Object By Label.vi", it shouldn't return an error, it should just set "Found?" to false.  Fixed version attached.