enum edits break queue function

[aartjan]

I am using an enum datatype with a queue to create a data manager subvi. The problem starts when I add items to the enum: all the wires to the queue functions break. I understand that I changed the datatype and that the queue functions are some kind of polymorpic functions that adapt to the datatype you wire to it. What I would like to know is how I can easily make the queue functions adapet to the new datatype. Or should I fall back to strings instead?

[Dynamik]

Hi Aart-Jan,

      I tried this (under 6.1) but didn't see the problem.  Would you mind attaching a [broken] example?  Is it possible there's a diagram constant (of the enum), that wasn't/isn't liinked to the [enumerated] type-def?

D.

Message Edited by Dynamik on 09-14-2005 03:06 PM

[Chaos]

You can still use enums if you wish.  Its not all that much more work when you get used to it.  What you'll need to do is right click the first enum (usually the left most) and create a control out of it [Change to control].  Move to the front panel, right click the control there and navigate to [Advanced>>Customize] which will bring up the controls editor.  Next to the wrench icon in the toolbar is a pull down menu.  Set this to "Type Def." and save the control.

Type Defs, by definition, are all the same so changing the different options for the new control will filter down to all the constants created from it.  To make the front panel neater you can hide this control so its not normally seen.  If you need to add new items or modify one just double click the control from the back panel and you should go to the editor again.  Change here / save / done.

[aartjan]

Well, I use 7.1, so here is a screenshot. The enum is a strict typedef. If I edit the enum typedef, the queue out wires break and I have to replace most of the queue functions to fix it.
The other cases in the vi contain enqueue, dequeue and realease queue.

[tbob]

The reason the wires break is that once the enum structure is set up and wired to the queue functions, that enum structure definition is set in stone in the wiring.  By adding another element, the wires do not see the same structure that was defined when it was originally set up.  So the wires break.  Doing what Chaos suggests is the best way to go.  By creating a custom control with the enum, the wires look at the control for the definition of what it is carrying.  When the custom control is edited (adding an element), you then have the ability to apply the changes throughout the vi, everywhere that control is used, even in the wires.  So the wires see the new definition and all is well.  After you edit the control (add an element), click Apply Changes (I think it is under one of the top menu headings), and Labview makes everything right for you.  What a great language.  Try that in an text based language.

[Chaos]

Ahh ok, theres the problem.  Your type def is being hidden by the cluster "wrapper" if you will.  You should bundle the two ahead of time into a cluster control and make that the type def itself.  See attached picture for a clearer idea. 

[Dynamik]

Hi Aart-Jan,

     It looks like CHAOS has a solution!  Oh well, for what it's worth...

      I coded this (attached) under 7.1, used a strict (simple) enum bundled with variant, but was unable to reproduce the problem.  I've experienced odd behaviour related to type-def ambiguity at the output of case structures, and where shifted value is supposed to determine type in other cases.  I'd try, instead of deleting/replacing the queue operators, deleteing/re-wiring, forcing shift-register to use queue-type from case shown.

Cheers,

D.

Message Edited by Dynamik on 09-14-2005 04:24 PM

[aartjan]

Guys, guys.. I am already using a typedef. The problem is that during development sometimes new items need to be added, and the queue functions seem to have lost it polymorpic ability to adapt to the new type. Putting the enum and variant together in a typedef does not change this problem. Take a look at the picture (after I added an item to the enum). The only solution seems to be to cast the enum itself to a variant.. or is there a way to "reset" the queue function?

[JeanPierre]

What is on the false case? When I wire the refnum straight thru, the wire adapts to enum type changes but if the wire passes thru queue functions it breaks the wire on enum type changes.

[aartjan]

Okay guys, here's the code in 7.0. Hope you can make something from it. I get the problems as soon as I add an item to the typedef enum.

As for the example: I changed it to look like mine, and the problem did not appear!! I am confused..