Context Sensitive Help missing left pane

[DanChicago]

How do I open a specific topic in WebHelp output so that the left pane is displayed with it? If you open a specific page in webhelp, it only shows the content of the page and is missing the TOC, Index, and Search area.

I am trying to generate context sensitive help in WebHelp. When the help is generated by Robohelp, there is a primary file named by default as "helpfile.html" that opens the entire help window, with a left pane and a right pane. The left pane has the TOC and Index, and the right pane has the content of the page, e.g., the help.

A separate html page is generated for each page written in help. However if you open or call one of these pages as you would in context sensitive help, only the content of the page opens and is missing the left side with the TOC and Index/Search.

So how do I call a specific page to open with the left pane included??

[Peter Grainge]

Dan

Click here.

[DanChicago]

Thank you Peter!

[TA_Andy]

Hi Peter,

In your discussion "Calling Webhelp Using URLs", what does "path" below refer to?
Is it the full pathname of the folder that contains the help topic?

X:/helpfolder/startpage.htm#path/target_topic_1.htm

The reason I ask is that when I try to display a specific help topic in this way, I just get the default topic.

So for instance, in this example how much of the path is required between # and topic.htm?

C:/folder01/folder02/folder03/Help_Project/!SSL!/WebHelp/index.htm#topic.htm

Many thanks in advance.

Cheers,

Andy

[Peter Grainge]

It is the path from the startpage to the desired topic. Thus if it is in a folder one down from where the startpage is and that folder is called folderx, you would have

X:/helpfolder/startpage.htm#folderx/target_topic_1.htm

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[TA_Andy]

Thanks Peter.

The topic file and start page are in the same folder, thus no "path", but the result was the default topic.

So am I doing something wrong or does one have to disable the default topic in some way?

Cheers,

Andy

[Captiv8r]

Hi all

Hopefully Peter won't mind my offering Andy a tip here.

Andy, perhaps this will help.

The simplest way I've discovered to get that correct path is by doing this:

Generate your WebHelp and ensure the option for "Show navigation pane link in topics" is enabled.

Open a topic all on its own and note that you should see a link in the upper left that reads "Show". (Unless, of course, you intentionally changed it to read differently)

Click that link and the full frameset loads.

Note what the address bar contains. That will be the path you want.

Cheers... Rick

[TA_Andy]

Hi Rick,

Thanks for that.

I'm pretty sure I've got the path correct.

Maybe it has something to do with how I'm testing this.

I've been pasting the entire expression (eg "C:/folder01/folder02/folder03/Help_Project/!SSL!/WebHelp/index.htm#topic.htm") into the address bar in Windows Explorer to see if it manages to mimic a context sensitive help call. Perhaps that's what's confusing the issue here (ie Windows Explorer is ignoring the "#" parameter and just loading my start page into the browser).

Maybe I need to get the developer involved to actually test this properly.

If that proves to be the case, I'll report back.

Cheers,

Andy

[Captiv8r]

Hi again

I can't help but to notice that the file name is top ic.htm. Note the space. Is that truly the name of the topic? Or is it just an artifact of copying and pasting?

Maybe that's the issue.

Additionally, I'd be very hesitant to use the path you cited unless you can be absolutely certain the help will be installed in the same folder on all machines using it.

Cheers... Rick

[TA_Andy]

Hi Rick,

That path and topic name are fictitious - just to illustrate the issue.

Not sure how the space got in there.

Cheers,

Andy

[Peter Grainge]

You say you are pasting into Windows Explorer. Do you mean that rather than Internet Explorer?

In IE trying open the default topic, then add the rest in the browser address bar.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[TA_Andy]

Hi Peter,

Yes what I was doing was pasting the actual address into the address bar of Windows Explorer to simulate a help call from the software.

I probably can't publish the full scary real-world address because I'll doubtless get into trouble with the company IT police.

But it goes something like this:

C:/blah blah blah/!SSL!/WebHelp/index.htm#Using_the_Segmentation_Screen.htm

This quite happily launches the browser, but at the default topic, and not the "Using_the_Segmentation_Screen.htm" topic specified by the # parameter.

I thought this was a reasonable way of testing the theory rather than getting a developer to actually compile a version of his code to test the context sensitive webhelp approach.

I'll see if IE makes a difference (BTW my default browser is Chrome - perhaps that was throwing a spanner in the works). I'll report back...

Cheers,

Andy

[TA_Andy]

Hi Peter,

Me again.

Progress of sorts - yes it is a Chrome issue.

In IE, at first I get just the default topic + the prompt to allow scripts etc.

Upon allowing scripts - hey presto we jump to the # topic.

Damn & blast. Are you aware of a way around this in Chrome?

Cheers,

Andy

[Jeff_Coatsworth]

Only RH10 produces WebHelp that copes with the Chrome "security fix" issue - there's two ways around it - launching Chrome in a mode that allows you to look at local html files or faking it out with a virtual web server - instructions are on Peter's site - search for "Chrome"

[TA_Andy]

Hi Jeff,

Thanks for the comment. This isn't quite the usual Chrome issue per se.

I am using RH10 to generate this Webhelp - this issue now has to do with trying to make context sensitive calls into that Webhelp.

If you want to use urls in those calls, and therefore include '#' in the context help call - this is achievable with IE but if Chrome is the default browser I think it interprets that # as some kind of script and therefore disregards it.If I'm going to use Webhelp, I need this to work in Chrome as well as IE..

The challenge I now face is that we have previously elected to use locally deployed Webhelp for cross-platform compatibility (locally deployed as opposed to server-based Webhelp is not ideal I know). So what I need to understand is this - can one successfully create context links from a software app (non-browser based) into Webhelp? or should I use compiled CHM help instead?

Cheers,

Andy

[Jeff_Coatsworth]

Yes, it's possible - I do it by using Map IDs and what Rick states in post #6 with the "Show" label (which I renamed to "Contents/Search/Index" with a mouse-over tip of "Show Table of Contents, Search & Index buttons").

[TA_Andy]

Hi Everyone,

<confession>

   I'm afraid I have to raise my hand and confess to having been quite stupid.

</confession>

From Peter's article, this expression

X:/helpfolder/startpage.htm#path/target_topic_1.htm

does work.

What I was doing wrong was trying to kind of emulate a context help call by copying the expression into the address bar of Windows Explorer (ie not a browser) to see if it would handle launching the default browser and also call the specified topic.

However what I should have been doing is just pasting the expression straight into the browser address bar.

Sincere apologies everyone, and thanks to Willam van Weelden for an email reply of his that made me realise my mistake.

Cheers,

Andy

[Peter Grainge]

No worries, we've all done similar things. I did prod you in that direction in Post 9 in this thread.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge