Allow editing of map and set constants

[User002]

Similar to how array and cluster constants on the block diagram can be edited, it would be useful to be able to edit map and set constants on the block diagram.

For example:

In the map constant above, the developer can scroll through and see all of the key value pairs in the map (plus an empty element at the end of the map).

It would be useful to also be able to edit the key-value pairs in the map (and add more key-value pairs to the map by changing the empty element at the end of the map).

[AristosQueue (NI)]

Yeah. This would be nifty. The UI experience was so frustrating that we abandoned it. If you have proposals for specifically how it would work, my team is interested. Specifically:

1. What constitutes "committing" a change to the constant such that sorting is reapplied? Or does a new/changed element immediately sort into position?

2. In a map, if you change or add a key that matches an already existing key, what happens to the conflicting value?

3. In a set, do you need feedback when two elements consolidate?

We kept coming back to some sort of "pop open a dialog where you change the contents and then commit the changes", but it felt really cumbersome. If you have better ideas, post them, please.

[User002]

1 - I imagined it being the same as committing a change to any other constant. When you finish typing and either click somewhere else or hit enter, it commits the change.

I wondered about sorting too. I think it would make sense for it to happen when you commit the change (for a map, sorting only has to happen if the key changes), and for it to keep the element you were just editing visible. So, after committing a change to an element, the scrollbar would move and the size would change. That way, you could continue editing that same element.

[User002]

2 - In a map, if you try to commit a change that changes or adds a key to match an already existing key, nothing happens (maybe the error sound plays) and the map switches to view the already existing key. 

[User002]

3 - I don't think feedback is necessary, but it would make sense for the set to behave similarly to the map. If you add an element that is already in the set, nothing happens and it shows you the other element. If you change one element to match another element, nothing happens and it shows you the other element. 

[AristosQueue (NI)]

"I imagined it being the same as committing a change to any other constant. When you finish typing and either click somewhere else or hit enter, it commits the change."

Imagine if the key is a cluster with two fields. You edit one of the fields and click on the second field. Normally, that would commit the value change in any other constant. Does it do the same here? If so, you could end up stomping on values you never intended to interfere with. This alone means there's some sort of "meta edit" operation that needs to be started (somehow).

[User002]

I hadn't thought about that, but I think what I described in response to your 2nd question (if you try to commit a change that changes or adds a key to match an already existing key, nothing happens) would work for that case.

Specifically, for a key that is a cluster with two fields: 

• you edit one of the fields and click on the second field
• this changes the cluster, and LabVIEW tries to commit the change to the key
  • If there is not already another element with that key, the commit succeeds and the map retains its new value
  • If there is already an element with that key, the commit fails and the map constant reverts to its previous value

[AristosQueue (NI)]

> If there is already an element with that key, the commit fails

> and the map constant reverts to its previous value

I have an existing map of :
[1, 1] -> "abc"

[2, 1] -> "def"

I want to change the key of the first entry to be [2, 2]. I change the first "1" to a "2"... and LabVIEW immediately reverts the edit when I click in the next field?

Cluster keys are not nearly as common as strings or ints, but they aren't rare. It's not a use case we could just let hang out there weirdly, especially if it lead people to think they had made an edit when in fact they had not. This was among many editing weirdnesses... all small, but collectively complex. So we punted editing out of the release to let smarter minds than us design it. 🙂

[AristosQueue (NI)]

By the way... if anyone wants to build an editor for the constants, you could create a custom right-click menu option and write the code for the editor to show us what you'd like to have. I'm literally throwing my hands up and saying, "I have no idea what a good UI interaction for these things looks like."

[TomOrr0W]

Instead of committing a change when a cluster key's field is modified, could you only commit the change when the user clicks outside the cluster's fields (i.e. clicking on the value, clicking on blank space in the cluster, or clicking outside the set/map constant).  For array keys, it would probably be similar except that the user can also click on the scrollbar and/or index display without committing the change.  On commit, the behavior could be as tannells described.

This could still be frustrating if the user is copying values from somewhere else, but, for normal editing, it should be fine.

I don't know if there is any other verification/committing process that is done when users click off of constants, but (if so) that should be done at the same time it normally would (i.e. if the first cluster key element would have some sort of verification, it would happen when clicking on the second element, while verification of the key as a whole would happen when clicking outside the cluster elements).

[PNR]

In my opinion sets and maps don't necessarily have to be edited on the block diagram, although it is certainly desirable.

> We kept coming back to some sort of "pop open a dialog where you change the contents and then commit the changes", but it felt really cumbersome. If you have better ideas, post them, please.

Why do you think it is cumbersome? In my experience constants don't change often, so having a dialog every now and then is no big deal. In fact, the lack of such a dialog requires me writing a VI to "generate" the constant by hand, which *is* cumbersome.

> 1. What constitutes "committing" a change to the constant such that sorting is reapplied? Or does a new/changed element immediately sort into position?

I think maps and sets should have a separate editor. New and changed elements should be sorted when committing changes (i.e. by pressing "OK"). There could also be an option to sort elements on demand. Of course, it should also be possible to discard changes.

> 2. In a map, if you change or add a key that matches an already existing key, what happens to the conflicting value?

The behavior should be similar to enumerations. When you have two items with the same name, you cannot commit changes and a warning is displayed:

I would also like to note that, although enums can be edited on the block diagram (Ctrl+Click, Shift+Enter), you can have duplicate values when editing enums in-place, but not inside the editor. I'm certain most people are not even aware of the in-place method, let alone the fact that you can create invalid enums.

> 3. In a set, do you need feedback when two elements consolidate?

A summary would be fine (i.e. "Element x already exists in the set" or "n elements were consolidated"). That should be enough, because the reason for using a set in the first place is the ability to consolidate elements. Otherwise we would be using arrays.

> By the way... if anyone wants to build an editor for the constants, you could create a custom right-click menu option and write the code for the editor to show us what you'd like to have. I'm literally throwing my hands up and saying, "I have no idea what a good UI interaction for these things looks like."

I'm not (yet) bothered *that* much 😉