Programmatically editing typedef enum strings or ring strings and values?

[Tomi_Maila]

Is it possible to programmatically edit typedef or strict typedef enum strings or ring strings and values? Or even for a custom control? It it possible for a VI but that won't help me. I want to write enum/ring string / values by calling a C-function and then writing the result to the enum. This enum will then define the interface to the current version of a specific library, the interface of which cannot grammatically change but the values of the enums may change from library version to another.

Message Edited by Tomi M on 03-01-2006 09:20 PM

[smercurio_fc]

You cannot change the item names of an enum programmatically as that goes against the very concept of an enum. You can change the strings (item names) of a ring control, even it's a typedef, though I'm not sure what you'd be gaining by making it a typedef in this case.

Message Edited by smercurio_fc on 03-01-2006 03:51 PM

[Dynamik]

Hi Tom,

      You can change the Strings[] aray of an enum, as long as the enum isn't on an active FP.  See pic.

Cheers.

Message Edited by Dynamik on 03-01-2006 09:21 PM

[Tomi_Maila]

Great Dynamik, it seems to work also for typedefs as long as they are manually opened! For some reason I thought I cannot open reference to a typedef, only VIs.

The reason I need this that there are C libraries, where there has been defined constant values using #define directives and macros. The names of these constants stays the same from version to another but the way they are implemented and even the values may change from library version to another. Also there is no easy way to get the value for compile time macros. I need a way to transform these constant values into a Labview enum. If I make a typedef with the correct strings (and values) for each library version, I can plase this typedef as a control to the labview port of the library functions and pass the typedef value to corresponding version of the library DLL.

When I would like to change into a new version of the library, I can run a small labview program that would call a small C program to get the correct values for each constant, enum etc and write these values to corresponding Labview typedefs. Then I can just replace the old DLL with a new version and everything should go smoothly. The other alternative would be to do the translation from Labview enum values to C constant values at runtime, but this is not something I like as I need high performance in my applications.

An example: Need to transform the following C code to Labview ring.

/* Flags for H5Fget_obj_count() & H5Fget_obj_ids() calls */
#define H5F_OBJ_FILE    (0x0001u)       /* File objects */
#define H5F_OBJ_DATASET    (0x0002u)       /* Dataset objects */
#define H5F_OBJ_GROUP    (0x0004u)       /* Group objects */
#define H5F_OBJ_DATATYPE (0x0008u)      /* Named datatype objects */
#define H5F_OBJ_ATTR    (0x0010u)       /* Attribute objects */
#define H5F_OBJ_ALL     (H5F_OBJ_FILE|H5F_OBJ_DATASET|H5F_OBJ_GROUP|H5F_OBJ_DATATYPE|H5F_OBJ_ATTR)
#define H5F_OBJ_LOCAL   (0x0020u)       /* Restrict search to objects opened through current file ID */

Especially the second last one is the hard one. I was thinking of writing a C utility to which I can pass constant name and it would return the constant value. Then I would call this utility from labview to set the corresponding typedef ring values. Voilá, everything should then work.

[Dynamik]

Hi Tomi,

      The more I think about what you're planning, the more I think:

This is VERY cool!  It's programmatic-editing!

Here's a quick-N-dirty parser that handles ( i think) the specific example you posted.

Cheers.

Message Edited by Dynamik on 03-02-2006 03:38 AM

[Tomi_Maila]

Dynamik, I was thinking more something like this:

A C++ utility that will write the macro strings and the corresponding values to stdout (or to file). The I can read this file in labview and write the strings and the values to ring. C++ will take care of parsing automatically.

#include <iostream>
// macro that will print the marco name and value
# define P(EX) cout << #EX << "\t" << EX << endl;

#define H5F_OBJ_FILE    (0x0001u)       /* File objects */
#define H5F_OBJ_DATASET    (0x0002u)       /* Dataset objects */
#define H5F_OBJ_GROUP    (0x0004u)       /* Group objects */
#define H5F_OBJ_DATATYPE (0x0008u)      /* Named datatype objects */
#define H5F_OBJ_ATTR    (0x0010u)       /* Attribute objects */
#define H5F_OBJ_ALL     (H5F_OBJ_FILE|H5F_OBJ_DATASET|H5F_OBJ_GROUP|H5F_OBJ_DATATYPE|H5F_OBJ_ATTR)
#define H5F_OBJ_LOCAL   (0x0020u)       /* Restrict search to objects opened through current file ID */

using namespace std;

int main(void)
{
  P(H5F_OBJ_FILE)
  P(H5F_OBJ_DATASET)
  P(H5F_OBJ_GROUP)
  P(H5F_OBJ_DATATYPE)
  P(H5F_OBJ_ATTR)
  P(H5F_OBJ_ALL)
  P(H5F_OBJ_LOCAL)
  return 0;
}

[smercurio_fc]

As you said, Dynamik, as long as the control isn't on an active front panel. While you can do this, what's the point of it being an enum? You certainly can't wire it to drive, say a case structure because once you change the strings the code breaks. To the poster: In a later post you say that the names of the contants don't change, only the values. I would *think* that the strings of the enum would match the names of your constants, which as you said, don't change. OK.. so why do the strings of the enum need to change? It seems to me that you're going through a bunch of hoops when a simple lookup table would serve your purpose. That way you don't need to change your LabVIEW code each time you change your library.

[JeanPierre]

See in this thread my tool to convert a C enum statement into a LabVIEW enum.

[Tomi_Maila]

Smercurio, you may be right that lookup tables are required. As a clarification what I meant:

1) Enums: When new items are added to the C library, these can be programmatically added to the Labview enum typedefs. Since the names don't change, LV code stays functional even when some old items are removed. Only case structures that referred to the old removed value will be broken. Addition of new items may require handling new cases in case structures as functionality is added but still, most of the code should function without modifications. I don't see any differences to lookup tables expect compile time "lookup" is faster than runtime lookup.

The compile time lookup produces faster code and should be preferred, I think, if enum or list of #define constants are strictly sequencial.

2) Rings: When C constant values are not sequencial but rather define a set of constants related to some special thing, then LV ring must be used instead of  enum. With rings the case structures follow numbers and not names, and will broke if values are changed. On the other hand, case structures sound a bit odd to be used with rings where value is not an identifier but rather a constant related to a name. In the example C code above the values are flags for different object types and need to be ORed to get the wanted combination.

The runtime lookup is perhaps more safe with rings and enums with non-sequencial data like error codes. Still the LV rings and enums can be programmatically filled using the methods mentioned in this thread but the actual values are fetched at runtime from a lookup table. The lookup table can be a Labview VI which takes ring in and returns the lookup value (type may vary from case to case). The lookup may be based on a hidden array control that, I think can also be programmatically filled based on the C code with the same methods as typedef enums can be filled.

Message Edited by Tomi M on 03-02-2006 06:59 PM

[smercurio_fc]

OK, I think I understand what you're trying to do now. Initially I thought you were trying to do this so you wouldn't have to modify your LabVIEW code. Based on your last post, however, regardless of which method you use you will impact your LabVIEW code and you will need to change it when you change the DLL interface. Also, as for enums vs. rings, you seem to be saying that the only reason you're choosing an enum in one case as opposed to a ring is that the values are sequential. If that's the only reason you may be better off simply choosing the menu ring or text ring and sticking with that rather than using two different types of controls. Depends, of course, on what you're doing in the LabVIEW code.