DevCon

Access DevCon Vienna 2022 - Access Roadmap Update

Highlights include a new "High Confidence" approach to the roadmap, a sneak peek at the modern browser control, and background on the Monster Bug.

Mike Wolfe

Sep 8, 2022 • 4 min read

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.

Roadmap Update

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.

Deployment Considerations

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.

Progress Report

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:

Work Completed

Can display a website in a form/report
Handles most standard Access Properties/Events

Backlog

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
JavaScript injection

Supported Events

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.