How to synchronize tree active item set pragmatically with keyboard/mouse selection?

[JohnG3k]

So here is the problem I am having:

1. I use the keyboard arrow keys to navigate up and down in a tree control

2. I then set the active item and value of the tree programatically.

3. I then press on the up or down key on the keyboard, and the active item and value is adjusted up or down relative to where it was when I last used the keyboard to set it's location, not relative to where I just set it programatically.

It seems that when the active item of a tree control is set with keyboard and/or mouse, this index is saved as an independent property to the active item property available using property nodes. How do I synchronize the two?

I have managed to reproduce this problem using the example here:

https://forums.ni.com/t5/Example-Program-Drafts/Moving-an-Active-Item-in-a-Tree-Control-Up-and-Down-...

To reproduce the problem, do the following:

1. Open the above vi and add property node after the case structure to set the tree control KeyFocus = True.

2. Run the vi and click on the 2nd row of the tree control. The 2nd row should now be highlighted.

3. Set the EditPosition.Row control value to 6. You should see the 6th row highlighted.

4. Press the down arrow.  You should now see the 3rd row highlighted... but should be the 7th.

Thanks,

John

[JohnG3k]

I have filed a Service Request with NI on this issue, and it is being escalated. In the meantime, I am posting a test vi I created to demonstrate this problem specifically, to see if anyone has already found a solution, or at least a work-around.

Also, a few points of clarification:

1) It is not actually a problem with the ActiveItem after all. It is a problem with the Value. In my application I update both at the same time, so I misdiagnosed the cause and effect. The active item isn't supposed to change with keyboard/mouse input (as far as I know), only the value should. But when the arrow keys are used to update the tree value, the new value is determined by the last value generated by the keyboard, not the current value of the control.

2) Using the Home/End/PageUp/PageDown keys after programmatically setting the Value works as expected. It is only the Up and Down keys that reference the Value before it was programmatically set (which I suppose makes sense, since those other keys don’t need to reference the previous value to determine the new one).

Thanks,

John

[JohnG3k]

This has been acknowledged as "unexpected behavior" by NI R&D. CAR 653654. 

If anyone has a work around, I'd love to see it.

Thanks,

John