We have developped quite an heavy ms-access app, with some 300 forms (yes!). As the code instantiates these forms (and do not just ‘open’ them), we can have multiple instances of the same form displayed on the screen.
To bypass the limitations of VBA, and its poor implementation of some object oriented concepts such as inheritance, interface, encapsulation, etc, the code is managing:
- a windows collection made out of the all the active instances of our forms.
- a ‘ghost windows’ object, which hold all the extra properties and methods needed for our code.
So, as an example, when I want to reach the standard property of one of my instances, I can write:
MyWindows.accessWindow(hWnd).name
Where hWnd is the handle given by Windows, and name the standard form().name property
But if I want to reach a specific property of one of my instances, I can write:
MyWindows.ghostWindow(hWnd).originalRecordset
Where ‘originalRecordset’ holds the original ADODB.recordset which was loaded when the form was first instanciated (meaning before any changes made by the user … can be interesting!)
It’s working great, but coding it can be a real PITA, specially when one knows how starighforward it could be to do something similar in C#, as long as one could encapsulate the MS-Access form object into a more generic C# object. So this is the question: could one embed the MS-Access form into a home-made C# dll? Is it feasable?
I do not expect a complete answer, but I am expecting some help to get on the right track. Any idea pals?
This should be doable through Office Automation.
In short, you use c# to launch your access application, and then get the proper object model for your forms, the same way you have them available in vba.
It’s probably the first step if you want to use more of c# (good), and less of vba (meh) to gradually improve/refactor your access app.
More details in the MS KB article “How to automate Microsoft Access by using Visual C#”