2023-10-11, 06:28:55
(2023-10-10, 20:36:13)wila Wrote: Hi,
OK.. sometimes things that seems so simple, are not that simple..
First off, the WebView2 control itself has parts that run "out of process", so it runs as its own process making things a bit strange when you connect to it as an in process control. Which is basically what we are doing here.
On top of that there's a custom keyboard/focus handling implemented by Microsoft that isn't exactly flexible nor standard.
Case in point: https://github.com/MicrosoftEdge/WebView...ouse+focus
and you'll see a bunch of open issues.
Some pretty old ones too. So that makes it all the more exciting.
While debugging this issue, I noticed that the WebView2 control itself does not detect that it should loose focus as it never triggers the LostFocus event.
So what to do then?
I tried to run this.setfocus from within VFP from within the text box click event, hoping it would move away the focus from the antview control, but that did not help.
However.. the technique that is used internally by the NextFocusWindowHandle and tabbing out of the control by running a windows API setfocus from within the AntView control does work.
So we exposed two new methods: FocusNextObject and FocusPreviousObject.
These methods will take the values set by NextFocusWindowHandle/PreviousFocusWindowHandle and notify the AntView control to change the focus to the object set in those properties.
By calling those from within the "Click" event in your text box, the focus then behaves normally.
A few screenshots of the required code:
and the new method:
So it's a workaround and not a fix, but it's not a lot of code to write and get the achieved result.
I will email you the link for a private build that has the new methods to try out.
-
Wil
Hi, thank you very much for your quick reply and deep analysis of the issue. I confirm that the new version with new method is working. The text boxes get focus normally.
BR Zdenek