Ring Type Def Benefit?

[jyang72211]

Since making changing to a ring type def will not update the rings of the type def on the diagram, what are the benefits of making ring into a type def.  In face, what is the beneift of using ring at all?  Couldn't I just use enum exclusively?  It seems like using a ring type def is a lot of trouble for little to no benifit.  I must be missing something. 

[nathand]

I often set the items in a ring programmatically, which is not possible with an enum.

Also, rings let you use arbitrary values.  They do not need to be integer data types.

EDIT: as for why use a typedef, kind of a strange question... you can make any type of control into a type definition, why would there be an exception for a ring even if it's not used very often?  There's definitely use cases for rings as strict type definitions, when you need several instances to have the same formatting.

[Ben]

---

@nathand wrote:

I often set the items in a ring programmatically, which is not possible with an enum.

Also, rings let you use arbitrary values.  They do not need to be integer data types.

EDIT: as for why use a typedef, kind of a strange question... you can make any type of control into a type definition, why would there be an exception for a ring even if it's not used very often?  There's definitely use cases for rings as strict type definitions, when you need several instances to have the same formatting.

---

I have been reviewing the LV Advanced course work lately and it recomends rings in the API to get a llilte more documentation from the diagram.

NI Uses them in many of their toolkits as well.

I have been bit more than once by the ring since they do not carry the data in the wire when toolkits where updated and the ring values changed.

If I am not looking to develop a toolkit I prefer the type-def'd enums since they will either update or break while the rings will sneak up on me and bite me.

In the case of API's passing the value as strings and checking the parameter for validity seems as robust as I can get without putting the users code in update jeopardy.

Ben 

[jyang72211]

About ring type def, I see the greatest benefit of making a ring or any control into a type def is being able to update a control in one central place and not needing to update a million controls all over the diagram.  However, for a ring, even if you make it into a type def, you don't have that benefit.  I can see that using strict type def would still be useful, since the format is controled, but I am not sure about type def.

[jyang72211]

Ben - So if you have a choice you will use string and enum instead of ring?  what did you mean by the following?

In the case of API's passing the value as strings and checking the parameter for validity seems as robust as I can get without putting the users code in update jeopardy.

[nathand]

If you're trying to find a use case for it, you might as well ask when you would want a typedef'd boolean (probably never, unless you expect the data type to change some day).  However, there's no reason not to have the ability to make a ring into a typedef.

[Ben]

---

@jyang72211 wrote:

Ben - So if you have a choice you will use string and enum instead of ring?  what did you mean by the following?

In the case of API's passing the value as strings and checking the parameter for validity seems as robust as I can get without putting the users code in update jeopardy.

---

If you update the value string pairs in a ring then deploy it for others to use, their code will no automaticly adapt and COULD break at run time by passing the olde version of the ring to the new API.

A string will never break.

SO if I use a string as the input and code up the API to check if it a string that I support, and return an error if it wrong, then there will be a clear method for the user of my API to ID where and what the issue is.

But that is the case were the API I am developing will be completely independent of the code using it (decoupled).

If the code is part of my app and I control the API and the callers of the API then I will use type def'd enums so that when I update my API the callers can adapt.

If the ring is being selected to allow for an arbitrary string to value mapping, I'll use an case structuer driven by the enum to return the translation.

I hope that clears that up.

Ben

[jyang72211]

If you use string as an input of a subvi, what is your preference in letting another developer knows what are the possible string input options?

You said, "If the ring is being selected to allow for an arbitrary string to value mapping, I'll use an case structuer driven by the enum to return the translation."

Did you mean type casting a ring into enum?  If so, besides the ring type def, don't you have to create another enum type def for type casting?  

[Ben]

---

@jyang72211 wrote:

If you use string as an input of a subvi, what is your preference in letting another developer knows what are the possible string input options?

You said, "If the ring is being selected to allow for an arbitrary string to value mapping, I'll use an case structuer driven by the enum to return the translation."

Did you mean type casting a ring into enum?  If so, besides the ring type def, don't you have to create another enum type def for type casting?  

---

1) VI documenation or documentation for the control itself.

2) Type casting may work but duplicate value in the ring could be an issue.. If I am taking that route of using the ring, then converting to an enum is more work but could save the users of your code headaches since you are doing th work to ensure your code is being used correctly and that major changes don't cause them headaches trying to figure out where old ring values are driving new ring types. Then again you could also use the ring to drive case directly (yes it will be only numeric labels) and le the case return an enum that is type def'd.

Does that help more than hurts?

Ben