> STILL I am not so sure what the original poster > actually wants to achieve.
Neither do I. However I'd like to point that there is a lot of really cool solutions you can do with PPH + CLR hosting. Like, for example to integrate C#/JScript program with DHTML you can use <object> tag with code base that points to your PPH's URL scheme, and make you PPH to dynamically compile code, create AppDomain and register object and viola, you can call methods of this object directly from DHTML script... (as an example think of SOAP over .Net directly from DHTML)... Or you can dynamically populate XML document stream with data from Database, Active Directory, Web storage or any other data source, and return it as a result of your PPH, and any program that need this data just use Load method of XMLDocument to read data in. -Valery. -----Original Message----- From: Thomas Tomiczek [mailto:[EMAIL PROTECTED]] Sent: Friday, May 10, 2002 10:02 AM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] custom URL protocol handler I know, STILL I am not so sure what the original poster actually wants to achieve. And I am pretty sure he does not talk of C++ :-) Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) -----Original Message----- From: Valery Pryamikov [mailto:[EMAIL PROTECTED]] Sent: Freitag, 10. Mai 2002 09:55 To: [EMAIL PROTECTED] Subject: Re: [DOTNET] custom URL protocol handler Thomas, IE clickable and pluggable protocol handlers are rather different things. With PPH you can use URL from any URLMoniker consumer, like f.e. source to XML Document, or URL for DirectX media surface image, and anything else. You control your own URL schema as you wish, and at last - to implement PPH isn't such a difficult job, esp. if you use helper classes from my web page ;-). As an example - vp.inlineurl protocol is only 32 lines of C++ code long ;-). -Valery. -----Original Message----- From: Thomas Tomiczek [mailto:[EMAIL PROTECTED]] Sent: Friday, May 10, 2002 9:46 AM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] custom URL protocol handler Valery, You define overkill by a far margin - well, it MAY be. To implement a handler for a "clickable" protocol in IE all you need is ONE (!) registry key to be set. Then the hyperlink click will start an executable with the hyperlink as parameter. The original poster asked for a class exposed, BUT - maybe he wants to make something like an email client, look-wise. Actually, I would have preferred to know more about what he wants to achieve - he wants something handled from within IE, and if this is as a result for a hyperlink (like the user clicking on a hyperlink to start an application), then this is easier. We use the protocol handler plus a "pickup application" that is then starting the real app and getting the URL by windows message. Reference: http://msdn.microsoft.com/workshop/networking/pluggable/overview/appendi x_a.asp Titled: Registering an Application to a URL Protocol In most cases this is enough :-) Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) -----Original Message----- From: Valery Pryamikov [mailto:[EMAIL PROTECTED]] Sent: Freitag, 10. Mai 2002 09:33 To: [EMAIL PROTECTED] Subject: Re: [DOTNET] custom URL protocol handler Hi, To use it from IE (and other URLMoniker consumers) you have to implement your own Pluggable Protocol Handler. You can find a couple of C++ (VC6) samples how to implement your PPH on my webpage http://home.online.no/~valery. Tim Tabor also has PPH sample on his website, which you can check. Clear .Net solution doesn't quite work, except if you just go interop way, implement all necessary PPH support+registration and register you .Net object as COM object. You'll also need to put it into the GAC along the way, for making it available for any URLMoniker consumer. Another way of solving it could be to implement un-managed PPH (in C++) and host CLR from it. It will give you many more available choices than going other way around. F.e. just think of the providing you own Evidence, or/and ApplicationBase/PrivateBinPath, ConfigurationFile and so fourth. Possibilities with the later solution is quite impressive, like f.e. you can use CodeDOM to dynamically compile and run embedded Jscript/CSharp/VB.Net code; use .Net remoting for communicating to .Net remote objects and/or webservices + many-many more. And hosting CLR is rather simple and straight-forward task - check "hosting interfaces.doc" in Tools Developers Guide. -Valery. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
