VFP 10.1 x64 - textbox problem

[Z0472]

Dears 
On formular where is the OLe container with activex AntView are an textboxes too. The problem is when I click inside the web content and after click on some textbox, it is not possible to write in the textbox. Only when the formular lost focus and after click back to the textbox it is possible write in. 
How to dismiss this strange behavior? 
Thanks a lot. 
Zdenek

[wila]

Hello Zdenek,

Thank you for your question.
I just confirmed this behavior in Visual FoxPro 9.x
First off, please note that I am not a VFP developer, while I have been trying to find more low level details on VFP in this particular area, it seems not that easy to find. Probably due to how long the language has been retired by Microsoft.

My suspicion is that this problem is due to how Visual FoxPro deals with handling windows controls. Normally each control on a form has its own window and its own window handle plus a message loop in which the windows messages are being dispatched. As such each control is capable of handling the focus changes itself or delegate it to the parent object.

With VFP - from what I've understood - only the form is a real windows control and all the native VFP controls -such as the textbox control- are handled by the form and are bitmap presentations of what normally would be a native windows control.
AntView is a native Windows control and thus behaves like a native Windows control when added to a form in your application.

Sadly this sometimes appears to result in issues like the one you are seeing when using in Visual FoxPro. While that might be "the way Windows works" it is obviously unwanted in this respect. There's also a lot of controls that do not behave like this in VFP, so it clearly can be fixed. The question is what FoxPro expects the control to do. I very much want to have this addressed or at least be able to provide a proper workaround.

For navigating by keyboard via a tab/Shift-tab you should be able to set
NextFocusWindowHandle
And
PreviousFocusWindowHandle
Both properties take a window handle as parameter of the object that you want to take focus “Next” or “Previous”.
Eg. the following code worked for me to be able to tab out of the control.

Code:

thisform.oAntView.NextFocusWindowHandle = mainHwnd()
thisform.oAntView.PreviousFocusWindowHandle = mainHwnd()

Using that, you will notice that the focus will be given to the object that had the focus before AntView took the focus from the VFP form.

Also note that you can use the MoveFocus method in VFP to assign the focus programmatically to the AntView control.

None of the above however does address your issue with the mouse!
Let me see if there's something I can find to alleviate this issue.

edited: Edit Reason: With VFP you can use the normal NextFocusWindowHandle instead of the UInt variant, especially when using 64 bit that becomes more important.

--
Wil

[wila]

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

[Z0472]

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