.NET 2.0: WebBrowser, Asynchronous pluggable protocols and DisconnectedContext MDA

Hi.

I'v initially posted this into .NET Development / CLR, but here it seems to be more suitable, so I would like to repeat my question.

Well, I have implemented a couple of asynchronous pluggable protocols (in C#) for IE. They are registered as temporary namespace handlers and used with WebBrowser controls in my WinForms project. All works fine until WebBrowser.ShowPrintPreviewDialog() is called. Then, during next garbage collection (started by GC itself or invoked by GC.Collect()), the DisconnectedContext MDA is activated while debugging or, if application runs separately from debugger, there SEHExceptions or something like are thrown. Sometimes in this case an application can simply hang (stop responding on keyboard and mouse input) without any exceptions. So what is the workaround for that

The entry point method of an application is marked with STAThread attribute (otherwise WebBrowser control cannot be instantiated), and creation and usage of my objects that implement pluggable protocols proceed in the same thread, of course, the main (GUI) thread. But I'v noticed that Print Preview Dialog shown by ShowPrintPreviewDialog() uses its own thread and operates with my pluggable protocol handlers in that thread. Could it be the core of a problem, and if so, how can I fix that

Hi,

Although I am not answering your question at all, I was wondering if you were able to successfully develop an APP by implementing the IInternetProtocol interface, or just using the .NET's RegisterNameSpcae method.

Thanks,

Ophir.

Ophir,

there are no any difficulties, actually. Yes, I¡¯ve just implemented IInternetProtocol (and IInternetProtocolRoot, of course) and IInternetProtocolInfo. Since all I needed were temporary namespace handlers (used only in concrete instance of my application), I¡¯ve used RegistrationServices.RegisterAssembly() to add to registry info required by COM to instantiate objects (in fact, links to mscoree.dll) on application startup and UnregisterAssembly() at shutdown. Next, the DllGetClassObject() function has been imported from mscoree.dll to get pointer to class factory (provided by mscoree.dll) and then pass this pointer to IInternetSession.RegisterNameSpace(). An IInternetSession pointer can be obtained via CoInternetGetSession(). This works and one can find many similar implementations of APP across the internet. But problems start rising when managed implementations of APPs used in multithreading environment, for example, when using WebBrowser.ShowPrintPreviewDialog() (print preview window has its own gui thread)...

Hello again maybeleo,

Thank you for your response. Since I have read you post, I have been trying to implement this myself. However, I am still ecountering some problems. I also looked across the web trying to find some code example, but still - no luck. I would appreciate it if you could post some code for me to see, or even post a link that I can follow regarding that subject.

Thanks in advance.

Hi, Ophir G!

Here http://ultrashare.net/hosting/fl/5b0e6e424c you can find an archive with a couple of source files. This is a simple abstract class named IeApp that implements basic functionality of IE APPs. All you need is to write your descendant, mark it with [Guid(your_newly_generated_guid), ComVisible(true)], and override two abstract members - ProcessRequest() and Scheme. This implementation assumes your protocol needs not much time to reply on request. Here is simple example:

In this example an URL like printemplate:/// sometemplate is passed (this is not shown here) to IOleCommandTarget.Exec() and then handled by my pluggable protocol (implemented by Class3) which just loads some template from resources and returns it to IE. Of course, APPs need registration. Since it's just temporary protocol handler, you may use something like this in your WinForms application:

Now, for any instance of WebBrowser control used in your application a new printemplate:// protocol is available. Good luck!

Hello again maybeleo,

I want to thank you for sending your code and explaining so well. However, I tried using your solution for intercepting HTTP requests and send them myself, using the HttpWebRequets class and it did not work. Unfortunately, it seems that it is an impossible thing to do with the current interoperability architecture.

I want to thank you again for replying my messages.

Ophir.

You are right. However, trying to implement APP for IE (or a WebBrowser control) resulted a very buggy application providing many crashes.

You can read more here:

http://groups.google.com/group/microsoft.public.inetsdk.programming.webbrowser_ctl/browse_thread/thread/3b1aa8af584af95b/a91685515f68aa09 hl=en#a91685515f68aa09

Ophir.

Hi, RatneshK!

That code is far from being legendary

Yes, as I wrote above, this is very basic implementation and assumes that request processing doesn't require significant time. If you need some other scenario, you should refer to the description of IInternetProtocolRoot.Start in msdn. There stated that you can return E_PENDING to indicate that operation started but will complete asynchronously. You should also make some experiments with IInternetProtocolSink.ReportData method to indicate urlmon.dll your progress and state. As for using standard handlers - sorry, I didn't dig this issue deeply. The only thing I know that permanent handlers are registered under HKEY_CLASSES_ROOT\PROTOCOLS\Handler. You probably can obtain clsid for http, for example, and create standard handler with Activator.CreateInstance(Type.GetGetTypeFromCLSID(Guid clsid)), and then use it inside your pluggable handler.

P.S. Here is description of APPs. Plus a lot of experiments from your side