how to dynamically change enum strings in private data

[Gabi1]

this is probably out there but could not find it.

i am trying to figure out how to set the strings of an enum typdef, which is the private data of the class. the reason is the program is evaluated by name rather than value of some enums. at init these are inserted into a ring or enum, which i want to transfer forward to the application. so value 0 might not always mean the same thing rather its connection to a specific string. therefore the data of the class, in this case the enum stings, should not be set prior to run time.

Am i doing something basically wrong? i was thinking this should be obvious, especially when one want to connect a class to state machine.

[Tomi Maila]

QUOTE(Gabi1 @ Oct 9 2007, 06:04 PM)

Am i doing something basically wrong? i was thinking this should be obvious, especially when one want to connect a class to state machine.

Yes you are thinking something wrong. Enums are a compile time way to make numbers have a meaning attached to them. I would never ever try to modify enums at runtime. It simpy doesn't make any sense. If you want your logic to depend on strings rather than numbers, then use string per se. Store a string to your private data and wire the string to the conditional terminal of your case structures.

Tomi

[Gabi1]

QUOTE(Tomi Maila @ Oct 9 2007, 09:53 PM)

Yes you are thinking something wrong. Enums are a compile time way to make numbers have a meaning attached to them. I would never ever try to modify enums at runtime. It simpy doesn't make any sense. If you want your logic to depend on strings rather than numbers, then use string per se. Store a string to your private data and wire the string to the conditional terminal of your case structures.

Tomi

Yes Tomi, i used this solution ultimately. i would not go as far as saying it doesnt make sense tough, since conditions by string are very prone to syntax errors, which enums are totally imune from. by updating the enum at run time, the connected typedefs would automatically update. this of course would never work in original LV environment, but in connection with LV classes i tough this could make a very interresting sort of dynamic call (and to me at first obvious - but thinking of it again it might not be so straightforward) .

[Aristos Queue]

QUOTE(Gabi1 @ Oct 9 2007, 03:42 PM)

Yes Tomi, i used this solution ultimately. i would not go as far as saying it doesnt make sense tough, since conditions by string are very prone to syntax errors, which enums are totally imune from. by updating the enum at run time, the connected typedefs would automatically update. this of course would never work in original LV environment, but in connection with LV classes i tough this could make a very interresting sort of dynamic call (and to me at first obvious - but thinking of it again it might not be so straightforward) .

Can't update typedefs at run time. That's an edit to the VIs, and requires the VIs to recompile. We'd have to check all case structures to make sure they cover the enum, break VIs that don't have a "default" case, etc. The string-to-number assembly code compiled into Format From String prims would need to be regenerated, etc. Enums are compile time set and are set in stone.

What you *can* do with LVClasses is this: Get rid of your case structure entirely. Replace it with a dynamic dispatch subVI "DoSomething.vi" on class Parent. Then load a new child class into memory for each string you would've wanted to dynamically instantiate. Each child class would know how to interpret zero for its own uses. This gets rid of the error-prone string compare, keeps everything type safe, and allows you to expand handled cases dynamically.

[Tomi Maila]

QUOTE(Aristos Queue @ Oct 14 2007, 10:19 PM)

What you *can* do with LVClasses is this: Get rid of your case structure entirely.

I'll eagerly wait for the LabVIEW version where I can get rid of case structures entirely by simply using LVClasses

[Aristos Queue]

QUOTE(Tomi Maila @ Oct 14 2007, 03:16 PM)

I'll eagerly wait for the LabVIEW version where I can get rid of case structures entirely by simply using LVClasses

In the mean time, you should see if you can come up with a G tool that can autodetect unneeded case structures and script classes to replace the functionality. :thumbup:

[TG]

QUOTE(Aristos Queue @ Oct 14 2007, 07:19 PM)

What you *can* do with LVClasses is this: Get rid of your case structure entirely. Replace it with a dynamic dispatch subVI "DoSomething.vi" on class Parent. Then load a new child class into memory for each string you would've wanted to dynamically instantiate. Each child class would know how to interpret zero for its own uses. This gets rid of the error-prone string compare, keeps everything type safe, and allows you to expand handled cases dynamically.

I'd give anything to see a (reasonably) simple example of this.

PS: This is not a challenge

[Aristos Queue]

QUOTE(TG @ Oct 14 2007, 06:04 PM)

I'd give anything to see a (reasonably) simple example of this.

PS: This is not a challenge

Take a look at the http://eyesonvis.blogspot.com/2006/08/code-reuse-through-classes.html' target="_blank">Eyes on VIs blog discussion of the Getting Started Window. This is the first of many discussions we've been having about how classes can replace case structures. There's also the example program that ships with LabVIEW 8.2/8.5: <labview>\examples\lvoop\BoardTesting\ That example has raised the ire of many people because it implements a test bed system once in OO and once procedurally, and it paints the procedural version in a bad light by deliberately making some bad design decisions. But that was done to highlight the change from one system to the other. One of the major refactorings in this example is the replacing of the case structure with a class hierarchy, making the system dynamically expandable and not limited by having to actually edit a case structure in order to handle a new board type.