ComboBox constant autoupdate - suggestions?

[pitol]

Hi,

Before I start I want to clarify that I am aware of the separation of value and type for Combobox controls.

I know that updating Combobox typdef does not update any combobox constants used in VI.

I'm looking for a suggestion that might help me out with what I want to create. Perhaps Comboboxes are not the best solution here, but let's see.

First I would like to quickly explain what I want to achieve.

I have a list of commands, for example: "A" and "B" (in real app, there will be >1000 commands).

I'm keeping those commands in Combobox Strict Typedef Control.

In my application I'm using those commands mostly as a Combobox constants.

Now I would like to update the Combobox Strict Typedef to remove "A" and add "C".

That's easy... But the constant does not update (I know...).

What I would like to have is to KEEP the previous value as selected, but have the drop down menu updated.

The reason for that is simple - I do not want to break anything that was set before the typedef update.

I would use the enums but whenever I update Enum Strict Typedef I will loose previous value of a constant.

Does anyone have any suggestion how can I achieve this behavior?

[Kyle97330]

You can do this if you do a "right-click -> replace" on the constant, and select the newly updated type definition as the thing to replace it with.  The value will be preserved, the drop-down will update.

If you have tons of these, you can automate it with VI scripting.  This should do it for all constants in one file:

You can modify it to do this to all files in a directory, in your project, whatever scope you want.  That part's up to you.

[Darren]

---

@pitol wrote:

I would use the enums but whenever I update Enum Strict Typedef I will loose previous value of a constant.

---

As long as you add new items to the end of the enum, the constant values will be preserved when you edit the enum typedef.

[paul_cardinale]

In your labview.ini, add the following line:

EnableStrictTypedefConstantConfiguration=True

(If LabVIEW is open, you'll have to close & reopen for the changes to take effect).

After you drop a combobox constant on the block diagram, right-click on it and select "Act as Strict TypeDef Constant" (you'll have to do that for every CB constant).

[Darren]

---

@paul_cardinale wrote:

EnableStrictTypedefConstantConfiguration=True

---

This INI token is not an officially supported feature. It is not fully tested, experimental, and could cause other issues in your code.

[pitol]

Thanks you all for your suggestions.

Let me answer you all one by one.

@Kyle97330

Unfortunately I cannot use references to find all instances of that particular typdef in my final app. I can only update the typedef itself.

(EDIT: after some thoughtful discussion with my colleagues we may go with the references, but if there is a chance to avoid iterating through all of the BD constants I would love it)

@Darren

I'm aware of that behavior but unfortunately I will not be adding new commands to the typedef, rather changing the list completely.

Therefore the Combobox seems to fit perfectly here.

@paul_cardinale

I would go with Darren on this. We tested that item but it does not meet our expectations. It only works if you do all the work manually.

We want to do it automatically so... nope...

Maybe I will explain more what I want to have.

I am going to provide a control (typdef) with a list of commands.

Any other user can use that control (typdef) in his app.

I want to provide an update functionality to change the list of commands in that particular control (typdef).

I would like that all users using that control (typdef) will have automatically updated all of their instances in their apps, including block diagram constants. But of course, preserving the original value. 

Im talking only about development. It is not intended to work in executable.

Any other suggestions?

[Yamaeda]

It sounds like you want a Text Ring with "allow undefined values" active, then update the Strings[] property to the new list. This list will not be a typedef as it'll be changing dynamically.

/Y

[paul_cardinale]

---

Maybe I will explain more what I want to have.

I am going to provide a control (typdef) with a list of commands.

Any other user can use that control (typdef) in his app.

I want to provide an update functionality to change the list of commands in that particular control (typdef).

I would like that all users using that control (typdef) will have automatically updated all of their instances in their apps, including block diagram constants. But of course, preserving the original value. 

Im talking only about development. It is not intended to work in executable.

Any other suggestions?

---

I would make the typedef'd control an enum, with the enum strings being the names of the commands.  And partner the enum with a VI that translates an enum value into a command string.

Then when you make changes to the command set, you have only to update 2 files: the enum typedef and the translation VI.

[paul_cardinale]

---

@pitol wrote:

Maybe I will explain more what I want to have.

I am going to provide a control (typdef) with a list of commands.

Any other user can use that control (typdef) in his app.

I want to provide an update functionality to change the list of commands in that particular control (typdef).

I would like that all users using that control (typdef) will have automatically updated all of their instances in their apps, including block diagram constants. But of course, preserving the original value. 

Im talking only about development. It is not intended to work in executable.

Any other suggestions?

---

If the typedef only needs to be on the BD, and never on the FP, I personally would be tempted to make an XNode; but that could get very complicated.  I've done something similar: It's an XNode that translates a signal name into a DAQmx task name based on a translation .INI file.  On the BD, it looks similar to a combo box.  The dropdown list of signal names is populated from the key names in the .INI file.  The value output is the DAQmx name taken from the corresponding key value in the .INI file.  In our system, NI-Max (which defines the DAQmx names) lives on our Universal Test Racks; and the translation .INI files live on USB drives inside adapters that go on the racks.  It works well, but the XNode is extremely complicated.

[pitol]

XNode would be a nice solution but I'm not that experienced in that area.

Can you provide more details how you built your XNode?

Our expectation will be very similar to what you did: to have Combobox populated from external source (file, other control, etc.)