startTopic not showing in CSH call

[parsonsv]

Up until our recent upgrade to Flare 8.1.2 (may or may not be related), our CSH calls would appear like this in the Web browser when called from the software:

Code: Select all

http://help.mycompany.com/SoftwareName/2.1.0/Name_Help_Left.htm#CSHID=Set_Property_Dialog_Box|StartTopic=Content%2FTopics%2FWorkInSoftware%2FSet_Property_Dialog_Box.htm|SkinName=Product

Now they look like this:

Code: Select all

http://help.mycompany.com/SoftwareName/2.1.0/Name_Help_Left.htm#CSHID=Set_Property_Dialog_Box|SkinName=Product

If you notice, before after the software read the Alias file (the .h file), it added the StartTopic portion into the CSH call. However, in the new call, this StartTopic portion is no longer in the call, and the software is left to open the introduction.htm page (which is the default start page if a CSH link isn't found).

Why in the world would a new CSH link we create in Flare and implement in the software no longer include this StartTopic section in the call? Any idea?

[Msquared]

Well, I may be talking complete nonsense, but I'm just trawling through the CSH information myself for the first time, to work out how to set it up. I've found something that may be relevant to you.

On page 88-89 of the Flare Context Sensitive Help Guide, section How to use an URL to open WebHelp or WebHelp Plus (Flare 8 documentation), it talks about what the developer has to do to set up the link to the CSH. I think what you're referring to in this post may be controlled by something your developer does. So is it possible that your developers have changed something? Perhaps they made some sort of global change to the link structure, and didn't realise they were affecting the help too?

As I say, this may be completly wrong, but there it is.

[NorthEast]

I'm not sure what the two examples are.

The first example looks like the URL displayed in the browser after a CSH call has been made to WebHelp output. The URL displayed in the browser after opening the help will not be the same as the original URL used in the CSH call.
The CSH call made by the software should look completely different to that, and wouldn't include a StartTopic parameter.

The second example looks more like a CSH call that has been made to HTML5 help. HTML5 help uses a different format for CSH calls to WebHelp, and the resulting URL displayed in the browser will also look completely different.

[parsonsv]

Both are browser strings AFTER the CSH call from the software. Any CSH made in Flare 7 contains the StartTopic portion of the string. Any CSH made in Flare 8 fails when called from the software, and the difference in the browser is the absence of that StartTopic portion of the string.

I am interested to hear that the StartTopic portion is supposed to be missing in the HTML5 output because I wonder if that's the bug (and yeah, I think this is a Flare 8 bug). While my output is webhelp, not html5 help, if new CSH created in flare use the new html5 standard then that would be why, maybe?

To fix this, I downloaded and recreated my CSH links in Flare 7 and provided them to the developer. Magically, they all worked again.