XNode Queue Like Behavior

[hooovahh]

Yeah another XNode question.  This isn't a need but I think it would be a nice feature if it can be done.  Has anyone thought of a way to have an XNode behave like other primatives, where the init defines the data type to be used, and the other functions know the data type and change their output based on it?

 

So lets say you drop a Obtain Queue and wire a string to the Element Data Type terminal.  Now when you use the Dequeue Element, the output changes to a string.  Also the wire color changes but I'm less concerned with that at the moment.

 

The first step in this I thought would be easy but I was wrong.  I made an XNode where it has an input terminal that is adaptive.  I planned on wiring to this a queue and then having this XNode change the output based on the queue data type.  But to get the queue data type I need to read the terminal type which gets returned as a variant, then cast it to a queue, then use a function like preview queue and use the type of the output of that.  The problem is to cast the variant to the queue, you need to know the type of queue it is.

 

I think there are a few more tricks I could try but I was curious what others thing.  Anyone done this?  Anyone got any ideas?

[Sparkette]

If I'm understanding you correctly you want an XNode to return a value of the type contained in a queue passed to it as an input? If so, you could just make the output terminal adaptive as well, and then its type will be determined during code generation according to what's wired to it. Sort of like a generic indicator (generic as in generic VI), except (AFAIK) it hasn't been abandoned by NI.

 

Alternatively you could probably do something with the variant's type descriptor in the AdaptToTerms ability (like what the OpenG variant VI's do) though I don't know how exactly you would parse it.

Edited September 15, 2014 by flarn2006

[JKSH]

Good question; I've been wondering about this too.

 

A nice application would be adaptive and type-safe variant-attribute dictionaries.

[hooovahh]

Good question; I've been wondering about this too.

 

A nice application would be adaptive and type-safe variant-attribute dictionaries.

Oh I've thought about it. This brings about a new problem of sharing data between XNodes which I also would like help in.

Are you sure adaptive types work on outputs? I'm on my phone right now so I'll try that and a few other ideas in tomorrow.

[Sparkette]

Oh I've thought about it. This brings about a new problem of sharing data between XNodes which I also would like help in.

Are you sure adaptive types work on outputs? I'm on my phone right now so I'll try that and a few other ideas in tomorrow.

 

Yep, output terminals can be adaptive too. When GenerateCode is called you can wire any type of data to it, and it will automatically change to that type.

 

As for sharing data between XNodes, you could always use the Message ability. It accepts (and I think returns) a string, and can be called from outside the XNode using an invoke node with an XNode reference. It's a private method, but I think that's more because XNodes are a private technology and NI's XNodes weren't designed with external access to that ability in mind than it being an untested property. Though I can't guarantee anything.

Here's a VI snippet of the relevant method, in case you don't feel like turning on SSPSS just for that one method:

Edited September 16, 2014 by flarn2006

[hooovahh]

Okay I haven't tried out that private method yet but I plan on it.  But I have been successful with the start of this post and have attached a quick example of it.  This has no documentation, very little icons, very little functionality, but it demonstrates an init changing the data type, and a read changing the data type of an output, just run Example Data Type Change.vi. 

 

The majority of the work was fixed by using the adaptive terminal types as flarn suggested.  But there are times that I need to know the data type of the wire, for things like updating the icon to change with the data type change.  I accomplished this by making a template VI that I would edit then run with scripting, from the XNode, which would just make a constant on the block diagram, and pull out the type within the queue, and return it.  There maybe better ways but it does what I want, where an Init VI makes the data type of the wire change, and then the other functions like dequeue changes the output terminals to match.

Circular Buffer XNode Start.zip

[Sparkette]

Actually I just tested it and the Message method gives an error that it's not yet implemented. :/

 

Funny thing is I've gotten that same message from something public as well: the type cast node's Convert 4.x Data property also isn't implemented. You'd think in that case they would keep it marked private if they haven't written (let alone tested) it yet

[hooovahh]

Funny thing is I've gotten that same message from something public as well: 

With scripting you can make an event structure, but in version 2012 and older you couldn't edit the structure, but there were methods for it.  So there was a remove case where you provided the index of the case to remove, but it would also return an error of not implemented.  Since then NI has added full support for the event structure but it just another example where it allows you to do something, then gives a run-time error.