topic Re: ComboBox constant autoupdate - suggestions? in LabVIEW

ComboBox constant autoupdate - suggestions?

pitol — Mon, 28 Oct 2019 13:40:29 GMT

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?

Re: ComboBox constant autoupdate - suggestions?

Kyle97330 — Mon, 28 Oct 2019 17:55:18 GMT

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.

Re: ComboBox constant autoupdate - suggestions?

Darren — Mon, 28 Oct 2019 18:20:14 GMT

@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.

Re: ComboBox constant autoupdate - suggestions?

paul_cardinale — Mon, 28 Oct 2019 18:30:43 GMT

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).

Re: ComboBox constant autoupdate - suggestions?

Darren — Mon, 28 Oct 2019 18:40:25 GMT

@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.

Re: ComboBox constant autoupdate - suggestions?

pitol — Tue, 29 Oct 2019 05:37:39 GMT

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?

Re: ComboBox constant autoupdate - suggestions?

Yamaeda — Tue, 29 Oct 2019 09:28:51 GMT

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.

Re: ComboBox constant autoupdate - suggestions?

paul_cardinale — Tue, 29 Oct 2019 12:26:25 GMT

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.

Re: ComboBox constant autoupdate - suggestions?

paul_cardinale — Tue, 29 Oct 2019 13:41:37 GMT

@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.

Re: ComboBox constant autoupdate - suggestions?

pitol — Tue, 29 Oct 2019 14:50:40 GMT

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.)

Re: ComboBox constant autoupdate - suggestions?

Darren — Tue, 29 Oct 2019 15:32:10 GMT

@pitol wrote:
Can you provide more details how you built your XNode?

Sorry to keep being a party pooper, but XNodes are not an officially supported feature. In my Don't Wait for LabVIEW R&D... Implement Your Own LabVIEW Features! presentation, I specifically call them out as rusty nails that you should avoid.

Re: ComboBox constant autoupdate - suggestions?

Darren — Tue, 29 Oct 2019 15:45:05 GMT

@pitol wrote:

I will not be adding new commands to the typedef, rather changing the list completely.

Really? So if I'm using a command, there's a chance you'll remove that command from the list with a later revision of the ring/combo box/enum/whatever? That's a strange use case. Why not maintain the same list and just add new commands after they come up?

Also, if you use an enum, and it contains all the command strings you need, you could use a Malleable VI to convert it to a string. You would not need to update the Malleable VI when the enum updates. This assumes that the enum strings exactly match the command strings. Another advantage of using a Malleable VI is that you could have multiple command enums that all use the same Malleable VI.

Re: ComboBox constant autoupdate - suggestions?

paul_cardinale — Tue, 29 Oct 2019 15:52:43 GMT

@Darren wrote:

@pitol wrote:
Can you provide more details how you built your XNode?

Sorry to keep being a party pooper, but XNodes are not an officially supported feature. In my Don't Wait for LabVIEW R&D... Implement Your Own LabVIEW Features! presentation, I specifically call them out as rusty nails that you should avoid.

Yes, XNodes are very dangerous; and most people should avoid them. But I mess with them anyway (I like XControls too).

Re: ComboBox constant autoupdate - suggestions?

paul_cardinale — Tue, 29 Oct 2019 16:10:18 GMT

@pitol wrote:

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.)

How to build an XNode is a very large topic. And if you head in that direction, you'll be entering dangerous waters. Here's a hypothetical worst case that could happen:

You create an XNode, test it thoroughly, then start using it (in many places).
You make a small, innocuous change to the XNode. But you fail to manage (or don't properly manage) the updating; this could be as simple as a typo in your update code.
You test the new version thoroughly (so you think), and it works fine. You test old VIs that were built with the previous version of the XNode, and they still work fine. Being paranoid, you mass compile those old VIs and retest them. Everything is still fine.
At some later date, those old VIs start breaking, or worse yet, they don't break, they just don't work properly anymore. And this is due to a latent bug in the XNode that has been hiding because of Item 2. The triggering of the bug could be caused by something as innocuous as just moving the mouse over the XNode.

Imagine trying to debug that. VIs quit working properly because of a bug introduced months ago, that comes out of hiding when you move your mouse a certain way.

But if your not scared, have a look at my DAQ Signal XNode.

Re: ComboBox constant autoupdate - suggestions?

pitol — Tue, 29 Oct 2019 16:20:58 GMT

Ok, I'll say I won't use Xnodes...

@Darren

Yes, the use case would be exactly as you said. The only difference will be that those will not be commands, but IDs of registers that the user can select to read/write.

I'm going to provide a control on the palette with the list of registers.

Imagine that a user use the provided control (list of registers) as a constant in his app.

If the user starts from scratch, then there is no problem. The control is up to date when the user starts development of his app.

But after a while, the dev team releases new list of registers. I am updating the typedef with new list of registers.

The user would like to apply new list of registers to the app, but preserving the previous value.

Why preserving?

Let's assume that the user initially selected "5000:BatteryVoltage" ID.

The list has been updated. Now the "BatteryVoltage" is under "6000:BatteryVoltage" ID.

I do not want to update the constant (enum) automatically, because I do not know in what state that specific constant will end up.

I want the user to do it manually.

So I would expect that the previous value will be preserved, but the dropdown list is updated with new list.

Honestly, I think I'll go with ability to go through the project and update all instances of that particular typedef.

I thought I could avoid that but it seems it is not possible.

Re: ComboBox constant autoupdate - suggestions?

Darren — Tue, 29 Oct 2019 16:26:45 GMT

@pitol wrote:

I do not want to update the constant (enum) automatically, because I do not know in what state that specific constant will end up.

I want the user to do it manually.

This functionality is currently available with the Review and Update from Type Def feature. If you update a typedef source (I'm thinking an enum for your use case), and LabVIEW doesn't find an exact match for the value that was previous set in an instance of the typedef (control or constant), LabVIEW will break your VI, and you will use the Review and Update feature to update the typedef instance manually.

Re: ComboBox constant autoupdate - suggestions?

pitol — Wed, 30 Oct 2019 13:01:41 GMT

The Review and Update functionality seems fine, but it has couple of "features" that do not fit into my use case.

If I update the typdef the code becomes broken. I do not want that. I want the code to remain unbroken, with preserved value but having new values possible to be selected.

I know it may sound irrational but it is what it is.

If there are no solution for this use case other than going through all instances of that particular typdef then I can live with that.

Thank you all for the feedback.

Re: ComboBox constant autoupdate - suggestions?

Kevin_Price — Wed, 30 Oct 2019 13:48:53 GMT

From afar, it sounds puzzling to me that you'd want to preserve an old value that might not be valid and also avoid the code breakage that could act as a critical clue about the change.

Code breakage is a hassle, but it's a *valuable* one.

-Kevin P

Re: ComboBox constant autoupdate - suggestions?

billko — Wed, 30 Oct 2019 16:24:45 GMT

I'm becoming very concerned about the direction this topic is taking. It seems to be straying further and further away from LabVIEW best practices, and when you do that, things become very murky and unpredictable. They become fraught with unknowable consequences and make code very, very fragile.

Re: ComboBox constant autoupdate - suggestions?

pitol — Thu, 31 Oct 2019 08:38:21 GMT

If I could, I would easily go with enums and use their power 😉

But the behavior I explained is required by the customer. Preservation of a previous value (regardless if it's valid or not) is a must.

Therefore I am using Comboboxes.

At the beginning I thought it would be cool to update them all automatically, but after some thoughts (and your feedback) I think it will be better to update them consciously by user (by pressing UPDATE THEM ALL!) using some scripting.