P
Peter Wone
Hosting the WebBrowser control is easy. Customising it is not. You have to
implement IDocHostShowUI, IDocHostUIHandler, IDocHostUIHandler2, and
IOleClientSite, not one of which appears in a typelib that I could find.
With aid from around the world I did just that, and put together a
comprehensive set of interfaces and enumerations, and I used them on my
forms to set up the form as the client site for the browser object
implementing squillions of callback interfaces.
Wonderful wonderful, works a treat.
Now I have a colleague, of lesser mettle, who though learning fast is
perhaps not ready for the subtle nastiness of DIY interop. And ultimately,
through all of this gnarly COM stuff, all it's really doing is asking for
settings and firing events.
So today I decided to implement a UserControl that hosts a WebBrowser, sets
itself up as the client site and either handles the callbacks itself getting
settings from properties of the UserControl or presenting callbacks as
events.
So here's the freaky thing: this code works fine in the constructor of a
Form.
InitializeComponent();
(wb.GetOcx() as IOleObject).SetClientSite(this as IOleClientSite);
wb.Navigate("about:blank");
but the same code throws a NullReferenceException in the constructor of a
UserControl. I checked the generated code to compare the way the web browser
is initialised and the same sequence occurs in both form and UserControl.
I found a fix. It works. What I do NOT like is the fact that I don't know
why. This works:
InitializeComponent();
wb.Navigate("about:blank");
(wb.GetOcx() as IOleObject).SetClientSite(this as IOleClientSite);
wb.Navigate("about:blank");
Now, the primary difference between wb before and after using the Navigate()
method is that before, there is no MSHTML instance and afterwards an
instance has been created. Great, that fits with the NullReferenceException
going away. But if that's what's wrong, then why the @#$%@!! does it work on
the form?
I am willing to release source code to anyone credible.
It smells a bit like certain messages are seen by the browser when on a form
but not when on a UserControl. I'm going to subclass (as opposed to
aggregating) the browser class so I can override WndProc and log messages. I
look forward to your collective insight.
implement IDocHostShowUI, IDocHostUIHandler, IDocHostUIHandler2, and
IOleClientSite, not one of which appears in a typelib that I could find.
With aid from around the world I did just that, and put together a
comprehensive set of interfaces and enumerations, and I used them on my
forms to set up the form as the client site for the browser object
implementing squillions of callback interfaces.
Wonderful wonderful, works a treat.
Now I have a colleague, of lesser mettle, who though learning fast is
perhaps not ready for the subtle nastiness of DIY interop. And ultimately,
through all of this gnarly COM stuff, all it's really doing is asking for
settings and firing events.
So today I decided to implement a UserControl that hosts a WebBrowser, sets
itself up as the client site and either handles the callbacks itself getting
settings from properties of the UserControl or presenting callbacks as
events.
So here's the freaky thing: this code works fine in the constructor of a
Form.
InitializeComponent();
(wb.GetOcx() as IOleObject).SetClientSite(this as IOleClientSite);
wb.Navigate("about:blank");
but the same code throws a NullReferenceException in the constructor of a
UserControl. I checked the generated code to compare the way the web browser
is initialised and the same sequence occurs in both form and UserControl.
I found a fix. It works. What I do NOT like is the fact that I don't know
why. This works:
InitializeComponent();
wb.Navigate("about:blank");
(wb.GetOcx() as IOleObject).SetClientSite(this as IOleClientSite);
wb.Navigate("about:blank");
Now, the primary difference between wb before and after using the Navigate()
method is that before, there is no MSHTML instance and afterwards an
instance has been created. Great, that fits with the NullReferenceException
going away. But if that's what's wrong, then why the @#$%@!! does it work on
the form?
I am willing to release source code to anyone credible.
It smells a bit like certain messages are seen by the browser when on a form
but not when on a UserControl. I'm going to subclass (as opposed to
aggregating) the browser class so I can override WndProc and log messages. I
look forward to your collective insight.