Equivalent to C Defines / sparse enums

[tfritz]

Hi,

I'm looking for a way to implement defines / sparse enums in Labview easily. For example if I use Labview to communicate with a device that has a set of commands, I want to define the possible commands in a central location and if new commands are added or the numbers change or whatever, I want this to be propagated to all places where it is used.

I already searched in the forums a little but didn't find a satisfying solution.

An enum doesn't really do the job if the values are not sequential. One way I could do it is by using a case structure or an array additionally but this means always keeping two places up-to-date. A text ring would be the better solution (though I still miss the possibility to map different names to the same value, which I need in some cases) but the big letdown is that constants of a text ring strict typedef are not updated so it is useless for what I want.

Actually I just want something like

typedef enum
{
    FOO = 0,
    BAR = 0,
    FOOBAR = 10
} foobar;

or 

#define FOO       0

#define BAR        0

#define FOOBAR 10

which is standard in C but seems unnecessary complicated and not straight-forward in LabView. Is there an elegant and easy solution? If not, are the LabView developers aware of this shortcoming and will it be implemented in future releases?

Thanks,

Tobias

[parthabe]

---

tfritz wrote:

are the LabView developers aware of this shortcoming and will it be implemented in future releases?

---

You can post you idea here, if you wish to see it in a future release.

[chrisger]

Hi there

first of all i also miss a "#define" equivalent in LabVIEW. I only can encourage you to post this suggestion here like parthabe mentioned.

Try this:

- create a cluster, each element in the cluster stands for a #define, so you can refer to that element by its name using unbundle by name function

- create a VI with the strict typedef cluster as an indicator and set the clusters elements inside the VI

- to retrieve the values call the vi and unbundle the cluster 

By doing so the data is stored at one single location and it is not possible to overwrite the data from the outside (like with global variables)

[tfritz]

Thanks, I will post it there.

The cluster idea seems like a reasonable workaround. However, it is much less readable then just an enum constant at least at a first glance (if I would see a VI that uses it, I would wonder what this subVI is good for). But thanks anyway, I'll consider it!

Tobias

[Andrey_Dmitriev]

Hi, Tobias,

There are many different ways how to implement this, depends from your needs and architecture.

In some cases just Globals may be useful (they are not always bad).

You can also create SubVIs like containers for your #defines, or using universal Functional Global VI, where these values will be stored - this is most flexible way. See examples:

Andrey.

[Mark_Yedinak]

I think everyone missed the obvious answer. You can use a ring control to achieve what you would like. Although you cannot have two items with the same value. The nice thing about ring controls is that you can initialize them pragmatically so you can load the values from a file or database if desired.

[chrisger]

"You can use a ring control to achieve what you would like."

No, you can't. The goal is to have the identical global constant VALUE at different locations in your app and not the same SET of values.

Instances of a strict typedef ring control DO NOT update the value they return when you change the value set in the typedef (mentioned earlier in this post). Because you want to define/change the value of the "#define" at one single location in your app/project a strict typedef ring will not do.

<edit>

Also the "#define" feature should work for all kind of data types, not just integers.

</edit>

Message Edited by chrisger on 09-17-2009 08:01 AM

[tfritz]

Hi,

thanks for all the replies. Yes, as I said and as Chris stated correctly, Rings won't do the job.

Andrey, could you save this as Labview 8.20 compatible? I cannot open it. Thanks so much!

By the way, I didn't post a new idea but added to an existing idea here. I really hope they will add this someday.

Tobias

[Mark_Yedinak]

Yes, I stand corrected. The typedefs don't update as you would like them to do. I would suggest that you enter this suggestion on the Idea Exchange. It would be nice for enmus to be extended to support this functionality.

[tfritz]

Well, according to NI, "it's not a bug, it's a feature", as you can read here.

I kind of understand the reasons for this design choice but I think the solution would be to really introduce a "define" type. Or at least an enum type as in C.