typedef'd enum screw up in case sturctures

[klompmans]

Hi all,

I found a problem when using typedef'd enums with a case structure: If a case is to be selected for multiple values of the enum, and the typedef is updated labview will sometimes incorrectly update the case structure.

Let me use an example:

I have a statemachine in which each state corresponds to a certain value of the enum. Let's say I have states Error,Idle,Working,Paused, and Aborting. Now I use a seperate VI as a state manager to check whether each state transition is actually allowed. In this state manager I got a couple of case structures, let's say I define that one case should be executed if the enum is Idle, Working, Paused or Aborting. After I typed in all these values, labview automatically changes my input in the case selector label to "Idle".."Aborting", since all these four states correspond to subsequent values of the enum. So far it's all fine.

However, if I change the typedef'd enum, let's say by changing the order to Working, Error, Idle, Paused, and Aborting, labview does NOT update the case structure correctly. The case structure will still read "Idle".."Aborting" which is obviously wrong, as it should state "Working","Idle".."Aborting" now. The same kind of problem arises when I add other enum values and move them in between Idle and Aborting. I think this behaviour is not desirable...

Do you guys know whether this is a bug or whether I'm screwing up here? In my arrogance I think it's a bug 🙂

Thank you,

Klomp

Oh, I used strict typedefs here, so it's not a matter of switching the `update' property on.  Also, I know there's a workaround in making a seperate case for each value of the enum, but that kinda means more work, and I think it should be possible in one case as well.

[andre.buurman@carya]

I.m.h.o. its not directly a bug as it is how the programmers have intended it to work. But they have made an error in thinking that collapsing the list of items to "x".."y" is what the user always wants.

A product suggestion would be to allow the user to undo the list collapse to the original entered list, so when an item is inserted in the enum the case structure displays an error for an undefined case.

[CoastalMaineBird]

I can confirm this behavior.

I made a strict typedef enum with "A", "B", "C", "D"", and "E" values.

I made a case structure with an instance of the enum as the selector.

I set one case to "B", "C", "D", and it was changed to "B".."D".

I added an item to the enum, after "C", called "C+".

The case structure did not change, though. meaning that my intent was changed, since I originally asked for 3 cases.

If I edited the typedef to move "D" up before "A" (order is now "D", "A", B", "C", "C+", "E" ), the case structure updated to "D".."B" A complete change of behavior.

This is on LabVIEW 7.1, and 8.2.

There's probably no real solution except for LabVIEW to abandon the idea of consolidating case selectors (turning "B","C","D" into "B".."D" ).

Even so, if you type "B".."D" into the selector, and THEN change things so that B comes before A (as I did) then what possible result could happen?

I'm not so sure it's a bug, so much as a situation where it cannot possibly figure out what you mean. 

Message Edited by CoastalMaineBird on 04-01-2009 08:05 AM

[AdnanZ]

The changes in the strict type def enum doesn't carry over to the cases of the case structure. It's not a bug but could be a good product suggestion.

[CoastalMaineBird]

A product suggestion would be to allow the user to undo the list collapse to the original entered list, so when an item is inserted in the enum the case structure displays an error for an undefined case.

But if I explicitly enter "B".."D", that means that  I want everything between "B" and "D", inclusive.

If I then insert a "C+" after "C" in the typedef, should that be in the case selector, or not?

It seems to me that there's no way to answer that question correctly every time. 

[klompmans]

Well, I'd say that if the user lists seperate values and labview collapses them on its own account, the user actually actually meant to say the case is valid for those enum values (and for these values only). In this case, labview should know that it actually changed the users intent, so if I change the order of the values or add new ones, it should revert to the uncollapsed list of values and handle it properly.

However, I agree that if the programmer defines a range of cases, it's kind of undefined what labview should do if the enum is changed.

I think that including an option to turn auto-collapse off would do the trick - solves my problem at least.

Thanks for thinking along 🙂

Oh, I forgot to say I use LV 8.6.1

Message Edited by klompmans on 04-01-2009 08:40 AM

[klompmans]

OK, I sent it in as a product suggestion.

[andre.buurman@carya]

What I was trying to explain is to have to ability to switch back and forth between to two styles. Or that LV doesn't automagically change it, something like to automatic changes in MS Word that can be undone by CTRL-Z.

I have also entered it as a product suggestion, so there are at least 2.

[klompmans]

I agree. Let's hope NI agrees as well...

Thanks again,

Klomp