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.

.

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?

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

^^ 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:

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.