Microsoft Access: Edge Browser Control is finally here :) (1 Viewer)

Correct. I mentioned that point when I was bug testing some months ago with the maps I showed in post #12

In the past I used code similar to this to retrieve the geo-coordinates from the 2 textboxes on the local HTML file

Code:
Dim objIE As Object
Set objIE = CreateObject("InternetExplorer.Application")
'Set objIE = CreateObject("MSEdge.Application") '- doesn't work - can we create an Edge object? If so, what is the correct syntax here

...
sngLat = objIE.Document.GetElementById("latbox").Value
sngLong = objIE.Document.GetElementById("lngbox").Value
...

I am currently trying to find a different way of grabbing those values using .ExecuteJavascript sngLat and/or .RetrieveJavascriptValue sngLat
So far unsuccessfully!

For info, I notified Thomas as soon as the new browser control was made available to the Insiders channel
He hopes to update his Better Access Charts to use the latest version release of charts.js
Try RetrieveJavascriptValue "document.getElementById('latbox').value"
 
Also, the Object property no longer exists, its an error that it was included in the documentation. The Object property directly links to the old browser OLE object with the nice VBA API, but the new browser is not OLE, nor does it have a built in VBA API
 
Try RetrieveJavascriptValue "document.getElementById('latbox').value"
@JoeJimenezMicrosoft , I would like to take a moment to express my sincere appreciation for your involvement and contributions to the edge browser control. The RetrieveJavascriptValue function works great. I do have one question for you regarding the possibility of loading local files/paths, particularly PDFs and images in the edge browser control. I believe that this feature could be tremendously helpful and would love to hear your thoughts on this?
 
@isladogs Thank you for sharing this information and workaround. The suggestion to add "https://msaccess/" before the file path in the browser control source worked for local HTML files, although I can confirm that there was a delay in opening them. I appreciate you taking the time to report this to the Access team and keeping us informed.

I also attempted to load local image and PDF files in the web browser, but was unsuccessful.
re: "open PDF's in the browser control"

my experience is that this has to do with settings in your PDF viewer, not Access.
 
for instance, in Foxit:

1678998294264.png
 
@JoeJimenezMicrosoft , I would like to take a moment to express my sincere appreciation for your involvement and contributions to the edge browser control. The RetrieveJavascriptValue function works great. I do have one question for you regarding the possibility of loading local files/paths, particularly PDFs and images in the edge browser control. I believe that this feature could be tremendously helpful and would love to hear your thoughts on this?
Thanks for the kind words. Yes, we definitely plan to support local pdfs and images, its a known issue that we're working to resolve.
 
thanks for letting us know that, @JoeJimenezMicrosoft. The web browser control has long been a great way to show the contents of local files in Access, especially pdfs and images -- you mentioned the 2 used the most ... although there are more .... Appreciate everything what you and the other Access team members are doing to make Access even better! thanks

kind regards,
crystal
 
Hi Joe
Apologies for the slow response. I've just replied to your separate email
I'd also like to publicly thank you for your hard work working on this over the past few months.
The new browser control is going to be a game changer for many developers and its great to see how its evolved over the past few months as you've been working on it.
I've not yet found any websites that its failed to open ...nor do I expect to do so

Most of the issues I reported in recent months are now fixed and I'm aware of some of the issues you're still working on

Unfortunately the suggestion of RetrieveJavascriptValue "document.getElementById('latbox').value" is only partially successful in my tests.
I've included more detail in my email reply

For the info of others reading this thread, one of the issues with the old browser was that the URL length was limited to 2048 characters (2083 using the ActiveX version). This caused significant issues for anyone using the browser control with annotated Google maps.
The new browser has a far higher limit which is larger than the Google Maps API limit of 16K.
However there is another 2048 character VBA limit when using the .ControlSource that Joe is working hard to resolve.

For now, that can be circumvented using the .Navigate property instead of setting the URL as the control source

Thanks again.
 
@JoeJimenezMicrosoft It's great to hear that supporting local PDFs and images is on the roadmap and that your team is actively working to resolve this issue.

@isladogs, with regards to the URL length limitation with the .ControlSource property, it would be helpful to set a control source by surpassing the limit of 2048 characters. One potential workaround that I suggest could be to populate the ControlSource with a function call or alternatively, populate a textbox with the URL and set the Webbrowser ControlSource to the unbound textbox instead (please see the attached screenshot for reference).
1679004057261.png
 
I have converted and attached Daniel Pineault's TinyMCE WYSIWYG Editor for MS-Access to use the Edge Browser Control and using the latest version of TinyMce Editor. If anyone is interested in checking out the original post for reference, please find it at this link: https://www.devhut.net/ms-access-improved-html/.

1679006465433.png
 

Attachments

Last edited:
Hi @Mohsin Malik
First of all, can I say how much I appreciate your contributions in this thread. Both because of the excellent questions you've asked and the solutions you've suggested. Your feedback is much appreciated.

With regard to the use of long URLs greater than 2048 characters for the browser control source, these will fail with error 2131 in the new Edge browser when the URL is set from a text string using code or directly entered in the control itself (as was the case in the old IE browser).

This is due to a wider limitation built into Access. Joe is aware of this issue and trying to find a solution.

However, there are various workarounds that I've used successfully
a) store the URL in a table and set the browser control source using e.g. a DLookup call
b) setting the ControlSource by referencing a textbox control value in the property sheet (as you suggested)
c) Use the .Navigate property instead of .ControlSource

EDIT:
I suggest you let Daniel know about your conversion of his WYSWIG editor. I haven't tried the original version myself but I know many people like it. Perhaps he will be willing to post your version on his website
 
Hi there!

Today I had the time to read this thread. Afterwards I had enough of knowledge to make Better Access Charts running with the new webbrowser control. Now I have all the files on my computer. I think I will put all the piece together and tidy up the code in the next days and then upload a new Version on GitHub.

kind regards
Thomas
Outstanding, Thomas. The timing is great here, too. With the parallel benefits of BAC and the new WBC for Access, we are on the cusp of a potential boom in Access as a modern tool.
 
Hi Thomas
That was amazingly fast. Looking forward to seeing the new version when its available

Now you can start planning for your follow up session for Access Europe in August - please let me have a title and summary when you can
 
If you are not an office insider but using current channel for Office365 and want to try out the new edge browser control, follow these steps:
  • Right-click on your legacy web browser control (if not add a web browser control in form design view).
  • Choose Change To and then select the new browser control.

Enjoy!

View attachment 106912

Update: Microsoft wants to make sure we're not just swiping right on their new Edge Browser Control. So, they've disabled the 'Change To' option for non-Beta/Current Channel Preview Office365 subscribers. Looks like I got caught in my own trick of rolling out the Edge Browser Control to the users in production, it worked well for two whole weeks but now, I had to roll back the changes to keep using the old-browser control in production. Just another day in the exciting world :)
 

Attachments

  • Right_Click_Change_To_Browser_Control.jpg
    Right_Click_Change_To_Browser_Control.jpg
    171.3 KB · Views: 141
You can probably blame me for that as I reported back about a month ago that the Change to...Browser commands were appearing when they shouldn't be

However, perhaps its an important lesson that you should NEVER deploy beta features to all users. ALWAYS wait until the official release date
 
You can probably blame me for that as I reported back about a month ago that the Change to...Browser commands were appearing when they shouldn't be

However, perhaps its an important lesson that you should NEVER deploy beta features to all users. ALWAYS wait until the official release date
You're absolutely right, it's a valuable lesson to never deploy beta features. I am patiently waiting for the official release date to avoid any potential mishaps. Thanks a bunch for sharing your insight with the community, it's much appreciated!
 
To be honest, I'm surprised it ever worked for those on the Current Channel as the code either isn't yet included or hasn't yet been activated
 
To be honest, I'm surprised it ever worked for those on the Current Channel as the code either isn't yet included or hasn't yet been activated
Yeah sorry about that, the change to options were not properly hidden, but we expect to release to prod late April, or early May, whenever the new Office monthly fork rolls out
 
Hi Joe
Are you able to give a deadline for feedback on the beta version before it needs to be sent to GA?
 

Users who are viewing this thread

Back
Top Bottom