Setting the value of a listbox should display the selected value

[tst]

Do you know what happens if you run this code?

Well, the not very useful result looks like this:

What it should look like is this:

So yeah, we can use the Top Row property and make sure we don't go under zero and that we're going in the correct direction, etc., but I don't really see any use for the current behavior, so I say that the listbox should display the selected value automatically, at least as an option.

Incidentallly, this also applies to multicolumn listboxes and trees.

[Mads]

And if you navigate with up or down the list with the arrow keys it will ignore your programmatic changes as well, and use the last known non-programmatic value as its reference from which to move...

[AristosQueue (NI)]

Workaround:

I can't find anything that helps with Mads' keyboard navigation issue... so I filed that as CAR 282916.

[tst]

AQ, I did mention that workaround in my post, but it's woefully lacking. The specific incident which brought about this post was that I was writing code where pressing a button adds a new item to a listbox. Naturally, the new item goes at the end and I wanted to display it, but to do it properly requires more complex code, because in your simple workaround it would look really bad.

Just as a small example - the basic operation in that case would be   Top Row = NewLength - NumRows   but this might produce a negative value, so you have to add a Max and Min with 0.

Similarly, if you're going from a lower value to a higher one you would generally want the new value to be either at the bottom or the center of the list, probably the bottom, but if you're going from a higher to a lower, you would want it to be on the top. You then need to account not just for negative values, but for values which are larget than   Length - NumRows,   and if the new value is already shown, then you wouldn't want to touch the TopRow at all, etc.

In short, all this code should be inside the control.

One important point I only glossed over in the original post is that maybe this should be optional. The main reason for that was that I was thinking someone might want a different behavior, especially if they already have existing code which handles this, so one way to handle that (assuming this would be optional) would be for controls from old VIs to have the property default to F and to let new controls have the property default to T.

[JackDunaway]

tst, what would you think about simply adding an "Ensure Visible" method (like the one for trees) that accepts an index value? This would enable your desired behavior without affecting the properties interface or existing behavior. Perhaps, there could also be a "Select and Ensure Visible" so the operation could be performed atomically?

[R_Beauchaine]

What it should look like is this:

 the listbox should display the selected value automatically, at least as an option.

Incidentallly, this also applies to multicolumn listboxes and trees.

---

What behavior would you propose for multiple selections or no selection?

[altenbach]

I am not sure I really want an uncoditional automatic scroll. What shoud it do of two items are selected and their position difference is larger than the control height? (Some guy will also be using this control as local variable in a tight inner loop and the display is going to dance around like mad, wasting all CPU scrolling back and forth. 🐵

How about having some blue marker line(s) in the scrollbar background that shows the actual vertical location (similar to e.g. after a word search (ctrl+F) in google chrome or elsewhere)? Manually moving the scroll bar handle over the line(s) will bring the selction in view.

[Manzolli]

Like the idea as an option.

[AristosQueue (NI)]

> (Some guy will also be using this control as local variable in a tight inner loop and the display is going to dance around like mad, wasting all CPU scrolling back and forth. 🐵

As long as the panel is closed or the control is hidden, this wouldn't be a problem. If he is showing the control, he already has this issue with the blue highlight dancing around, and taking time to update the display.

[tst]

Jack, personally I could probably manage with a special method, but I would say that for ease of use, a boolean property coupled with any method of setting the value would make it much more practical, as I believe this will be the use case most users want.

For multiple lines, we'd probably be safe with showing just one of them (probably the one nearest to the top). If one of them is already visible, the control can probably not move at all. Personally, I think this use case is a lot less critical, as I don't really set values like that programmatically (unless I have a list with multiple selections where I'm loading the previous selections from disk, in which case it doesn't really matter what the scroll position is and I would probably disable the auto-scrolling for such a listbox).

Similarly, for no lines, we could probably simply not touch the scroll position.

And of course, Altenbach's markers-on-the-scrollbar idea can also be implemented regardless of this idea, although personally I'm not a huge fan of controls which deviate from the normal behavior.

[deyyoung]

Great idea!  A boolean property to enable/disable it would be fine as well (ex: "Center On Last Selected Value").