John Lokanis Posted December 19, 2007 Report Share Posted December 19, 2007 Create a system multi-column listbox. Fill in several rows with some data. Set the properties Active Cell and Edit Position to a row in the middle of the ones you populated. Set the value to that same row. Set the key focus to true. Create a simple while loop to keep the VI running after all these setting are applied. Run the VI. The row you set should be selected. Use the up/down arrow keys to move to another row more than 2 rows away. Stop the VI Run the VI again. Use the arrow keys to move the selection again. Instead of moving relative to the programmatically selected row that is highlighted, it will jump to the row that was (up/down) from the row you moved to right before you last stopped the VI. Why does it do this? Why does it remember the last selection you navigated to? How can I override this so the selection I set programmatically is the one it will move relative to when the use uses the arrow keys? Is this a bug? -John Download File:post-2411-1198024019.vi Quote Link to comment
John Lokanis Posted December 22, 2007 Author Report Share Posted December 22, 2007 Hello? Is this just obvious to everyone else or is there just no one who cares? Quote Link to comment
Ton Plomp Posted December 23, 2007 Report Share Posted December 23, 2007 QUOTE(jlokanis @ Dec 21 2007, 10:50 PM) Hello? Is this just obvious to everyone else or is there just no one who cares? No, it's not obvious, and yes I care. I can't find an explanation. I only noticed that the 'Edit position' isn't updated by the property. Ton Quote Link to comment
Albert Geven Posted September 4, 2011 Report Share Posted September 4, 2011 I just tested in LV2011-0f1 and it behaved correctly. probably fixed in 2011, the 0f1 release had something to do with the runtime installer and daqmx-base. Quote Link to comment
mje Posted September 7, 2011 Report Share Posted September 7, 2011 I haven't tried reproducing the behavior you describe, but it sounds a lot like something I posted earlier relating to the tree controls. If it is fixed in LV2011, that's good news. In the past, behavior such as this has made me loathe using LabVIEW list/tree/table controls in any system style UI. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.