CSH on an Old Legacy Help Project

[artm54446707]

Hi All,

I've spent a few days looking through the forums, and while some have come close, I need more specifics.  Let me try to describe what's going on:

I recently 'inherited' a RoboHelp project a couple of thousand web pages deep that's probably 13 or more years old.  The original author and developer are no longer with the organization.  We recently upgraded to Rh 2015 and the conversion to the updated software (from Rh 11 to 2015) appears to have completed without incident.  (Let me add here that although I've been a Technical Writer for about 25 years, this is my first exposure to RoboHelp.  My 'training' consisted of a three hour crash course provided to me by my predecessor.  Unfortunately, she left a few things out...)

I've learned to update content, generate and sequence the TOC, create books, and compile the project.  When I compile and pull it up in my sandbox, everything looks good, whether I'm looking at it in IE, FireFox, or Chrome.

The PROBLEM:  In Production, we have context sensitive help (CSH) enabled, so that when you visit a particular page of the web application and click the 'Help' link, the Help page for that screen displays.  However, when I visit a page in our Test environment and click the 'Help' link, the Help screen defaults to the 'Welcome' screen for all pages.

I've been doing some reading and exchanging emails with my former colleague.  From that, I suspect that we're using a 'TopicId' method employing hashed URL fragments (http://myserver/myhelpproject/index.htm#SampleHelpPage.htm).

I've also looked at the BSSCDefault.h and whcshdata.js files and both are empty.

How do I?  Or where do I look to identify which method is being used?  And any options on how best to proceed to restore CSH in Test?  What other information should I be providing?  And lastly, what other questions should I be asking?

Thanks!

Art

[Captiv8r]

Hi there

When you are in the live environment and you summon a CSH topic, I'd check the address bar and see what it says. That may provide a clue as to exactly what method is being used to call the help.

Cheers... Rick

[artm54446707]

Hi Guys,

Thanks for the replies.

Here are the link forms from PRD (they're identical to TST):

Below is a link to a typical topic page.  The 'nsystem' denotes 'new' system name and the 'lsystem' below denotes 'legacy' system name.  I have no insight into why the original developers elected to mix and match legacy and new system names.  What I can tell you though, is that every worked, once upon a time.

https://www.mysystem.com/prod/nSYSTEM/nsystem/topicpage

This is the link from the topic page to the associated Help page:

https://www.mysystem.com/prod/help/lsystem/lSYSTEM_Help.htm#nsystem/TopicPage.htm

This is the direct link to the topic Help page:

https://www.mysystem.com/prod/help/lsystem/nSYSTEM/TopicPage.htm

Peter, at this point, I'm inclined to agree with you about this being a developer issue.  I contacted my predecessor yesterday and she mentioned that she had encountered problems with developers changing file names and other practices that could break a Help project.  I also noticed that CSH is now broken in PRD, as well (it was working at the beginning of the week).

I'm trying to locate a file list that CSH might use to cross-reference topics to pages.  My predecessor mentioned that they always used a 'Roles' page that listed all of the Help topic file names which they bounced off the application file names to ensure topic files and Help files matched.  I'd think there would be some kind of xref file, but nothing I've found so far looks like that.  Or am I completely missing the mark?

Thanks for your time on this,

Art

[Peter Grainge]

This does look more and more like a developer issue.

Your links have some case differences in them. Depending on the server operating system, that could be an issue.

I'm trying to locate a file list that CSH might use to cross-reference topics to pages.  My predecessor mentioned that they always used a 'Roles' page that listed all of the Help topic file names which they bounced off the application file names to ensure topic files and Help files matched.

As you are using URLs, there is no CSH file. I think the Roles page must be something internal.

---

See www.grainge.org for RoboHelp and Authoring information

@petergrainge

[artm54446707]

Thanks for the reply, Peter.

I suspect I've taken this about as far as I can without engaging the Developers.  Unfortunately, none of them have any experience with this Help project.  And I'll need to submit a Problem Report so they'll have a charge code.  The bright side is that, since inheriting this brain-burner I've documented everything, so when some future generation runs into similar issues, they'll have backstory.

And, thanks to you guys here (and a whole grunch of elsewheres), I've got a raft of notes that should help get our Web team started.  I'll post a synopsis of our findings here once we get it fixed.

Thanks again!

Art

[Peter Grainge]

From the link you have provided, it does look as if you are using the URL method that using path and file names. It does not require Topic IDs, hence those files being empty. See the Calling WebHelp page on my site for an explanation and there are links to Willam van Weelden's site with more information.

I was thinking that maybe the path from the app to the help is not valid in the test environment but then I thought that if that were the case, it wouldn't even find the home page. Have you tested the whole help is in the test environment by opening it direct and testing it works in all respects.

Good to see you got more training than I did. One Tuesday I think it was I was told I was taking over the help the next week.

"Mick will show you."

"He's leaving on Friday!"

"He'll show you before he goes."

I was just shown how to add footnotes in Word before running that through the Microsoft Help Compiler!

My gut feel is this is a problem for the developers.

---

See www.grainge.org for RoboHelp and Authoring information

@petergrainge