Authoring custom controls in COM for Access 2003

Question

Short version of question:

How can I author custom controls for MS Access 2003 without resorting to VB6 ?

Long Version:

I have been spoiled with the pleasure of writing C# WinForms apps for the past 6 years and now I have to modify an Access 2003 application. Yes, it will eventually be rewritten as a Dot Net app, but for now, it must remain an Access 2003 application.

So one of the things I loved about writing WinForms applications is that I could take any WinForms UI object, say a combobox and turn it into a custom control to which I could add features. I could also take multiple controls, composite them onto one design surface as a custom control and then have it appear in my VS.Net toolbox as a custom control. (Very handy when you have a complex set of data gathering controls you need to use over and over again).

So now that I am stuck with Access 2003 for one of my projects, I want to be able to create custom controls for it. Access 2003 3rd party controls use COM. The problem is, the only environment I've ever created custom COM UI controls in is VB 6. Now, I still have VB6, but since VB6 is more than 10 years old now, I feel obligated to search for other options.

I'm pretty sure that there are people still authoring COM UI controls, so what are you guys using if not VB6 ?

Answer 1

I doubt you're going to get much help on this specific to Access, as most Access developers don't need or desire what you're asking for. Indeed, most of the pros that I hobnob with avoid non-native controls of all types in Access, simply because there are so many problems associated with using them in an Access application. Access is actually a very special animal in many ways so creating controls that will work in Access is harder than creating ones that work in a VB app, for instance. I don't know this for a fact, my guess is that one reason for this is that fact that individual controls on an Access form have a window handle only when they have the focus. The reason for this is quite clear: at the time Access was designed, system resources were limited and you didn't want to be allocated window handles for every single control on a form (which could be in the 100s). That's perhaps not an issue these days, but the design in Access remains the same. There are workarounds, but from my observation, they aren't pretty.