LAVA 1.0 Content Posted October 17, 2008 Report Share Posted October 17, 2008 OK, I have a hard one, could be either 'expected result' or 'bug'. Run the accompanying VI, follow instructions (load the accompanied RTM as well). The following thing happened today: I was editing a string Hit a menu shortcut This triggered a popup with info from the string. However the info from the string was old. Selecting a menu item with a keyboard-shortcut doesn't remove the focus from the string object resulting in a 'value change event' or a terminal update. So what happens. I instruct my user to always use the keyboad (mouses suck), so they edit the string, hit the menu shortcut et voila I have old data. I know only one workaround: 'Update value while typing', but that one is very hard to filter to see what really happened. Anyone has an idea? Ton Quote Link to comment
Aristos Queue Posted October 17, 2008 Report Share Posted October 17, 2008 Keyboard shortcuts deliberately do not take away focus... imagine if ctrl+c [cut] or ctrl+v [paste] took away focus from the string. :-) So... expected behavior. No, I don't have any recommendations to help you. Quote Link to comment
mbrowne Posted October 18, 2008 Report Share Posted October 18, 2008 QUOTE (Ton @ Oct 16 2008, 07:53 PM) I know only one workaround: 'Update value while typing', but that one is very hard to filter to see what really happened.Anyone has an idea? Ton An other workaround is to manually set the focus of the string to false before you read the terminal... (and set the string focus back afterwards if you want) see picture... This will cause the correct updated value to be read and the value change event to be fired AFTER the menu event. Quote Link to comment
LAVA 1.0 Content Posted October 19, 2008 Author Report Share Posted October 19, 2008 QUOTE (Aristos Queue @ Oct 16 2008, 10:55 PM) Keyboard shortcuts deliberately do not take away focus... imagine if ctrl+c [cut] or ctrl+v [paste] took away focus from the string. :-)So... expected behavior. No, I don't have any recommendations to help you. I can see the point, but as a keyboard junky (come on Darren) this is strange behaviour. It's not about the focus but about the value in the string, it is not available for programming. QUOTE (mbrowne @ Oct 17 2008, 03:20 PM) An other workaround is to manually set the focus of the string to false before you read the terminal... (and set the string focus back afterwards if you want) see picture... This will cause the correct updated value to be read and the value change event to be fired AFTER the menu event. Thanks, I assume that setting the 'keyfocus'=True for any other control will take focus away and will trigger the event. Ton Quote Link to comment
mbrowne Posted October 21, 2008 Report Share Posted October 21, 2008 QUOTE (Ton @ Oct 18 2008, 08:17 PM) Thanks, I assume that setting the 'keyfocus'=True for any other control will take focus away and will trigger the event. Setting the 'keyfocus'=True for any other control will take focus away from the string and cause the value change event to trigger if you were editing the string and had changed it's value. Quote Link to comment
Aristos Queue Posted October 21, 2008 Report Share Posted October 21, 2008 QUOTE (mbrowne @ Oct 20 2008, 04:29 AM) Setting the 'keyfocus'=True for any other control will take focus away from the string and cause the value change event to trigger if you were editing the string and had changed it's value. The thing to watch out for with this approach is that if you are inside the event case for the menu item when you do "keyfocus=true", then the value change event will be sitting in the event queue, but it won't fire until after you leave the event handler for the menu item. You will (I think) be able to get the value from the string control by reading a local variable or the FP Terminal after doing the keyfocus=true, but don't rely upon your event handler doing anything in a value change event.QUOTE (Ton @ Oct 18 2008, 02:17 PM) I can see the point, but as a keyboard junky (come on Darren) this is strange behaviour. It's not about the focus but about the value in the string, it is not available for programming. If I type some text in a string, then use ctrl+c to copy that text, then hit ESC, the text of the string goes back to what it was before I started editing. At no point was the focus taken away from the string, so no Value Change was ever committed. The value in the string has not changed. However, your comments here have given me an idea -- we could have a property on any text entry control -- numerics, strings, paths, etc -- for "Current Editing Value", which would give you the value as it is being typed right now. It would differ from the Value property in that the Value is the committed change. I don't generally work in front panel stuff ... if you like this idea, someone should file it to the product suggestion center on ni.com. 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.