01-24-2008 03:59 AM
01-24-2008 06:51 AM
a preprocessor directive such as #def is similar to using typedefs in c. It is not quite as flexible as c but easy to use. Sounds like you want to make an enum, name the ids and then use the enum instead of the number. Create a custom control, make an enum, edit the enum to add the items and make sure you save it as a typdef. Now use this typdef throughout your program instead of the id. if you update the typdef to add elements the changes will automatically update throughout the application. The one major caveat is that unlike enums in c you can not skip indexes for sparse enums nor can you change this list at runtime. But you will make coding much easier just as in c you are defining your ids external to your code.
Paul
01-24-2008 07:02 AM
01-24-2008 07:43 AM
Yes rings can be sparse and can also be changed at runtime, the disadvantage is that they dont autopopulate case structures and the strings[] are not as accessable as enums. Too bad NI has not gotten around to making a sparse enum. I sometimes use 'undefined #' for enum cases to make a sparse enum but this is not all that elegant.
01-24-2008 12:09 PM
01-24-2008 10:59 PM
01-25-2008 04:23 AM - edited 01-25-2008 04:25 AM
That depends on how you want to input the integer, but here's one way, which assumes that the user is selecting it from a closed list.
Note that in this case the value of the ring (0 or 1) corresponds to your a and b.
01-25-2008 06:51 AM
And you can do it even simpler if you use a combo box:
01-27-2008 06:02 PM
I would do #define as a simple vi that returns a value. I do this all the time to define constants throughout programs. I know there is more overhead than your #define preprocessor but it is a clean implementation and the overhead is low when you consider the speed of a current PC.
Paul
01-28-2008 01:09 AM - edited 01-28-2008 01:10 AM
Hi Amit,
A G implementation of "#define" seems to imply pre-compile graphical substitutions - that would be interesting. Of course it's not supported and a work-around seems necessary. I began reading this thread with the same enthusiasm for Enums as tst, and Falkpl, but at this point Enums seem unsatisfactory, expecially in light of your criteria of "not mapping the id to the name again and again during runtime,only once during the start of the program" (that seems to rule-out falkpl's #define VI, but what about tst's idea of parsing the enum's string-representation?)
In "C", instead of the #define, one might accomplish the very same effect (maintaing values in one place) with [global] constants. LabVIEW has constants too - they can be defined in one place and wired to wherever they're used - why not do that? Are you trying to achieve a specific "look" or "effect" on the diagram?
Cheers.