Documentation v15 help: More odd mailto: links in the help

[Dan Glynhampton]

1. TCC > Variable & Functions > Functions > @FTYPE

The example contains a mailto: link which creates an e-mail addressed to %@ftype[Word.Document.8​

2. TCC > Variable & Functions > Functions > @FORMATNC

Both examples contain mailto: links which create e-mails addressed to %@formatnc[5.10,%@eval[2300*4.7] and %@formatnc[010.3,5 respectively.​

3. TCC > Variable & Functions > Functions > @FORMATN

Both examples contain mailto: links which create e-mails addressed to %@formatn[5.10,%@eval[2300*4.7] and %@formatn[010.3,5 respectively.​

4. TCC > Variable & Functions > Functions > @FLOOR

The first example contains a mailto: link which creates an e-mail addressed to %@floor[3.14​

5. TCC > Variable & Functions > Functions > @FILESIZE

The first example contains a mailto: link which creates an e-mail addressed to %@filesize[d:\path\myfile.ext​

​

 

[rconn]

These are the result of the Help Compiler being "helpful". (And it's a royal PITA to convince it *not* to do it for each one -- there's no way to prevent it globally.)

 

[Dan Glynhampton]

These are the result of the Help Compiler being "helpful". (And it's a royal PITA to convince it *not* to do it for each one -- there's no way to prevent it globally.)

I see what you mean, it's assuming that if you use a "@" symbol then it *must* be an e-mail address, and since all the TCC functions us an "@" I also see why it is a PITA!

 

[mathewsdw]

I see what you mean, it's assuming that if you use a "@" symbol then it *must* be an e-mail address, and since all the TCC functions us an "@" I also see why is a PITA!

Rex, a possibly unhelpful suggestion: Use a character other than "@" in the help file (possibly a tilde?) and then use a binary editor to do a global replace of the tilde by an at-sign. (I used to have an editor with which I could do such things, but that was a long time ago and I don't even remember what the editor was/where I got it from. However, I think a program could be written rather easily in a high-level language to do such a replacement. The only problem would come if the help file had a CRC (a value that's typically derived by XOR'ing all of the bytes in the file together) which I think is rather doubtful for a help file.

 

[rconn]

The help files are compiled to a binary (.CHM) format, so at that point I can't substitute anything.

 

[Olly]

The help files are compiled to a binary (.CHM) format, so at that point I can't substitute anything.

that´s why Mathew suggested to use a binary editor for replacement purposes :)

 

[Dan Glynhampton]

that´s why Mathew suggested to use a binary editor for replacement purposes :)

But by that time it's too late, the mailto: links will have been created in the .CHM file and replacing an individual character won't change that. The issue is telling the help compiler not to treat every sequence of x@yy as an e-mail address and thus creating a mailto: link for it. Since there's no global configuration option to set that Rex has to nurdle each instance separately in the help source code

 

[rconn]

And the individual '@' characters have been replaced by other (unknown) ones during the compilation as part of the compression encoding -- they don't exist in the .CHM output file.

 

[Charles Dye]

And the individual '@' characters have been replaced by other (unknown) ones during the compilation as part of the compression encoding -- they don't exist in the .CHM output file.

Now if you could do that to the compiler, so it uses, say, a cent sign to detect email addresses, that would be helpful! But finding the correct one would doubtless be a royal pain.