Antwise community forums
Alternatives of old IE methods - Printable Version

+- Antwise community forums (https://forums.antwise.com)
+-- Forum: Antview (https://forums.antwise.com/forumdisplay.php?fid=11)
+--- Forum: Antview for Windows (https://forums.antwise.com/forumdisplay.php?fid=12)
+--- Thread: Alternatives of old IE methods (/showthread.php?tid=133)

Alternatives of old IE methods - hsacrm - 2022-08-30

Hello, we're currently implementing Antview in MS Access and we're having a few issues. We hope you could help us.
  • When adding the control to a form and docking it horizontally to both sides, the width of all webpages are larger than the form itself. How can we prevent this from happening?
  • In Internet Explorer there was an option to execute commands by calling browser.ExecWB. Is there any equivalent in Antview?
  • is there an easier way to get the html source of the current page? We use it it many places and right now we'll have to execute an event and catch it in another (RequestCurrentHtml). In IE we could simply call browser.document.body
  • Can we request the state of the browser? In IE this would be browser.readystate.

Thanks for the assistance.

RE: Alternatives of old IE methods - wila - 2022-08-30

Hi,

Thank you for your questions.
I will try to answer them below.

When adding the control to a form and docking it horizontally to both sides, the width of all webpages are larger than the form itself. How can we prevent this from happening?

Can you try the following?
   

For me when I last tested it in MS Access that made the AntView control have the expected width.

In Internet Explorer there was an option to execute commands by calling browser.ExecWB. Is there any equivalent in Antview?

No, sorry, there is no ExecWB for WebView2.
In the WebView2 world everything is handled by Javascript. This opens up a lot more possibilities, but it is quite a mind shift from the old mshtml and ExecWB way of doing things.

is there an easier way to get the html source of the current page? We use it it many places and right now we'll have to execute an event and catch it in another (RequestCurrentHtml). In IE we could simply call browser.document.body

The default way of working with the WebView2/AntView control is asynchronous.
This is the recommended way and is most flexible.
However, as this is sometimes problematic with legacy programming languages we have started on implementing synchronous wrapper functions to make it easier to communicate with the control.
The RequestCurrentHtml function has a synchronous variant RequestCurrentHtmlSync which directly returns the html of the current page.

Can we request the state of the browser? In IE this would be browser.readystate.

This works completely different in WebView2. You would be looking at the OnNavigationCompleted event (or likely the OnNavigationCompletedHex variant as I doubt that MS Access supports Int64 data types) in order to see if a document is completely loaded.

Hope this helps,
--
Wil

RE: Alternatives of old IE methods - hsacrm - 2022-08-30

Thanks for the reply. We will look into it.

About the width. We've tried your suggestion, however it doesn't resize correctly. It only works after setting it about four times.

You can see on the left that there is still space left: [Image: wrong.png]

While it should look like this: 
[Image: correct.png]

RE: Alternatives of old IE methods - wila - 2022-08-30

Hi,

Trying to make sure I understand your issue correctly.
   

I think you're trying to say the issue is (1). The rendering process of the browser puts extra space on the left side for the test URL https://docs.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core.corewebview2
Where I was thinking you had issues with maximizing the control, you are apparently having issues with the rendering process.

If the issue is (2) then it seems to me that the left positioning isn't 100%.

So assuming you are talking about (1), then it is the rendering process of the browser that behaves different. This by itself is not something I control. The webview2 process is the one who takes care of the rendering.
That by itself doesn't mean it isn't curable.

First things first.
What happens if you open the same URL in Microsoft Edge? Do you see the same there?

You probably already know this, but let's get down to the basics.
Nowadays websites anticipate on how much screen real estate they have, by creating responsive websites. The layout of a website looks different when you resize the view. This way they can customize for when someone visits a website using a phone, a tablet or a desktop computer.
The website asks the browser for how much screen real estate it has to work with and adapts to that.
My guess is that this is what is biting you. That the site thinks your form is bigger than it actually is.

I would have expected to see a horizontal scroll bar at the bottom, but it seems there is none.

Can you give me some additional background info please?

What is the screen resolution are you using here?
Did you change DPI settings? (eg. 100% DPI or something else?)
What version of MS Access and is MS Access using a manifest file?
Windows version?
How big is that form?

As an example.. I just played a bit with MS Edge and the website shows a similar white space on the left when I increase my resolution to 2560x1600 and maximize the browser.

thanks!
--
Wil

RE: Alternatives of old IE methods - hsacrm - 2022-08-31

It's indeed the rendering process however, it seems that it works correctly when not setting the horizontal anchor point of the control to both sides. If i do set it, then it shows the white space. We could use this work around but if it's possible, we would rather use the anchor point because then we won't need to look at the width.

[Image: change-to-Horizontal-Anchor-300x300.png]
(The anchor point of the control, this is just an example of what i mean)

To give you some additional information:
There is no problem when using the Edge browser.
The screen resolution is 1920x1080
The DPI is set to 100%
I'm using Access 365, 16.0.1, 32Bits, on a Windows 10 machine. (Access 2010 has the same problem)
The form height is 6,508cm and width 8,492cm. However, since im achoring it, it'll become full screen.

RE: Alternatives of old IE methods - wila - 2022-08-31

Thanks for the extra info and great to hear that you at least have a work around.

Completely understand that you prefer to use anchoring over manually resizing the control.
I will need to see if we can reproduce the problem down here and then see if we can figure out what is actually happening.
Sadly the AntView control does not see when you use anchoring versus manually resizing. As far as the control is concerned it is the same thing.

As an aside.
On another development environment (DataFlex) anchoring works as expected, so it is a curious to see it behave like this on MS Access.

--
Wil

RE: Alternatives of old IE methods - hsacrm - 2022-09-09

Hi wil,

Do you have any updates regarding the sizing?

On a side note, we are experiencing some issues with the control. Maybe you could give us a push to the right direction.
- Is it possible to save the default printer and page margins via the registry? We already tried some given solutions, like setting it in HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge but that does not work. Maybe the control reads it from somewhere else?
- Besides that, we only see that it's possbile to set the margins when saving it as a pdf file through PrintToPdf. We'd like to set it in the print preview if it's possible.
- Is it possible to call the system print dialog instead of the print dialog of Edge? (ctrl + shift + p)
- The event/method OnKeyPress of the browser does not seem to work at all. It does not get called no matter how many times we press a key.

Thanks again!

RE: Alternatives of old IE methods - wila - 2022-09-10

Hi,

Sorry last week was dramatic, did not get much work done for anything.
It wasn't just that, although that was certainly enough, but not exactly a productive week.

Looking to see if I can reproduce the sizing issue is still on my to-do list.

Re. your questions.

Strange as it might be, Microsoft hasn't yet added an official API for printing yet.
As it is, they are rounding up the specs for implementing that.

https://github.com/MicrosoftEdge/WebView2Feedback/pull/2604

Right now your best bet on invoking a printer dialog is to do so via javascript.
eg.

ExecuteScript "window.print();"

Not ideal and I really hope that Microsoft gets their printing API in the WebView2 product soon as I can then also work on exposing that.

re. the keyboard OnKeyPress event.
That event is added by the ActiveX framework I'm using and probably shouldn't have been exposed.

The problem is that the WebView2 control is Out-Of-Process and has an In-Process front end.
So while you're typing in the -out of process- control, the -in process- front end doesn't get any of those events.

MS is changing that so that you can actually track these kind of things with the normal WindowHandle and from what I read here: https://github.com/MicrosoftEdge/WebView2Feedback/issues/468
They are getting close to completion on that one.
Also see: https://github.com/MicrosoftEdge/WebView2Feedback/issues/112

Can you tell me what you need to have those keyboard events for?
Perhaps there's another way to get what you need.

--
Wil

RE: Alternatives of old IE methods - hsacrm - 2022-09-12

I'm sorry for your loss Will. That's certainly not something you want to go through. Wish you the best.


About the questions.

We'll continue using window.print() for now, hoping it'll be added soon.
As for the keyboard event. We're currently using it because we're loading a text editor library in the browser. In our program we have certain key presses that can activate functionalities, such as ctrl +s, which saves the text from the editor to our program. However, if you're writing inside the editor, the key presses won't be caught because it's seen as an action inside the browser. Which is why we're catching the keyboard events.

This should be possible if we could execute javascript and directly get the result. Because we then only need to call the document of the editor and define it as a HTMLDocument
(In our new case Edge is async, and we can't find a solution for the code below)
Small code example IE browser:

Dim WithEvents oDoc As HTMLDocument 'Events
Private Sub SetoDoc()
    Set oDoc = wb.Document.parentWindow.Eval("editor.document.$") ' Here we get document of the edit area of the editor
End Sub
And when a key get pressed, we do:
Private Sub oDoc_onkeydown()
    Select Case oDoc.parentWindow.Event.KeyCode
        Case vbKeyS
            If oDoc.parentWindow.Event.ctrlKey Then
                ' Call functions
            End If
End Sub

Hopefully this makes our goal a bit clearer.

RE: Alternatives of old IE methods - wila - 2022-09-12

Hi,




Thanks.




re. catching key events for accelerator keys.




You can actually handle this via javascript as well (I just tested that here)




If you add the following bit of code:



Code:
window.addEventListener("keypress", function(event) {
  if (!(event.which == 115 && event.ctrlKey) && !(event.which == 19)) return true
  alert("Ctrl-S pressed")
  event.preventDefault()
  return false
})
and run that for the currently loaded document.

After the above has run, you'll see that pressing "Ctrl+S" does indeed pop up the alert box.




If you want to instead handle something in your host application then instead of using "alert" you can pass data to your host application via a postmessage event.



An example of how this works can be seen in the webmessage example.



See the VB6 webmessage demo explanation for some details on that and the demo code itself under the Public Documents AntView folder.




On top of that, there is a way right now for handling accelerator keys in the C++ API of the WebView2 control.



From the sounds of it that might also help for your current needs.

Note that what Microsoft offers there is for accelerator keys only, so no general keyboard event as to what you used to have with the old MS browsercontrol.




I will look into this, but need a bit of time for adding support for it while I"m slowly catching up with things.




--


Wil

RE: Alternatives of old IE methods - wila - 2022-09-13

Hi,

Today I played a bit with MS Access. Only have a very old version here, but I suspect that that isn't the main issue.
I could not reproduce what you're seeing, but it did behave a bit wacky.

This is the code I ended up with that seems to behave reasonably.
Code:
Option Compare Database
Private WithEvents Document As AntViewAx.AntViewDocument


Private Sub Document_OnRequestCurrentHtml(ByVal Html As String)
  MsgBox Html
End Sub

Private Sub EdgeWebBrowser_OnCreateWebviewCompleted(ByVal HResult As Long)
  If HResult = 0 Then
    Form_Resize
  End If
End Sub


Private Sub Form_Load()
  Set Document = CreateObject("AntViewAx.AntViewDocument")
 
  EdgeWebBrowser.CreateWebView
  EdgeWebBrowser.Navigate "https://docs.microsoft.com/en-us/dotnet/api/microsoft.web.webview2.core"
  EdgeWebBrowser.AutoSize = False
  EdgeWebBrowser.EventsUseHexadecimal = True
End Sub


Private Sub Form_Resize()
  On Error Resume Next
  If EdgeWebBrowser.WebViewCreated = True Then
    EdgeWebBrowser.Width = Me.InsideWidth - 500
    EdgeWebBrowser.Height = Me.InsideHeight - 700 - GetHtmlButton.Height
  End If
End Sub

Private Sub GetHtmlButton_Click()
  Document.CurrentBrowser = Me.EdgeWebBrowser.Object
  Document.RequestCurrentHtml
End Sub
So only resizing after the control has actually been created.
Sending a resize immediately after a create and using InsideWidth and InsideHeight.
Oh and I also had to turn off AutoSize (whatever that does)

I'm setting EventsUseHexadecimal there as that's a setting I expect you will need in order to be able to use several of the events.

Hope this helps,
--
Wil

RE: Alternatives of old IE methods - hsacrm - 2022-09-14

Hi Wil,

That's approximately the same as we do now as a workaround. That works for us. So we'll continue with it as it is.

About the key events and printing. We'll just wait till Microsoft releases these features/fixes.
There are still things that don't work as we would have wanted, but we understand that it's a completely different browser with a different API. We're slowly getting accustomed to it, and are able to fix our problems.

Thank you for your guidance.

RE: Alternatives of old IE methods - wila - 2022-09-14

(2022-09-14, 13:01:42)hsacrm Wrote: Hi Wil,

That's approximately the same as we do now as a workaround. That works for us. So we'll continue with it as it is.

About the key events and printing. We'll just wait till Microsoft releases these features/fixes.
There are still things that don't work as we would have wanted, but we understand that it's a completely different browser with a different API. We're slowly getting accustomed to it, and are able to fix our problems.

Thank you for your guidance.

It might be a while before Microsoft releases those features... they aren't exactly fast on addressing these open requests.

Would exposing the accelerator key interface help?
That's at least something I can look into on a short notice and is under my control.
--
Wil

RE: Alternatives of old IE methods - Patrickb - 2022-11-03

(2022-08-30, 10:17:06)wila Wrote: Hi,

Thank you for your questions.
I will try to answer them below.

When adding the control to a form and docking it horizontally to both sides, the width of all webpages are larger than the form itself. How can we prevent this from happening?

Can you try the following?


For me when I last tested it in MS Access that made the AntView control have the expected width.

In Internet Explorer there was an option to execute commands by calling browser.ExecWB. Is there any equivalent in Antview?

No, sorry, there is no ExecWB for WebView2.
In the WebView2 world everything is handled by Javascript. This opens up a lot more possibilities, but it is quite a mind shift from the old mshtml and ExecWB way of doing things.

is there an easier way to get the html source of the current page? We use it it many places and right now we'll have to execute an event and catch it in another (RequestCurrentHtml). In IE we could simply call browser.document.body

The default way of working with the WebView2/AntView control is asynchronous.
This is the recommended way and is most flexible.
However, as this is sometimes problematic with legacy programming languages we have started on implementing synchronous wrapper functions to make it easier to communicate with the control.
The RequestCurrentHtml function has a synchronous variant RequestCurrentHtmlSync which directly returns the html of the current page.

Can we request the state of the browser? In IE this would be browser.readystate.

This works completely different in WebView2. You would be looking at the OnNavigationCompleted event (or likely the OnNavigationCompletedHex variant as I doubt that MS Access supports Int64 data types) in order to see if a document is completely loaded.

Hope this helps,
--
Wil

I was trying out requestcurrenthtmlsync  I'm running antview 1.1.200.0 
 I'm getting an error 426 - OLE error code 0x80020006: Unknown name.
My code:
LOCAL lctext
lcText = thisform.obrowser.RequestCurrentHtmlSync
STRTOFILE(lctext, "AntView.txt")

Fairly straight forward , I must be missing something
Thanks Patrick

RE: Alternatives of old IE methods - wila - 2022-11-03

Hi Patrick,

Thanks for your question.
What you're bumping into here is that the functions in file advctrl.prg are not up to date with the latest version of the AntView control. My apologies as that slipped through my attention.
The AntView.IDL.txt file is also not up to date, so it isn't easy to find the correct definitions to use for the prg file.

I have attached the .IDL for AntView version 1.1.200 to this reply.

So the trick is in adding the correct definition for RequestCurrentHtmlSync to your advctrl.prg file.
After that you should be able to use it in Visual FoxPro.

Sorry for the trouble.
--
Wil

RE: Alternatives of old IE methods - Patrickb - 2022-11-15

Hi Wil, Thanks for the file.   Where would the "advctrl.prg"  be?  It's not on my PC
Thanks
Patrick

RE: Alternatives of old IE methods - wila - 2022-11-15

(2022-11-15, 20:12:43)Patrickb Wrote: Hi Wil, Thanks for the file.   Where would the "advctrl.prg"  be?  It's not on my PC
Thanks
Patrick

The AntView installer puts it in the following folder:
C:\Users\Public\Documents\AntView\Examples\Visual FoxPro

Hope this helps,
--
Wil

RE: Alternatives of old IE methods - Patrickb - 2022-11-16

Ha found it,  it's avdctrl.prg        v&d were swapped   Thanks Patrick

RE: Alternatives of old IE methods - wila - 2022-11-16

(2022-11-16, 15:41:16)Patrickb Wrote: Ha found it,  it's avdctrl.prg        v&d were swapped   Thanks Patrick

Oh my goodness. Yes, you are correct, my mistake.
Glad to hear that you found it.

Let me know if you have more questions.
--
Wil