LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Programmatically editing typedef enum strings or ring strings and values?

Hi Smercurio,

      I think Tomi could programmatically open an typedef, edit it, then simply recompile the application and have everything work - because the enumerated string-names are the same.  Of course the nice thing about enums is that they keep the diagram readable.  Tomi's idea seems like a beautiful approach.  However, if he used rings instead of enums, he'd be in trouble.  After changing a ring typedef, the diagrams would show the new ring-string-value but keep the old integer value, not (i think) what he wants.

Cheers. 

Message Edited by Dynamik on 03-02-2006 04:33 PM

When they give imbeciles handicap-parking, I won't have so far to walk!
0 Kudos
Message 11 of 15
(1,960 Views)
Ah, but the key is that the enumerated string names would *not* the same eventually. That's exactly what he's trying to change. As a later post said, he could be adding new ones or deleting ones that are no longer being used based on the C code. Once you do that some LabVIEW code *will* break, such as a situation where an enum is driving a case structure that does not have one of the cases set as "Default" and new enumeration values are added. I think Tomi realizes this. At least I hope he does.
0 Kudos
Message 12 of 15
(1,953 Views)
You're right! - that's what I get for not paying attention. Smiley Very Happy
A default-Case would be required to cope with new names, and even when there is a Default case, dissappearing enumeration-strings will break Cases that have them selected.
 
Oh well, it was fun while it lasted...
 
Cheers.

Message Edited by Dynamik on 03-02-2006 07:15 PM

When they give imbeciles handicap-parking, I won't have so far to walk!
0 Kudos
Message 13 of 15
(1,947 Views)
Adding new ones is not a problem but deleting old ones is. But if the library no more supports an old one, then the Labview code must break. It's better to see at compile time that there is a problem with certain typedef values and correct them rather than let the program seem ok and let the library crash.
--
Tomi Maila
0 Kudos
Message 14 of 15
(1,937 Views)
True, but It seems like there should be a way to insure the right value gets to the CLF, without recompiling.  Maybe your DLL can return a SW revision# that has to match some INI section name.  You could pull DLL input parameters from the appropriate INI section...  Of course if the DLL function prototype changes, a recompile is probably unavoidable...
When they give imbeciles handicap-parking, I won't have so far to walk!
0 Kudos
Message 15 of 15
(1,931 Views)