ComboBox constant autoupdate - suggestions?

[Darren]

---

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

[Darren]

---

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

[paul_cardinale]

---

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

[paul_cardinale]

---

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

1. You create an XNode, test it thoroughly, then start using it (in many places).
2. 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.
3. 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.
4. 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.

[pitol]

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.

[Darren]

---

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

[pitol]

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.

[Kevin_Price]

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

[billko]

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.

[pitol]

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.