Ok, I know this is an old topic, but for me it's new. And with all
that's been written, I still have outstanding issues. I've been able to
get .NET controls to be hosted in IE and able to deal with the
dependent assembly and strong name issues. But I've not been able to
get Javascript to communicate with the control.
In this blog post
(http://blogs.msdn.com/andrewdownum/archive/2006/01/25/ControlInBrowserProperties
AndMethods.aspx),
this person claims to very simply get javascript to call a method and
property on a .NET control hosted in IE. Using the code as shown, I
cannot get this to work. Here's another article with a simple example
that I cannot get to work
(http://windowsforms.net/articles/iesourcing.aspx).
1) Is it even possible using such simplistic code? There are no
attributes shown. There is no mention of making it COM interoperable.
It makes sense to me. IE has special behavior to load up a .NET
control. Any access to it via Javascript or whatever script, you would
think, had .NET adapters so that nothing special had to be done on the
control side.
2) If it isn't as simple as shown, then how do I get Javascript to
communicate to the .NET control?
Do I *have* to expose a COM interface and register for COM interop?
Do I *have* to implement IObjectSafety?
Do I *have* to ....?
3) Lastly, if I have to expose a COM interface from my .NET control, do
I also *have* to register it (using regasm or whatever) BEFORE it is
usable in IE? Or, can it self register upon its first initialization?
If the former is the case, this is a bit counterintuitive since one of
the reasons to host a .NET control is to deploy it on demand without
any administrative activies upfront.
All help is appreciated.
Thanks
Gary F.
Gary F. - 29 Mar 2006 22:05 GMT
I don't believe this. Less than 1 hour after I posted this message, I
found some answers. Isn't it always the case.
Ok, so here's what I found (recorded here for posterity).
To answer my Question 1, yes and no. Yes, this very simplistic class
can be scripted against. No, not all info was in the author's article.
I enabled "Register for COM interop" in the build settings and turned
on COM visbility - [assembly: ComVisible(true)] - in AssemblyInfo.cs.
Yeah, I understand that turns it on for all classes but for now I just
want to get something working. I'll whittle down visibility later.
Re: Question 2, I'm exposing a COM interface by virtue of setting
ComVisible to true. I'm not doing anything special for IObjectSafety.
I've come across posting saying that a .NET control already implements
IObjectSafety. I've tried increasing some IE ActiveX settings and I
haven't run into anything yet, though I'm only running this as
localhost.
Re: Question 3. I love this one. It appears that the COM interface of
my .NET control is registered with the Windows registry after the .NET
control has been downloaded. I'm assuming IEHost or IEExec or something
is doing that on my behalf. That's perfect.
Just 1 glitch - the control still stays registered in the Windows
registry after it has been deleted from the download area of the GAC.
It doesn't make sense to me to still have it in the Windows registry if
all access to it from the desktop has been removed, or am I missing
something? Anyone know how to fix this?
On to the next hurdle.
Gary F.
Gary F. - 30 Mar 2006 04:20 GMT
I will now explain my next hurdle and how it was overcome.
So the hurdle (or hurdles) were to add an IObjectSafety implementation,
event source functionality, and a limited, cleaner exposed COM
interface. I did this all in this order.
IObjectSafety was easy mainly because of a well-written blog article
http://blogs.msdn.com/infopath/archive/2005/04/15/408728.aspx
The event source functionality was easy as well because of the said
blog article.
Lastly, the exposed COM interface was NOT easy. This was the last task.
So naturally, I just added an IUserControl1 interface to the end of my
class declaration. It looked like this:
public class UserControl1 : UserControl, IObjectSafety,
IUserControl1 {;}
I could NOT get javascript to call any methods or props on
UserControl1. It was maddening especially having done it without
splitting the interface.
It turns out, after pouring over the ComXXXAttribute attributes,
there's one called ComDefaultInterfaceAttribute. That one specifies the
default interface for the class. I'm assuming that the late binding IE
has to use the default interface. Makes sense. Anyhow, it turns out
that I can use ComDefaultInterface or I can just rearrange my
interfaces in the class declaration.
Gary F.