John R. Durant's WebLog

Blog of "The" Office Developer

.NET Control -> ActiveX Control hosted by Office

On Sue Mosher's amazing Outlook site, there has been a discussion about creating ActiveX controls in managed code and running them on an Outlook form. It is a completely unsupported scenario, but that never stops a dyed-in-the-wool developer. I had tried to create ActiveX controls reliably with .NET and run them on a forms^3 form some time ago, but I never fully succeeded. Given the recent thread about the issue, I decided to re-survey the space and see if there are any new silver-bullets. No luck. Anyway, here are some links that speak to the scenario to different degrees. Use at  your own risk:

http://www.codeproject.com/cs/miscctrl/exposingdotnetcontrols.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/actxvnetcontrols.asp
http://www.codeproject.com/csharp/ImportActiveX.asp
http://www.vbdotnetheaven.com/Code/Jun2003/2067.asp
http://www.ondotnet.com/pub/a/dotnet/2003/01/20/winformshosting.html
http://msdn2.microsoft.com/library/4taxa8t2(en-us,vs.80).aspx
http://www.c-sharpcorner.com/Code/2003/March/ActiveXInNet.asp
http://www.gosky.de/dotNet/MigNetKomp.zip

I sometimes hear my fellow MS employees say something like, "Well, no one is really going to try to [fill in unusual dev technique here] anyway, so it's nothing we need to worry about." I don't mind saying that I'm a tireless advocate for the core developer scenarios as well as the ones that I know devs will try that MS will normally not predict. I was a consultant before coming to MS, and sometimes, the unsupported option is the only one that can be adopted, for a variety of reasons. That said, there were a few times I was a little to eager to do take the unusual road, I admit (I am guilty of being too curious), but time has taught me better.

Here's an example of success I cannot take any credit for: Remember when the commonly held belief was that VB6 could not be used to create a Windows service? It was also believed that no developer would attempt to do so. Well, some attempted, and they succeeded. One such intrepid developer was Dev Ashish, now an Access MVP and former co-worker of mine. I still have the source code somewhere on a DVD.

 Rock Thought for the Day: This is not the first time I have blogged about the killer Washington band, From the Fall. Their latest CD, Entropy (which I bought just today) hits right in my sweet spot: heavy, deeply melodic, truly technical guitar work, convincing vocals, and a bassist and drummer who know exactly what to do to make the song move. As I mentioned in my first entry about them in the spring, I heard a definite awareness of Alice in Chains in their music, but that's all. It's refreshing when a band knows how to pay homage to predecessors while producing something entirely new, entirely their own. Besides, a band that can properly use the word 'jingoistic' and still make it cool is destined for something much grander than the local scene. I voted for them to make the stage at an up-coming event. You should too.

This album is just what I need to join my repertoire of metal madness that pushes me to ride my Madone 5.9 ever harder. I need all the help I can get!

Rock On

Published Wednesday, August 10, 2005 10:03 AM by johnrdurant

Comments

 

shaunbed said:

I think the idea of hosting ActiveX controls in Office is only common sense.

.NET was created in many ways to supersede COM though there will without a doubt be COM code for many years to come. There were talks early on about .NET components running under IE. I believe this is an unsupported solution and with ActiveX it may never really materialize but it is something I would like to see.

People often harp about the bad things ActiveX controls demenstrated rather than the good things. As fewer and fewer developers work with COM and more are going on to .NET, I think that Microsoft should make .NET able to fill more of the voids COM once filled.

I am not saying do away with COM. Even with the wonderful performance I am experiencing under .NET 2.0 and VS 2005, I believe that many people will feel like they need to stay with COM and C++. I know that Mark over at Sysinternals had a blog a couple months ago discussing memory bloat and problems he saw with .NET.
August 10, 2005 5:05 PM
 

Eran Kampf said:

Well if hosting ActiveX on an Outlook form is too complex you can also use the old win32 API SetParent call (its a hack but, suprisingly, it works well :) )
August 10, 2005 5:28 PM
 

Jarno Peschier said:

Is there so extra trouble when using such an "Active.NET" beast on an Outlook form that I am unaware off? Because I know I once wrote a COM class in managed code to get me a SmartTag in MS Office (Word, primarily) to get to the text of RFCs easily. Worked fine. Only real pain in the behind was the signing/security stuff, but since it was just to see if it would work, a developer key and some easing up of policies was enough there.
August 11, 2005 3:59 AM
 

Avner Kashtan said:

I really like .NET. I think it's a great development environment. This is why I really hate the fact that I can't use it properly in Office, which is one of the more important and interesting development platforms. It's like you've given us a car that can go at 150MPH, but we have to drive it on a rocky, bumpy road - I want to use Outlook and Outlook forms, and I want to use controls and components that I would have to jump through hoops in VB or walk on coals in C++ to achieve, but I can't. It's very frustrating, since our apps are standardized on .NET/C#, to suddenly find out we're flat-out unsupported on our platform of choice.

I really don't want to go down the unsupported route, but so far I haven't found an alternative that seems feasible. I can list down some of the really off-the-wall ideas we've had, but they all sound just as fragile as this solution, not to mention complicated to implement.

Some alternatives:
1) Write our own controls in VB6/C++. Problematic, since our developers are .NET/C# oriented. Too high a learning curve.
2) Instantiate a .NET control from a managed add-in, catch the InspectorOpen event, and paste our controls in using SetParent and similar subclassing APIs. Extremely fragile.
3) Dump the whole Outlook Forms concept and use WinForms launched from Outlook that mimic existing Outlook Forms behavior - a lot of work invoved to customize the forms to look and act exactly like the original Outlook forms, or else the users will find themselves frustrated and annoyed.

Any other possibilites, save for MS agreeing to accept the challenge and write an official ActiveX wrapper for .NET Controls?
August 19, 2005 9:09 AM
 

Anelia said:

Very nice blog.
September 2, 2005 1:36 AM
 

Blog de Frederic Queudret said:

Cet article fait suite à un atelier d'étude migration d'applications en VB6 vers .NET. La problématique

March 20, 2007 1:48 PM
 

Blog de Frederic Queudret said:

Cet article fait suite à un atelier d'étude migration d'applications en VB6 vers .NET. La problématique

March 21, 2007 10:43 AM
Anonymous comments are disabled

© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker