Jump to content
John Lokanis

MCLB Automated Selection

Recommended Posts

This is driving me nuts!

 

I have a VI with a MCLB display.  When I open this VI, I select a particular row (for example, row 3) and set the key focus to the MCLB control so the user can use the arrow keys to navigate without first clicking on the control.  This works fine the first time I open the VI in my application.  If the user presses the down arrow, the selection moves to row 4 as expected.

 

If the user navigates to a different row (for example, row 8) and then in the main program takes an action that causes my MCLB VI to be activated again (this time selecting row 5), I bring the MCLB VI to the front most and again set the key focus to the MCLB control.  Row 5 is highlighted as expected.  But if the user presses the down arrow again, the selection changes to row 9, not 6 as would be expected.  Even though the control value is set to row 5 and row 5 is highlighted, somehow the control remembers that the last row navigated to manually was row 8 and it thinks it is still on row 8!

I have tried setting the active cell to the selected row to see if that fixes it but with no luck.  I have also tried changing the order of when I set the MCLB value and the key focus but that seems to have no effect.

Even if I close the VI containing the MCLB and then reopen it, it still remembers the row navigated to and not the newly set one.

 

The thing that is bugging me even more is I vaguely remember having this problem years ago and solving it (I think) but I cannot remember how.

Has anyone solved this or have any ideas?

 

thanks for any thought or comments you can offer.

 

-John

Share this post


Link to post
Share on other sites

Yup.  Just dug up the code (had to go back to something I wrote in 2004 to find it) and I had ended up solving it the same way.  That is one old bug.  I wonder if it will ever get fixed...

Share this post


Link to post
Share on other sites
There are some private properties you can use in LabVIEW 2012 SP1 and later that allow you to set the focus row of a Listbox or Multicolumn Listbox programmatically. Whenever you programmatically change the value, if you also programmatically change the focus row, it should behave in the manner you're looking for. I had heard the behavior was fixed natively to the controls in LabVIEW 2013, but it appears to still be an issue that we have to workaround programmatically.

 

This VI (saved in LabVIEW 2012) contains the private properties you would need. Again, these properties were added in 2012 SP1, so they're not available in an earlier version.

 

Oh, and it was a top woman, not a top man, who added these private properties for us. ;)

 

attachicon.gifFocus Row Properties.vi

 

This behavior has irked me for some time. I also observe it in the Tree controls, do they have a similar private property?

Share this post


Link to post
Share on other sites

Darren, thank you. I haven't tested it yet, but you likely just fixed the longest outstanding defect on one of our products. Like button x Inf.

  • Like 1

Share this post


Link to post
Share on other sites

Thanks! This definitely fixed my problem.  Please let me know who to buy a :beer_mug: for at NI Week.

 

One note: If you try to write -1 to the Focus Row, you get an error.  Writing -1 to the value deselects all rows so sometimes I use this to purposely not have a row highlighted.  I had to add some code to detect this and not set the Focus Row property in those cases.

 

Nice to see this will be in 2013.  Are you saying that this will be publicly available or that the focus row will automatically be set to the value?

 

While we are on the subject of fixing the MCLB, here is something I would like to see:

 

Set the number of visible columns and the minimum width of each column.

When scaling the control within a pane, widen or shrink the columns so the requested number of visible columns is maintained.

Allow us to set the control to auto scale all columns or a specific subset (so some columns maintain their width while other scale).

 

I can do all this in code, but there is so much lag in handling the re-size events that it inevitably is visible to the user as the columns adjust.  This gets especially problematic when there are multiple MCLBs in multiple panes on a panel.

 

Oh, and do the same for Trees as well!   :P

 

thanks again for the help!

 

-John

Share this post


Link to post
Share on other sites
Nice to see this will be in 2013.  Are you saying that this will be publicly available or that the focus row will automatically be set to the value?

 

From what I could tell, we were *supposed* to see the focus row be correctly set while editing in 2013, but from my preliminary tests, it appears to still be a problem in 2013, and will thus still require the programmatic workaround.

Share this post


Link to post
Share on other sites
From what I could tell, we were *supposed* to see the focus row be correctly set while editing in 2013, but from my preliminary tests, it appears to still be a problem in 2013, and will thus still require the programmatic workaround.

I'm ok with that but will the Focus Row property be public?

Share this post


Link to post
Share on other sites
I'm ok with that but will the Focus Row property be public?

 

The FocusRow and FocusItem properties are still private in LabVIEW 2013. I will add them to our internal list of properties to consider moving to public/scripting in LabVIEW 2014.

Share this post


Link to post
Share on other sites
I didn't think they did, but I was pleasantly surprised when I looked this morning. Here is the same property for the Tree (saved in 2012), also only available in 2012 SP1 and later.

 

attachicon.giftree_FocusItem.vi

 

Tree:FocusItem doesn't seem to work for me in 2012 SP1 (12.0.1f3) - I get an Invalid Property error: The property is not valid for this class.

 

Listbox appears fine.

Share this post


Link to post
Share on other sites
Tree:FocusItem doesn't seem to work for me in 2012 SP1 (12.0.1f3) - I get an Invalid Property error: The property is not valid for this class.

 

Argh, you're right. When I checked this morning I was awash in several open LabVIEWs and checked the wrong one. The "Focus Item" property of the TreeControl class is only available in LabVIEW 2013 and later. I have updated my post above to reflect this. Sorry about that.

Share this post


Link to post
Share on other sites
This is driving my nuts! 
Certainly only top men have this problem. Top. Men. (Those who do not get the original reference should at least get the Family Guy homage)

Share this post


Link to post
Share on other sites
Certainly only top men have this problem. Top. Men. (Those who do not get the original reference should at least get the Family Guy homage)

Good catch.  Never type while mad.  I should have done a better job proofreading..   :o  :unsure:

 

(we really need a :facepalm: emoticon on LAVA)

Share this post


Link to post
Share on other sites

This just saved me again with a single column listbox.  Thanks again Darren!

(Please lobby to make this public in the next version of LV)

Share this post


Link to post
Share on other sites
(Please lobby to make this public in the next version of LV)

 

I have added a link to this post to the CAR, and indicated that we should prioritize this over some of the other CARs I've filed about moving private stuff to public/scripting.

  • Like 1

Share this post


Link to post
Share on other sites

Looks like this is still private in LV2014.

 

I did what I could to lobby for these properties to become public, but they were not prioritized highly enough to make it into LabVIEW 2014. 

Share this post


Link to post
Share on other sites

This is an oldie-but-goodie bug:

 

http://forums.ni.com/t5/LabVIEW/Multicolumn-Listbox-Keyboard-Navigation-Bug/m-p/1286778/highlight/true#M533821

 

Similar behavior for the normal listbox as well.

 

I have "solved" it by taking full control of the keyboard navigation using events.  And yes it is a pain.

 

The first report of it was actually 1 year earlier - back in 2009...

 

I do not see why we should need to set a Focus property to get this right...So instead of fighting to get that property made public (not that that's not nice as well), I would prefer it if no such property setting was needed (if that is made available it could instead be used to override what is then the default behaviour - in the rarer event that you would not want to focus on the current value).

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.