typdef constant programmatically from it's path

[Ben]

Have you considered a slight change to the data you push via the queue.

Instead of a Variant, queue up a cluster that contains an enum AND a variant.

On the sending side, set the enum to describe the type of data you are sending.

On the receive side unbundle the enum and use it to drive a Case structure where each case has the right type of cluster wired to the "variant to Data".

Moving forward you need only add another entry to the enum to describe a new packet type and a case for the new data type.

As illustrated above, I get a value from a queue as a variant and cast it as a cluster of enum and variant and the enum determine how I cast the variant ... 

Ben

[Hooovahh]

Actually I whipped up a quick demo while you were replying, this does the basics of what I was trying to say.  The same queue is used for two data types, and the loop handling the request can detect what case it should go to, which states what type def to use.  You can use an enum, but it has its pros and cons.  I still prefer using variant attributes, because I heard for large data type (huge clusters) it is faster to use the variant attribute and just pull out the enum/string.

[Ben]

---

@Hooovahh wrote:

Actually I whipped up a quick demo while you were replying, this does the basics of what I was trying to say.  The same queue is used for two data types, and the loop handling the request can detect what case it should go to, which states what type def to use.  You can use an enum, but it has its pros and cons.

---

The enum will break the case structure and remind us to update that code when we add a new type.

What are the "cons"?

Curious,

Ben

[Hooovahh]

---

Ben wrote: 

What are the "cons"?

---

More things to edit when adding new methods.  If this is done with scripting (which my method generation is) then there's more involved.  For me the method name comes from the VI file name, so sending that can be done with code built into the method sending VI, instead of having to update enums with scripting, and have that force a compile change on all VIs that use it, and then use a new enum constant in the method sending VI.  Then when deleting a method you need to remember to delete that value of the enum, and force compile.  Where in my setup I just delete the method sending VI from disk.  There is also more thing that need to be in memory, (the type def controls).  And therefor more dependencies to manage, commit to SCC, more files on disk, etc.

None of these are huge issues, but honestly I've never had an issue using strings for this type of messaging.  I use plenty of enums, but in this case a typo (which shouldn't happen because again scripting generates the methods and states) will be found the first time you run it and go to the default case which generates an error.  In this setup even if there is a typo it is found the first time and then you fix it and it doesn't happen again.

[drjdpowell]

I don’t really understand what is being attempted here.  In real-world scalable messaging systems (like the post office), messages are delivered based on meta data (the address).  The Post Office doesn’t have the need to understand what’s inside all the envelopes.  So why does your “communicator” need to know any of these typedef clusters?

[Ben]

---

@drjdpowell wrote:

I don’t really understand what is being attempted here.  In real-world scalable messaging systems (like the post office), messages are delivered based on meta data (the address).  The Post Office doesn’t have the need to understand what’s inside all the envelopes.  So why does your “communicator” need to know any of these typedef clusters?

---

That is a great question!

Way to do the Socratic method thing!

THe code I shared above could very well have delayed casting the variant data by one step in the distribution of messages and thereby decouple the code that delivers and the code that reads the message.

Thank you!

Ben

[paul_cardinale]

---

@Hooovahh wrote:

What you want to do is not possible, the way you want to do it.  The type must be known at compile time.  You can't write code that changes the cluster output as it runs, you can only link the input and output to a common type def control (again at edit time).  You can have a Variant to Data converting it to the appropriate type but it can cause run-time errors if the type isn't what is expected.

Even NI functions that change data types need to be told what type of data type to be.  The Dequeue element needs a reference passed in from an obtain function, where the data type is specified.  Type cast can turn into anything, but you need the data type as an input telling it what to be.

---

Pretty much true.  However we can push the boundaries a bit.  Attached is my universal indicator that changes what it is depending on what data it receives.  The giant downside is that it only works in the development environment (because it has to edit itself at runtime).

[Hooovahh]

Really Paul?  Password protection?  Isn't this just a subpanel with a Create From Data Type invoke node behind the scenes?  Still as you mentioned this requires the development environment.  If you want a (semi) universal way to visualize data from the run-time engine alone I'd suggest looking into the Variant Probe which more or less flattens data to a tree.

[paul_cardinale]

---

@david_tatrai wrote:

I've made numerous trials with VI scripting, but unfortunately didn't manage to solve the problem. Could you help, how to parametrize the New VI Object function? Thanks in advance.

---