Article Writing

1-Jan-03 9:34

In the newsgroups and message boards, you see a lot of "The only way to resolve relative urls is with a url moniker. That's doable in c# but really hard." You never see any c# code on how to do it. Lots of people give the url to the ms docs on how to do it in c++/non-.net.

I don't know com very well, I'm a java programmer. I can handle a little interop but not that much of it. I would do it if I could.

"Outside of a dog, a book is Man’s best friend. And inside of a dog, it’s too dark to read."
-Groucho Marx

Stephane Rodriguez.1-Jan-03 10:22

1-Jan-03 10:22

Bog wrote:
The only way to resolve relative urls is with a url moniker. That's doable in c# but really hard.

I am not sure I understand. URL monikers are not to solve URLs, they are meant to download stuff pointed by URIs.
Do you need to download stuff ?
If yes, and if it's an http:// URI, then you've got the WebRequest(URLBuilder) .NET class waiting for you.
It's asynchronous, in exactly the same way than standard WIN32 URL monikers are (IBindStatusCallback, etc.).

May be by solving URLs you were meaning splitting URLs into pieces. This can be done with the URLBuilder .NET class. (saying so, I wanted to make sure not anyone tells you to rely on the WIN32 InternetCrackUrl() function).

Bog1-Jan-03 10:54

1-Jan-03 10:54

What I mean is, as an example, if I download a webpage (via whatever- httpwebrequest let's say), and I want to then load that html into a webbrowser control, either by saving it to a file or by loading it in as a stream, all of the relative url paths will be wrong. in other words, images will be broken and links won't work.

"Outside of a dog, a book is Man’s best friend. And inside of a dog, it’s too dark to read."
-Groucho Marx

Stephane Rodriguez.1-Jan-03 18:51

1-Jan-03 18:51

Bog wrote:
What I mean is, as an example, if I download a webpage (via whatever- httpwebrequest let's say), and I want to then load that html into a webbrowser control, either by saving it to a file or by loading it in as a stream, all of the relative url paths will be wrong. in other words, images will be broken and links won't work.

That's correct, at least for relative resource URIs. Absolute resource URIs are going to work, in the sense that IE is going to launch threads and retrieve the content for it. But URL monikers have nothing to do about it.
To solve this, do one of these :
- invoke explicit URIs for all resources (html tags with a src= attribute). This means you have to parse the html page yourself.
- add a <base href=domainhost> tag in the html page you have just downloaded. Doing so, IE remaps relative links to the actual target website, and does all the proper resource retrieval.

Good luck!

Bog2-Jan-03 7:05

2-Jan-03 7:05

Neither one of those will completely work.

Parsing the entire html file will only fix the element's urls. It won't fix javascript's local references, or local references in things like applets and flash. Besides which, that solution is slow compaired to writing a URL Moniker.

The < base > element is also not a complete solution. Anchor links won't work. Nor will protocol-independent links like "//www.codeproject.com/", which are perfectly legal according to rfc 2068, and work in all major browsers. IBM uses them for example.

If you read the microsoft.public.dotnet.languages.csharp group, you see a lot of posts saying that URL Monikers do have something to do about it, and are the way to go, but difficult to implement.

"Outside of a dog, a book is Man’s best friend. And inside of a dog, it’s too dark to read."
-Groucho Marx

Stephane Rodriguez.2-Jan-03 7:39

2-Jan-03 7:39

Bog wrote:
Parsing the entire html file will only fix the element's urls. It won't fix javascript's local references, or local references in things like applets and flash. Besides which, that solution is slow compaired to writing a URL Moniker.

I am not sure a URL moniker is going to be of any help, but ok just go ahead.

Bog wrote:
The < base > element is also not a complete solution. Anchor links won't work. Nor will protocol-independent links like "//www.codeproject.com/", which are perfectly legal according to rfc 2068, and work in all major browsers. IBM uses them for example.

as far as I know, anchor links work.

About the protocol-independent stuff, you're probably right even though I don't think you should care much about that. 99.99% links are standard URIs.

Bog2-Jan-03 8:00

Re: Extra Explorer Buttons

2-Jan-03 8:00

Here is a post from one of the MVP's saying that URL moniker is going to do this,

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=u9%23II0fi%24GA.261%40cppssbbsa05&rnum=5&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26q%3Dnicholas%2Bmoniker%26meta%3D

And anchor links won't work- try it.

I've been trying to "just go ahead" for weeks! Hence my suggestion for it as an article...

thanks for your responses,

"Outside of a dog, a book is Man’s best friend. And inside of a dog, it’s too dark to read."
-Groucho Marx

Extra Explorer Buttons

SLiDeR31-Dec-02 15:36

SLiDeR

31-Dec-02 15:36

Does somebody know how to add a button "New Folder" to explorer toolbar? For example "Open" and "Save as" dialogs have this button. But Exporer itself doesn't.

Stephane Rodriguez.31-Dec-02 18:38