HELP Overriding URL resolution (data access) in WebBrowser Control

Folks,
The WebBrowser AX object includes a method called "Navigate2". Unfortunately, Navigate2 takes either a resource or URL as an argument. I have a need to use the web browser control to retrieve data from a data source not defined by an URL or a resource. I want to override the portion of the AX object which translates an URL (http://www.news.com) into a buffer and buffer length. In effect, i want the address MYSOURCE://0/0/0 when passed into Navigate2 method to retrieve HTML pages from a user defined source (ie I want to define a new URL data source).

I believe there must be another COM object located within the web browser control. This COM object is responsible for resolving the URL addresses. Unfortunately, I don't how to identify this COM object, or it's particular interfaces. Also, once I have found this object, I don't know how to override it with my own resolution interface.

Is there any extensibility located within the web browser control that would allow this functionality?

A good example of what I want to do is shown in the MSDN 6.0 release. Instead of accessing HTML pages directly, they have (somehow) overridden the URL resolution to resolve MK: to indicate reading a compiled HTML file (*.chm).

If that doesn't work, are there any other methods to achieve this same result?

What I have tried so far is to sink the event BeforeNavigate2 into a function OnBeforeNavigate2 which provides equivalent functionality to what is described above. I indicate a CANCEL, retrieve the proper HTML data from my data source, copy it to the HD c:\temp\temp.htm, and then issue a Navigate method to c:\temp\temp.htm.

While this works, its a) a BIG hack and more importantly b) when a frame window is viewed, its children frames are not sinked to my BeforeNavigate event override. For this reason, any data in frames is not properly displayed.

Try implementing a Custom Protocol Handler to deal with MYSOURCE: URLs.

Here is an excerpt from Microsoft's Internet Client SDK. It is well worth checking out. (I think now that it is part of the Platform SDK. I'll leave it to you to find.)

Sorry I can't be more specific, I'm just getting a handle on it myself. Good luck.

*************************
About Pluggable Protocols
Microsoft Internet Explorer uses two mechanisms for registering new URL protocol handlers. The first method is to register a URL protocol and its associated application so that all attempts to navigate to a URL using that protocol launch the application (for example, registering applications to handle mailto: or news: URLs). The second method uses the Asynchronous Pluggable Protocols API, which allows you to define new protocols by mapping the protocol scheme to a class.
For information on how to register an application for a particular URL protocol, see Appendix B: Registering an Application to a URL Protocol.
Asynchronous pluggable protocols offer three ways to map a protocol scheme to a class:
Permanently registering an asynchronous pluggable protocol handler in the registry. The handler is used for any URLs with the specified scheme (such as http, ftp, and so on).
Permanently or temporarily registering a pluggable name space handler. The handler is used for any URLs with the specified pattern in the scheme-specific portion of the URL for a particular protocol scheme.
Permanently or temporarily registering a MIME filter. The handler manipulates the data stream it receives and returns a data stream for any resources of the specified MIME type.
Note All asynchronous pluggable protocols must support the BINDF_NO_UI and BINDF_SILENTOPERATION flags.
Interfaces related to asynchronous pluggable protocols
IBindProtocol
IInternet
IInternetBindInfo
IInternetProtocol
IInternetProtocolInfo
IInternetProtocolRoot
IInternetProtocolSink
IInternetSession
Functions related to asynchronous pluggable protocols
CoInternetGetSession
About Asynchronous Pluggable Protocols
An asynchronous pluggable protocol handler is an apartment threaded Component Object Model (COM) object that handles any calls made to the protocol scheme that it is registered for. When a client application makes a request, Urlmon looks up the protocol scheme in the registry and creates an instance of the protocol handler registered for that protocol scheme. If the protocol scheme was successfully mapped to the class identifier (CLSID) of a protocol handler, CoCreateInstance is called with that class asking for an IClassFactory interface. An instance of the protocol handler is obtained with IClassFactory::CreateInstance.
To register a custom URL protocol, add a key for the protocol scheme of the custom URL protocol to the registry under HKEY_CLASSES_ROOT\PROTOCOLS\Handler\protocol_scheme. Under that key, the string value, CLSID, must be set to the CLSID of the protocol handler.
To register the custom protocol scheme example, you would have to add a key named example to the registry under HKEY_CLASSES_ROOT\PROTOCOLS\Handler. Under the new key, HKEY_CLASSES_ROOT\PROTOCOLS\Handler\example, the string value, CLSID, must be assigned the CLSID of the protocol handler. Any URLs with the protocol scheme example: would be handled by the protocol handler associated with the CLSID value.
The protocol handler cannot use any Windows® messaging to switch back to the thread it was instantiated on, since the protocol handler must work on non-GUI threads.
Note All asynchronous pluggable protocols must support the BINDF_NO_UI and BINDF_SILENTOPERATION flags.
About Pluggable Name Space Handlers
A pluggable name space handler is an asynchronous pluggable protocol handler that you can set up to handle various protocol schemes and patterns. If a pluggable name space handler understands a particular URL, the handler will start successfully. Otherwise, the pluggable name space handler indicates that the default protocol handler for that protocol scheme should be used. A pluggable name space handler can be installed permanently or temporarily and can include specific patterns to indicate when it should be used.
Multiple pluggable name space handlers can be registered either temporarily or permanently. Temporarily registered pluggable name space handlers are called first and in the reverse order in which they were registered. This means the temporary pluggable name space handler that was registered last will be called first. Permanent name space handlers are not called in a specific order, so there is no way to insure which handler will be called first.
Note All asynchronous pluggable name space handlers must support the BINDF_NO_UI and BINDF_SILENTOPERATION flags.
Permanent pluggable name space handlers
To set up a permanent pluggable name space handler, you must register it in the registry with the key HKEY_CLASSES_ROOT\PROTOCOLS\Name-Space Handler\protocol_scheme\handler_name. Under this key, you must set the values for a CLSID and any pattern string that you include. If no pattern strings are set, the handler is called for all requests for the specified protocol scheme.
If there are multiple permanent pluggable name space handlers registered, the order that they are called in is random, so handlers should only specify name spaces that they have control over to avoid handling name spaces specified by another handler.
In the following example, the pluggable name space handler Ohserv-Handler is to be called for all HTTP requests with the URL http://ohserv/.
HKEY_CLASSES_ROOT\PROTOCOLS\Name-Space Handler\http\Ohserv-Handler
CLSID = {..}
Pattern1 = "ohserv"
Pattern1 is a pattern string that is used to determine if this handler should be used on a particular URL. If a handler has multiple pattern strings (Pattern1, Pattern2, Pattern3, and so on), the browser checks the pattern strings listed to see if any of them match the URL the browser is trying to access. If there is a match, the handler is used; if there isn't, the handler is not used.
Note Valid pattern strings cannot have a leading wildcard character, such as *.com, and should only handle a specific group of known name spaces (for example, URLs for your company's Web sites). Pattern strings that could include numerous Web sites might conflict with other name space handlers that are provided for that specific site.
Temporary pluggable name space handlers
You can register and unregister a temporary pluggable name space handler by using the IInternetSession interface.