An Argument for Changing Combo Box Typedef Behavior

[viSci]

As many know, LV will autoupdate a typedef'd combo box control but not a diagram constant.

There is a very interesting and useful class of applications that would greatly benefit

from the use of typedef'd combo box constants that autoupdate. 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 has a

version of the CVT that uses block diagram strings as variable names. This approach is cumbersome

in that if a name is changed you have to find all instances on the diagram and change

them manually. Also you have to cut and paste them in the first place. Another possibility is typedef'd enum's which will autoupdate

on the diagram, but unfortunately the enum datatype cannot be passed into subvi's without converting to a variant or string. It is also rather inefficient if your CVT is large

and you have 100's of variable names that would have to be passed around inside of the enum constant attributes.

An alternative and elegant solution is the use of typedef'd combobox constants that will autoupdate. I would like to argue that the change in behavior is really only a

development environment change, not really a fundamental change to the underlying wire type characteristics as it has been argued by NI.

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

Any Comments?