I talked with Jonathan Pobst and Geoff Norton to figure out how we should hook into the winforms implementation...Calvin, Andres, and I had been discussing the idea of implementing the UIA providers directly in the winforms assembly. Turns out we really can't be adding anything public to winforms or even adding additional dependencies, since we need to match the Microsoft implementation. Therefore, we'll be trying the following approach:
- Winforms UIA Providers are implemented in a separate assembly (WinformsAutomationProvider).
- When the Winforms assembly initializes, it will use reflection to initialize required UIA assemblies like the provider implementation (and possibly the UIA<->ATK bridge).
- The WinformsAutomationProvider assembly will use reflection to hook into an internal Winforms event that will allow providers to be created as new forms and controls appear. This internal event may need to be added to Winforms.
In the future there will be at least one more provider implementation (Moonlight), and potentially there could be other bridges if we needed to target other accessibility platforms. Anyway, the big question mark in there is who is the one to initialize the bridge. That's probably a piece of conditionally-compiled code sitting in the core, though I haven't really thought much about it.
So I've been working on provider implementations for Form and Button, with some success. I also experimented with a couple of ways to set up the internal Winforms event. By the end of this week, I will have created the infrastructure for the WinformsAutomationProvider assembly, which will include my Form and Button providers. I will have a patch to Winforms that initializes that assembly, so that I can dynamically create providers as forms are created. I may also work on the Core or whatever else needs to be done.
I'm looking forward to a more productive week.