I know that you can control the name of a chunk by setting Breaks (tab) > HTML Chunking button > Persistent file name (drop-down) > from attribute (drop-down).
Has anyone been able to set the id value?
For example, I get the following output (via View Source in the .chm / HTML Help file):
And "#styler-id220.127.116.11" is the named target of the TOC entry and it is also possible to open the .chm to the page and location (what I am ultimately wanting to do) by executing something like:
ss hh "c:\path\filename.chm::/persistentchunkname.htm#styler-id18.104.22.168"&
Except I want to be able to control the id value so it would be this instead:
ss hh "c:\path\filename.chm::/persistentchunkname.htm#persistentidvalue"&
It's easy right? You know JUST how to do that. Bueller? Bueller? Bueller? ....
I've played a little bit with HTML Help source edits, but all that is accessible is: <xsl:call-template name="object.id">
And removing that and replacing with an xsl:text forcing it to "qwerty" doesn't survive the composition. Something else, I believe the function generate-id(), ends up overriding whatever you insert where the xsl:call-template call referenced above is made. generate-id() is apparently a core function ... I can't find it anywhere accessible.
Oh, and I'd be happy with some other way to get where I'm going ... to be able to author persistent links to HTML Help content generated by PE. We went down a similar path re: id maps and DMP a while back. Am assuming the limited functionality there is the same as here since the path is the same/similar by way of HTML Help generation as an intermediary format.
Thanks, Clay. I was distracted by the fact that our linking relies on ID attributes on the title parent, not on title. If I add any attribute, type ID, to title and populate it, it works as you say. So now I'm trying to hack away and cheat the fact that our IDs are on title parents to see if I can get away without requiring an additional (or relocated) ID attribute.
But ... worst case, I can write the parent ID with "title" appended or some similar strategy to the title element on save.
I feel your pain, and I have often wondered about the reasoning behind the way they render links as pointing to title text rather than containers. It certainly makes things more complicated in situations like this.
You might be able to rig something in your publishing process to do this on the fly (propagating modified container ID's to the <title> element), via customizing comp_htmlhelp::htmlhelp_preprocessing ().
[Crazy. Just found this in Drafts ... actually sent before it was the weekend. Does that count as time travel?]
Now I have a couple of ways to skin the cat. Thanks again Clay.
I created a file named htmlhelp_preprocessing.acl and copied the function htmlhelp_preprocessing into it and started the whole thing off with "package com_htmlhelp" which overwrites just that one function leaving all the rest in the core source alone.
Then I added this to the end of the function, just before return 1: