combo box auto-updating

[Dillon_G]

Still present in 8.5   It's rather an annoying issue.

[viScience]

I would like to reactivate this thread because of the importance of the issue at hand.

There is a very interesting and useful class of applications that can only be acheived through the

use of typedef'd combo box constants.  Consider the use of Current Valve Tables in distributed systems.

The CVT's are actually a form of keyed memory that is used to store data values that can be dynamically

created, updated and read.  NI's System Group version of the CVT uses block diagram strings as variable names.

but this is cumbersome in that if a name is changed you have to find all instances on the diagram and change them manually.

It has been suggested to use typedef'd enum's which will autoupdate on the diagram, but unfortunately cannot be passed into

subvi's without loosing their typedef.  This prevents proper encapsulation of the CVT API.  The only elegant solution is the use of typedef'd combo box constants that will autoupdate.

The change is really only a development environment change, not really a fundamental change to the underlying wire type characteristics.

The contstant itself already has an attribute that links it to the typedef, so why inhibit the autoupdating?

[LabBEAN]

I have to agree with sachsm.  This article addresses why the string datatype cannot support type defined Item / Value pairs.  However, as sachsm points out, our CAR regards the IDE.  Currently, string combo box controls and indicators maintain their link to the type def, but do not update when the type def is changed.

A whole new class of state machines could be developed if this were addressed.  The thing that drives me bananas about string state machines is having to remember / go look up the name of a state I'm about to call (could be 100s of states).  So, alas, I avoid strings except when communicating between EXEs or targets.  Sure would be nice to have one method service both implementations...

[Ben]

Sounds like a reason to use LVOOP since the Classes do maintain their default data as specified in the private class data, so look-up tables can be easily implemented.

Ben

[LabBEAN]

For now we just convert the enum to a string before enqueueing to another EXE / target.  Changing from enum to combo box could reduce comlexity (right after I told JackDunaway that I hadn't ever changed the state/data type def).  LVOOP is great for dynamic dispatch and encapsulation but does add complexity.  Do you have a simple example?

[Ben]

---

LabBEAN wrote:
...Do you have a simple example?

---

No.

My post was based on my reading about LVOOP and that special feature of LVOOP that does maintain the default data from the private class data. This is very unique in LV since the default data of type-def'd cluster are subject to loss when the type-def changes.

Ben

[Gigi_31]

This bug is still there on LabVIEW 2016 f5 version...

Should we wait for an action from NI ? Will pass through enums then...

[paul_cardinale]

Add the following line to your labview.ini file:

EnableStrictTypedefConstantConfiguration=True

Start (or close & restart LabVIEW).

Drop a strictly typdef'd combo box or ring onto the block diagram.

Right-click on it and select "Act as Strict Typedef Constant"

[Gigi_31]

Thank you for your answer. It works fine as you said but it let you do some stuffs which should be done by LabVIEW itself when saving your control as type def...

It is a latent LabVIEW bug. It's sad NI let it there.

Thank you Paul

[RyanWright]

There is a KnowledgeBase article that describes why this is happening:

Item Lists of Combo Box/Ring Constants Do Not Update from Type Definitions - NI

However, I'm not really satisfied with the explanation because this observed behavior only affects combo box block diagram constants that are type definitions and not combo box front panel controls and indicators that are type definitions.  The behavior is inconsistent which makes no sense to me.  The behavior should be uniform whether you are using a control, indicator, or constant.