TRichView.com

Hi Sergey,

Let's say I have an RTF file with 2 hyperlinks that have the following target URLs:
http://www.google.com
www.google.com

The relevant portion of the RTF file looks like this:
\pard\fi0\li0\ql\ri0\sb0\sa0\itap0 {\field{\*\fldinst HYPERLINK "http://www.google.com"}{\fldrslt \plain \f0\ul\fs20\cf2 One}} \par
\pard\fi0\li0\ql\ri0\sb0\sa0\itap0 {\field{\*\fldinst HYPERLINK "www.google.com"}{\fldrslt \plain \f0\ul\fs20\cf2 Two}}

When I import this using InsertRTFFromFileEd(), I get the following:
http://www.google.com
C:\Program files\Whatever\Directory\The\RTF\File\Was\In\www.google.com

When the OnReadHyperlink() event is triggered, the Target parameter is already fully qualified with the wrong/inappropriate path, so it's somewhat tricky for me to fix this reliably in there.

I noticed the following:
Word 97 suffers from this problem, but to a lesser degree: the imported link is not qualified in the document itself, but the Hint it displays when the mouse hovers over the link is incorrectly qualified.
Word 2003 seems to have fixed this problem.

What do you think? I hope it's not a "feature"...

Thank you,

Michel

It is a feature.
If I, for example, upload HTML containing <a href="www.google.com" to the root folder of my website, the link will point to http://www.trichview.com/www.google.com , and this is a valid URL.

It is a feature

I was afraid you'd say that.

However, I don't quite understand the relevance of your example. I mean, what you said about uploading an HTML file is fine, except that my problem feels to me equivalent to you uploading "www.google.com" and the actual uploaded file ends up on the server with some file system path prepended!

Also, even if this were a feature, how is it useful or sensible? If someone or something is importing an RTF file, it's a file, so it resides in some file system (e.g., C:\Temp\), so it doesn't seem to make any sense to assume that any link (Web or not - because this problematic prefixing affects unqualified file links too) should be qualified with the file system path this RTF file happened to reside in.

Finally, it seems that at some point in time between Word 97 and Word 2003, Microsoft promoted this "feature" to the honorable status of a bug, and even fixed it!

Maybe I don't understand the deep and secret meaning of it, but it surely seems to me like something between an outright bug and a semi-destructive problem. Not something anybody would want under any circumstances.

Am I making sense?

Michel

In TRichView importing procedures, all paths which do not contain ':' are considered as relative paths. And I think it's normal.

Since TRichView 1.9.16, where is an option for not-adding the base path to relative hyperlinks/paths loaded from RTF. Set RichView.RTFReadProperties.BasePathLinks = False.

Ok, that BasePathLinks option is then probably all I need!

Thanks,

Michel