No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
When designing actions, you can enter shortcut keys like ctrl-S. These shortcuts are set per action. | When designing actions, you can enter shortcut keys like ctrl-S. These shortcuts are set per action. | ||
There have been issues with WPF not listening to these shortcuts | There have been issues with WPF not listening to these shortcuts; it seems that the main cause of the problem was that the WPF app lost all keyboard focus. It is still not fully clear to me how this can be - but it is easy to see when it happens. | ||
The suggested way to deal with the issue is to react to null focus and fix it: | The suggested way to deal with the issue is to react to null focus and fix it: | ||
Line 21: | Line 21: | ||
</pre> | </pre> | ||
This calls the RescueNullFocus method and you can define it like this: | This calls the RescueNullFocus method and you can define it like this: | ||
Line 59: | Line 58: | ||
It is also a good idea to call RescueNullFocus at the start of the application. | It is also a good idea to call RescueNullFocus at the start of the application. | ||
A change was also introduced to the WPF window to own the InputBindings instead of the | A change was also introduced to the WPF window to own the InputBindings instead of the WECPOF. This is done with an extra parameter to _wecpof.EasyInit like this: | ||
_wecpof.EasyInit(_ecospace, false, pathToStyles, thestyle, this/*send in window as command target*/, _targetgroup); | _wecpof.EasyInit(_ecospace, false, pathToStyles, thestyle, this/*send in window as command target*/, _targetgroup); | ||
[[Category:WPF]] | [[Category:WPF]] |
Revision as of 06:32, 18 July 2023
When designing actions, you can enter shortcut keys like ctrl-S. These shortcuts are set per action.
There have been issues with WPF not listening to these shortcuts; it seems that the main cause of the problem was that the WPF app lost all keyboard focus. It is still not fully clear to me how this can be - but it is easy to see when it happens.
The suggested way to deal with the issue is to react to null focus and fix it:
this.IsKeyboardFocusWithinChanged += (s, e) => { if (!this.IsActive) return; var foc = Keyboard.FocusedElement; if (foc == null) { Trace.WriteLine("IsKeyboardFocusedChanged NOTHING"); RescueNullFocus(); } else Trace.WriteLine("IsKeyboardFocusedChanged " + foc.GetType().Name); };
This calls the RescueNullFocus method and you can define it like this:
private void RescueNullFocus() { new DisplayQueueThis(() => { if (Keyboard.FocusedElement == null && this.IsActive) // if the keyboard focused is lost - return it to something usefull { IInputElement x = null; if (_wecpof.CurrentWindow() != null) x = (_wecpof.CurrentWindow() as FrameworkElement).PredictFocus(FocusNavigationDirection.Right) as IInputElement; if (x == null) x = (_wecpof).PredictFocus(FocusNavigationDirection.Right) as IInputElement; if (x != null) // Got stuck on Menu { if (!(x is MenuItem)) Keyboard.Focus(x); else { // find a non menuitem var next = x as FrameworkElement; var stop = next; while (next != stop && next != null && !(next is MenuItem)) next = next.PredictFocus(FocusNavigationDirection.Right) as FrameworkElement; if (next != null) Keyboard.Focus(x); } } } }); }
It is also a good idea to call RescueNullFocus at the start of the application.
A change was also introduced to the WPF window to own the InputBindings instead of the WECPOF. This is done with an extra parameter to _wecpof.EasyInit like this:
_wecpof.EasyInit(_ecospace, false, pathToStyles, thestyle, this/*send in window as command target*/, _targetgroup);