listbox stores position independent from value

[Florian.Ludwig]

Hi community,

when I use the keyboard to control a listbox after setting its value programatically the value change seems to be relative to a position the listbox stores apart from its value.

To see what I mean please:

1: Run the attached vi.

2: Press "Tab" on your keyboard once to highlight th listbox control.

3: Press "arrow down" on your keyboard - the highlighted line will change from 1 to 2 (as expected).

4: Run the vi a second time and repeat steps 2 and 3. The highlighted line will change from 1 to 3 (not expected, by me at least).

Further testing shows that the value change seems to be relative to the last value the listbox was set to manually despite that not being the currrent value.

I have tried using property nodes to get the invisible position to match the value but wasn't successful.

I haven't used the listbox control much so this is probably my fault - but to me this behaviour is unexpected.

Any help is appreciated.

Best regards,

Florian

[James.M]

Yeah.... That's weird. I've been toying with your VI and can't explain it other than there must be a disconnect between value assigning and key-down pointers. If you output OldVal as well, it jumps from 1 to 3, so the value definitely knows it's jumping. I even tried setting up to manually increment and decrement the value based on KeyDown, but the listbox functionality trumps this too..

[Matthew_Kelton · Accepted solution]

It's a known bug:

http://forums.ni.com/t5/LabVIEW/Listbox-behaves-in-unexpected-manner/m-p/630457#M291808

I have a posted workaround, and there's a link to a lava thread that also has a fix.

Matthew

[Florian.Ludwig]

Thanks for the reply.

Based on your idea I came up with a workaround.

I still feel that there should be a way to do what I want to do with the standard functionality of the control.

Can anyone help us with that?

[James.M]

Ah, Matthew had the solution. My snippet above just needed the (?) and Discard functionality:

[Florian.Ludwig]

Thanks Matthew, you beat me to the filter event solution. 

In the thread you linked there is even a link to a lava thread with downloadable property notes that are not yet public.

They fix this for me even without or workaround.

[Matthew_Kelton]

Looks like NI thinks they fixed this, but they have not as of LV 2015.

[sassyaspy]

Hi Matthew,

The "fix" is somewhat indirect--in 2015, the "focus row" property was added to the public properties of Listbox to provide a better workaround to the issue. Now if you change the value of the listbox, you will need to also change the focus row to be the same value. That will maintain the location in the listbox rather than jumping back to the last clicked location. That's worthy of better public documentation so I'm going to make a KB for it.

[sassyaspy]

KB 721AT9SU will be on the web in a few minutes, with examples of the workaround you discussed as well as how to implement the fix in 2015. You can see it here:

http://digital.ni.com/public.nsf/allkb/61D1AA87092BBC4C86257ED2005B1EC5?OpenDocument

[Matthew_Kelton]

Siana,

But doesn't that sound counter-productive?  Shouldn't the default behavior be to update the row focus when the value changes, and use the Row Focus property on cases where you don't want it to change?  I can't think of an instance where I would want it to behave the way it does now, but I won't say there is no reason.  It just seems to me that the behavior now is the opposite of what would be considered "normal" behavior.

Matthew