Add "old/new" string to "Edit Cell" event data node

[ConnerP]

Single control items have "NewVal" and "OldVal" in the Data Node for Value Change events. This is applies for numeric, boolean, and strings. It would be nice if this feature were included for listbox and multicolumn listbox labels for the "Edit Cell" events.

Use case: I use a listbox to show the materials for which the user has defined experiment settings for. These settings are saved in an XML file with the material name as an attribute. In the event that the user wants to edit the name in the listbox, it would be nice if they could just do that directly in the list box and the XML change will be handled automatically in the background. Currently to find the right element in the XML, I use an XPath to search for the label selected from the listbox. If the user edits the name, I need to know the old value in order to replace the existing name. Presently, this does not work as the Event Data Node only supplies me with the new value.

[wiebe@CARYA]

"Edit cell?" gives the new value in Event Data Node "String". The old value is still readable from "Item names", and can be indexed with the Event Data Node "Row".

[ConnerP]

Ah that does indeed make sense and means I can implement this feature as I had imagined.

However, I still think it would make sense to put both strings into the event data node because if someone is going to use the Edit Cell? case, they are very likely to want the old value. This would remove two items from the case including a property node. It isn't significant reduction, but I still think this is a reasonable request for a small but valid improvement.

[wiebe@CARYA]

Agreed, an old value Event Data Node item would not be out of place in Edit Cell?.

[AristosQueue (NI)]

Adding that to the Event Data Node would be relatively expensive (relative to the current overhead) as it would incur a data copy of the existing cell data even if you weren't using the data. Would require a considerably different under-the-hood design (for the whole events system!) to avoid that data copy for event structures that didn't use that value.

That's not a reason to not do this, but it would be a downside to adding it.

[ConnerP]

I have no idea how this stuff works under the hood, but would it really be that much different for the listbox labels compared to any other control? Clearly it was decided the copy there is not an issue.

[AristosQueue (NI)]

It would be different -- "Value Change" is a committed event, not a filter event. There's no need for the system to roll back to the old value, so the old value can simply be moved out to the wire without a copy. "Edit Cell?" is a filter event (note the question mark), which means that the old value is still in use, and so we would have to make a copy for the event structure to use. Even if we found a way around that (and there are options), sharing a value out of the middle of an array requires us to know that no one is modifying the whole array. Sharing a control's whole value is easier.

LabVIEW makes a lot of nasty problems go away before our users are even aware of them. 🙂

[wiebe@CARYA]

On the other side, the expensive copy would only happen when a used commits a cell edit. It's not going to happen thousands of times per second, like mouse moves.

Does this data copy happen even if the Event Data Node item is hidden? Or only when it shows and not used?

So it is relatively expensive, there is a workaround and there are downsides if implemented... I can see where this is going!

[AristosQueue (NI)]

> Does this data copy happen even if the Event Data Node item is

> hidden? Or only when it shows and not used?

Under current design, it wouldn't matter if the data node was visible or invisible, wired or unwired. The event generator generates the event without knowledge of what subpieces will be used by all the registrants.

> So it is relatively expensive, there is a workaround and there are

> downsides if implemented... I can see where this is going!

Yeah. I try to not kill ideas outright until we talk through the limitations, but this one seems doomed to be classified, "doable, helpful to some, but probably not a good idea to do overall."

[ConnerP]

Re altenbach:
> Yeah. I try to not kill ideas outright until we talk through the limitations, but this one seems doomed to be classified, "doable,

> helpful to some, but probably not a good idea to do overall."

Understandable. It is usable as is, just not as elegant as it could be. It was worth a shot.