If you have key focus on a control, then open a subVI window or dialog to get some input for example - before returning to the original window...it is a well known problem that you have to programatically set the key focus back on the control. However, there seems to have been a change in 2014 (persistent in 2015) that makes the return of focus on the window of the calling VI behave differently/slower - so that it is now possible that the key focus write is ignored if it is run just after the pop-up window has closed itself.
Let's say that you have a listbox for example and if you double-click on an item there you are given a pop-up window where you can input something...but when that window closes you want the user to be able to continue navigating in the listbox from the original location as if key focus on it was never lost. So you add a key focus property and write a True to it as soon as the pop-up subVI returns...Well, that would have worked in 2013 and earlier, but not in 2014...unless you add a 10 ms wait between the subVI-return and the key focus write(!).
Now the fact that the window where you want key focus to be set has to be frontmost is a documentet fact too, it is described here, but in this case the frontmost state is automatic, so that should not be an issue...
However, 2014 introduces a delay it seems to that return to frontmost state.
(It seems that this is even more complex though, because if you happen to *read* the control's key focus state just before opening the pop-up window...the problem disappears, even though that should not really affect what happens later in the program (an more strange this corrective result only happens if you read the value, of the key focus property not if you just read the error out from it)).
