LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
pine

Enhanced ring to define constant

In text based language, define some constants with meaningful names are very common task. For example, you typically define constant in C like this: 

 

#define RED          1

#define GREEN      2

#define BLUE         3

 

In LabVIEW, you can use ring to define them: 

color ring.PNG 

 

and then you can use the constant very simple: 

 use color ring.PNG

 

But the following definition can not be implemented with ring:

#define RED          1

#define GREEN      2

#define BLUE         3

#define DEFAULT   1

Here, DEFAULT is the same with RED.  But this is not permitted by ring, it will popup a warning if you try to do this: "Waring: Identical values in the Values list are not permitted. The oblject cannot be updated until you assign new values or remove items with identical values. "

 

I know you can use local or global varibles to define constant as a work around, but variables have performance overhead, it is not the best solution as a result. 

 

I propose to create a "const" that allow different items share the same value, and the other behaviours will be the same as a ring. You can also add "picture const" and "text & picture const". 

 constant.PNG

 

The following topic on NI discussion forums inspires me to propose this idea.  

 http://forums.ni.com/ni/board/message?board.id=170&thread.id=435687

 

5 Comments
tst
Knight of NI Knight of NI
Knight of NI

I posted a similar idea here, although I believe my suggested implementation (which is similar to the globals you mentioned) is simpler and more relevant.

 


___________________
Try to take over the world!
tst
Knight of NI Knight of NI
Knight of NI

Also, if your use case is for assigning names to a list of numeric values, a typedef enum is the better option. In such cases, I don't see a need for having another option which is "default". If you do want it as a ring, you can (and have to) use the default case in a case structure. If you want enums with a wider range of options, there have already been ideas for sparse enums and enums with more representations.


___________________
Try to take over the world!
RavensFan
Knight of NI

When I saw this idea, the suggestion of sparse enums came to mind as well.  I think this idea would essentially need to also have "dense" enums where two different constants could have the same value.  Let's say both Red and Green could be the value 2, while Blue is different with 3.  In addition to the sparseness where the value 4 could be skipped in the enum and the next value could be Yellow at 5.

G-Money
NI Employee (retired)

I am going to decline this idea because there is a duplicate that encompasses the functionality and has more Kudos.

G-Money
NI Employee (retired)