Hosting .Net Win Form inside Access Form

Question

Hy,

exist a host control that is capable to display my homemade .net win for app. inside a Access Form?

I use Access 2007 ... i know that is possible to use a .net library reference ....is possible to use also a graphic controls (displayed inside a Access form)?

Thanks,

Marco Bosco

Answer 1

I did realise.  I'd been trying to find out if anyone else had already done it because I was trying to figure out handling versioning nicely.

The short version is:

C++ / CLI DLL to provide a stdcall based wrapper to the .NET functionality. (all .NET 4.5)

On the VBA side, Declarations for the wrapper API, plus LoadLibrary calls to get the appropriate x64/x86 wrapper version loaded.

Plus a simple XML serialisation based "dictionary" for arguments on both sides of the API.

That makes everything work with const char * and int parameters to keep things simple.

Interestingly, using "Long" for the callback reference seems to work under VBA7 + x64 and VBA6 + x86 which I wasn't expecting.

In the wrapper you have to go through a bunch of jiggery pokery with Assembly Resolution (because the default resolution folder is the MS Access install folder) to get the main DLL load process to work.

Then I have "Load" (sets up the wrapper and .NET),  "Setup" (to load the specific application interface class and set up call backs) and then "OpenForm", OpenReport" and "Command" methods for the actual calls you want to make.

It's kind of flakey when you are developing if you trigger a recompile in the wrong place because it may break the callback pointers, but seems to be solid when using an MDE or ACCDE.

Answer 2

Hi Roger,

Are you speaking of a .NET assembly with a COM wrapper, per standard practices?

If not, can you describe your technique in more detail (maybe in a blog post and then reference it here)?

P.S. did you realize you're responding to a post from 2013?

Thanks,

Answer 3

User Controls, no, not without COM etc as described above.

But I have figured out how to load a .NET DLL into the MS Access process space, and enable callbacks so that you can essentially send Process messages (e.g. OpenForm, OpenReport, and "Commands") in both directions.

Not large data (like data sets), but enough to be able to do reports, forms, and set up interfaces to run methods

That's going to enable me to carry out a gradual migration of a couple of client systems that have several hundred forms and reports where the development is on going, but the upfront cost of a migration would be too high (6 figures) to tolerate.

Answer 4

Old post I know, but figured I'd add some information in case anyone else came across this. I'm not positive on the graphic capabilities, but this is possible and I am doing it on a complex production application.

You can actually use .NET WinForm user controls directly in Access forms by exposing the .NET controls as COM and registering them using regasm.exe. Also copying your .NET control into the GAC helps to avoid issues with Access being able to find the DLL.

There are draw backs and bugs to this approach though; Mainly .NET user controls cannot be properly resized after they have been placed on an Access form. To get around this and a few other issues I ended up using VB6 to create a true COM wrapper around my COM .NET user controls. Access interacts with the VB6 user control without any problems. The VB6 user control in turn interacts with the COM exposed .NET user control without any problems. You end up with an extra layer of DLL to register and keep track of, but this does work smoothly.

All of that being said, this solution is brittle if you need to update often. Get out of Access as soon as you can, it's horrible and the bane to my existence.

-Wes

Answer 5

No, as far as I know, you cannot display any .NET graphic control inside an Access form.

The reason for this that I've heard is that the content of an Access window - used to display the form - doesn't follow the standard of Windows' windows.  Access is doing this in order to minimize the number of handle required to display those very long forms (pages) with numerous controls and increasing the performance: instead of creating a windows' handle for each of these control, quickly using up the number of available handles from Windows, Access creates the minimum number of handles required to display only the visible portion of the form and will make itself all the necessary adjustments when the user scroll up/down or page up/down the form.

This is why must standard ActiveX controls won't work on an Access form either.  You can create an ActiveX control that can be used on an Access form but it must coded following a very precise format particular to Access. Sadly, at this moment, the same is not possible for .NET controls.

While it is not possible to display a .NET control on an Access form, it is possible to call and display a .NET form from Access and some examples of code of this have been published in the past.  However, this is a very rarely used feature, probably because people capable of programming a form in .NET don't want to bother themselves about Access; especially for a combination of Access and .NET.

Personally, I think that if you can program in .NET, you should do all of your work in .NET.

---

Sylvain Lafontaine, ing.

MVP - Access

Blog/web site: http://coding-paparazzi.sylvainlafontaine.com

Independent consultant and remote programming for Access and SQL-Server (French)