decoding auto-generated header #defines

[jephthah]

so im working in an environment (National Instruments) that auto-generates header files for the GUI.

in my GUI, i have 150-some odd LEDs arranged in a matrix to represent a large relay bank. my LEDs are named and sequenced numerically like

PANEL_LED_1
PANEL_LED_2
...
PANEL_LED_150
etc...

which would allow me to easily control the relays in various configurations if i had a one-to-one mapping of the name with the corresponding value

HOWEVER

the freaking environment auto generates all GUI header files, with virtually no rhyme or reason to the sequences, so i wind up with something like this:

#define  PANELRAC_LED_141                 2      
#define  PANELRAC_LED_142                 3       
#define  PANELRAC_LED_143                 4       
#define  PANELRAC_LED_144                 5       
#define  PANELRAC_LED_137                 6      
#define  PANELRAC_LED_138                 7       
#define  PANELRAC_LED_139                 8       
#define  PANELRAC_LED_140                 9

and don't think you see a pattern here, because it gets mixed up later, and any time a change is made to the GUI and recompiled a brand new GUI header file is generated and the entire sequence can be re-arranged.

so my question is how best can i associate the string of the #define'd name with the corresponding numeric value.

obviously i would like LED_140 to equal 140. but i can't force that to happen, because i can't modify the header without potentially breaking it in the future.

so i've done this,

case PANELRAC_LED_1:  
			return 1;
		case PANELRAC_LED_2:  
			return 2;
		case PANELRAC_LED_3:  
			return 3;
		...
		...
		case PANELRAC_LED_124:  
			return 124;
		case PANELRAC_LED_125:  
			return 125;
		case PANELRAC_LED_126:  
			return 126;
		case PANELRAC_LED_127:  
			return 127;
		...
		etc...

but i don't like it.

i'm trying to think of a way to do it with enum or a linked list, but i'm drawing a blank.

.

[Dave Sinkula]

Something like this, maybe?

#define  LED_2  PANELRAC_LED_141                       
#define  LED_3  PANELRAC_LED_142                        
#define  LED_4  PANELRAC_LED_143                        
#define  LED_5  PANELRAC_LED_144                        
#define  LED_6  PANELRAC_LED_137                       
#define  LED_7  PANELRAC_LED_138                        
#define  LED_8  PANELRAC_LED_139                        
#define  LED_9  PANELRAC_LED_140

[edit]No, I guess not. But can you just ignore their version and create your own header?

[Narue]

Why exactly is the environment rewriting your defines to be something different? That kind of defeats the purpose of manifest constants.

[jephthah]

^^ no, that won't work either because you're expecting the original #defines to remain constant... any modification and recompilation of the GUI will generate a new header file.

^ damned if I know. this is a "feature" of National Instrument's LabWindows/CVI environment. It's basically ANSI C with some extra libraries and a GUI creation tool that auto generates a gui header file based on the gui you created.

its kind of a dumb feature really. it doesnt create any other headers for you, so i dont see really where the benefit is other than perhaps savign time tracking down bugs due to typos.

oh, well. now i've got a 150-case long switch statement. its ugly. and probably slow. but f- it, it works, i guess

:ugh: