This kind of "focus" stealing issue still exists in current version of .Net Framework. Problem seems to be related to WindowsFormsHost control which permanently steals focus once it gets it (in example by clicking on the TextBox control within it). Issue probably started appearing in .Net 4.0 and was probably partially fixed in 4.5, but in different scenarios still exists. The only way we found to fix the problem is through Windows API (as WPF window has separate hWnd from WindowsFormsHost control that is rendered as a window within a window). Adding following 2 methods to the Window's class (and invoking it when focus on the WPF window needs to be regained) helps remedy the issue (by returning focus to WPF window and its controls)
/// <summary>
/// Native Win32 API setFocus method.
/// <param name="hWnd"></param>
/// <returns></returns>
[System.Runtime.InteropServices.DllImport("user32.dll")]
static extern IntPtr SetFocus(IntPtr hWnd);
/// <summary>
/// Win32 API call to set focus (workaround for WindowsFormsHost permanently stealing focus).
/// </summary>
public void Win32SetFocus()
{
var wih = new WindowInteropHelper(this); // "this" being class that inherits from WPF Window
IntPtr windowHandle = wih.Handle;
SetFocus(windowHandle);
}
This will also help when navigating from a page with WindowsFormsHost control to another one that doesn't have it, though there is a good chance you'll need to invoke Win32SetFocus with a delay (using DispatcherTimer).
NOTE: This code was tested only with x86 (32bit) build, but the same solution should work with x64 (64bit) build. If you need same DLL/EXE code to work on both platforms, improve this code to load proper (32bit or 64bit) unmanaged DLL.