Editor's Note: Normally, waiting five months to publish an article about a software roadmap update would be a fool's errand. The good news for me–and bad news for you, dear Access developer–is that nothing has really changed with regard to the Access Roadmap over these last five months. So, while this may be old news now...it somehow also still qualifies as "current events." Enjoy!
Michael Aldridge (Principal Program Manager for Microsoft Access) and Joe Jimenez (Microsoft Access Software Engineer) presented an Access Roadmap update on April 28, 2022, on Day 1 of Access DevCon Vienna. What follows is a more in-depth recap of that talk than what I posted shortly after the event.
Michael Aldridge presented the current and updated public roadmap.
Michael acknowledged that missing estimated release dates has been a real problem for some time now. As a result, the Access team is moving to a "High Confidence Delivery" approach. This means that feature updates will only appear on the public roadmap when the engineering team has 90% confidence that a feature will ship on a given month.
I wrote about this change in detail in an earlier article, so I won't rehash that here.
Browser Control Update and Demo
Instead of basing the new web browser control on WebView2 directly, the Access team changed their approach to use the Office Solution Framework (OSF), which is a wrapper around the WebView2 base control.
This provides one unified WebView2 component for all of Office (not just Access). Thus, the Access team does not have to manage the lifecycle of updates on the WebView2 control. That responsibility will fall to the (presumably better-resourced) Office development team.
On the downside, the Access team now has to lobby the Office team to expose certain WebView2 APIs that the OSF abstracts away. On the screenshot below, those are the long lines that poke through the OSF layer and into the Access layer.
On balance, I think the decision to go the OSF route is a good thing.
Microsoft barely provides the Access team with enough resources to maintain Access in its current form. Having to provide constant updates for a rapidly evolving dependency like WebView2 was always going to be a bridge too far.
Backward Compatibility Breaking Changes
Some properties of the old web browser control will no longer be supported, including:
- Transform property (almost no reported real-world usage)
- OnProgressChange event (not supported in WebView2)
- Mouse events (not supported in WebView2)
- Keyboard events (only work for accelerators)
Also, there will be no VBA API support with WebView2 like the current IE browser control has. Instead, Joe recommended using the Selenium project, which can be used to automate all browsers (but not the web browser control itself). This would be useful for things like automated web scraping.
The new browser control will be editable in Office 365 and future perpetual builds (e.g., Access 2023/2024, etc.) for development purposes. End users will be able to run the new browser control in read-only mode for older supported Click-To-Run (C2R) perpetual builds: Access 2016, 2019, and 2021.
Bear in mind, this progress report is as of the end of April 2022. Hopefully, several items on the Backlog have since been implemented. With that said, this was the state of the list at the end of May 2022:
- Can display a website in a form/report
- Handles most standard Access Properties/Events
These are items on the to-do list that the team intends to ship with the new browser control:
- Local html files
- Print support
- Continuous forms
- Record navigator changes url when browser bound to field
- VBA API
The following events will be supported with the new browser control:
- On Enter
- On Exit
- On Got Focus
- On Lost Focus
- On Before Navigate
- On Document Complete
- On Navigate Error
- On Progress Change
- On Key Down
- On Key Up
- On Key Press
- On Click
- On Dbl Click
- On Mouse Down
- On Mouse Up
- On Mouse Move
Monster Bug Background
In the Q&A portion at the end of the presentation, Joe pulled back the curtain a bit on the infamous "Monster Bug" (i.e., the "data is in an inconsistent state" error).
A long time ago, the Microsoft Access team relied on some undocumented Windows behavior to manage multi-user access to files on the network. This broke Access when the undocumented behavior changed one day (as undocumented behavior is wont to do).
Since the source of the bug was a change to Windows and not Access, the typical approach of rolling back to a previous working build was not even an option.
Also, the Access team is having trouble reliably reproducing the bug itself. And, as every software developer knows, reproducing a bug is often more than half the battle.