Some people have asked me what I’ve been working on and so I thought I’d share a sneak peak.
Basically, I’ve been working on trying to elevate the Access interface a bit and have been working on a few new menus concepts and thus developing content, demos for my blog and YouTube channel.
One more bug to add to the very long list of Modern Web Browser control bugs!!!
I was working on what I was hoping would be a nifty demo database to utilize for fun media capabilities that HTML5 offers and got it all working fine in Edge, on its own. Sadly, when I then tried to bring it over into Access I hit a wall.
After testing I discovered that Access will accept a Control Source like:
="https://msaccess/C:\Users\Daniel\Desktop\blank.html"
="https://msaccess/C:\Users\Daniel\Desktop\" & [FilePath] & ""
where [FilePath] returns ‘blank.html’ (and yes the ending & “” is required to get around another bug!)
So, simply accessing a file is possible. We knew that.
—
Where things then start to fall apart is when we try to pass parameters as part of the URL of any local files. Thus, passing parameters like demonstrated in the following 2 examples fail.
Came across a really weird bug today while trying to identify another bug with the Microsoft Access Modern Web Browser control.
I set a Modern Web Browser control’s Control Source to something like:
="https://" & [URL2]
then tested and came back into Design View to see some messed up Control Source shown on the control itself, yet a blank property value. I even tried the Zoom box, and it too is blank???!
Yep, another bug with the Modern Web Browser control.
Worse, this issue occurs when simply trying to navigate to a URL via VBA using the form’s current event. At the opening of a form, navigation is simply completely unreliable and more often than not renders a blank page! Sometimes it works, but most of the time it does not! When navigating the records, the event works just fine, this bug is limited to the initial opening/loading of the form/report control. So in most instances, the user ends up with a blank Modern Web Browser control when they should be seeing content.
Just a quick FYI regarding the Modern Web Browser control. I’ve been doing some recent work and have been experiencing issues.
As previously reported, I’ve been getting blank displays even though the URL indicates it went to the site, nothing new here!
Now, after closing my database, I kept having a lock file that wouldn’t go away and I couldn’t delete it. Examining the Task Manager I came to see that Access remained running as a hidden process, and I also then saw a whole bunch of Microsoft Edge WebView2 processes running as well. It was only after killing all of these that I was able to finally delete the lock file and continue working.
Just playing around with an idea of making list boxes and combo boxes have the column width autoresize based on the content of those same column and thought I’d share a first run at the concept.
I came across a thread on UtterAccess:
and it brought back some memories of work I did for a client where I had to deal with this issue.
The issue is quite simple, exports, with the exception of PDFs, do not properly export all formatting.
Let me illustrate the problem, or at least one example of them.
Here’s an issue that has been nagging me for years, the Midi Client close buttons not responding!
Here’s a screen recording illustrating the issue.
Just a short commentary about the inconsistent behavior, unreliability of the Microsoft Access Modern Browser control.
I believe for a solution to truly be good a number of design considerations have to always be front and center when doing development. I wrote about some of those aspects in my article:
One of those elements is to use contrasting color between text and the background so things are legible. If users have to strain to read content, graphics, … then we as developers have failed.
Continue reading
