Context Sensitive Help in main window and suppress Popup Window

[brcbuzz]

Hi, I am a developer and not the person in our organization that creates the WebHelp files so I do not know anything about setting up the RoboHelp project and MapID's for context sensitive help.  With that said, our application requires context sensitive help.  Currently RoboHelp is creating the javascript to open the  context sensitive help in a popup window.  I was able to modify the javascript code manually to open the context sensitive help in the "main" window and not in a popup.  My concern is that the javascript in the htm file will get overwritten when a new build of the WebHelp files are created.  Does anyone know how to set a property or some project variable in RoboHelp so it will create the appropriate javascript code to NOT open the context sensitive help in a popup window?

I appreciate any help.

[Peter Grainge]

I am not a developer but I don't think that's the right approach. You should be able to open the tri-pane window with the required CSH topic.

Doing it with URLs is definitely described on my site. See Calling WebHelp. There are links and other topics about different ways of calling help, maybe one of those will help.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[brcbuzz]

I looked on your site but didn't find anything that helped me.  I don't think it is how WebHelp is called since basically the source code is just opening an instance of Internet Explorer and using the Navigate method passing the URL.  The URL is basically a UNC path to the server/folder location of the help files with the start .htm file and an MapID appened to the end of the URL.  The javasript within the .htm file is opening another window for the context sensitive mapID's.  So it seems to me that this is being done when RoboHelp is compiling the help files.

Thanks

[perttime]

Using a URL seems to be the most common and least painful way to open the WebHelp Context-sensitively from the Application.

Call something like this:

file:///path_to_the_help/start_page.htm#the_page_you_want.htm

So the context sensitivity actually comes from the Application making a correct call to the help page you want. The help just dumbly obeys.

For me, it seems to work perfectly in IE, Firefox, Safari and Opera.

(Generating helps with RH7.02)

[Willam_van_Weelden]

Hi,

Speaking of the devil, I've had this discussion in my company last week. Should we use MapId, TopicId, URL's? How do we set it up? We don't want a popup,we want the help to open in the main window. You can imagine

As always, different departments have different approaches to calling the help. Therefore I created a start file.

You can feed it both MapId's and TopicId's. You developer simply calls the file with an url parameter id (example.htm?id=myid) and the script launches the help in the main browser window. No popups. Both MapId's and TopicId's work for single projects and merged webhelp. (Tested on RH7/8) It works for local help and online help.

If you are interested, please PM me with you email address and I'll send you the file.

@perttime: In my opinion using url's is a very painfull way of calling the help. If you want to change a filename or reorder someone's project, the context sensitivity has to be edited in the program. I haven't met any developers that are happy any time they have to change the help call.

Greet,

Willam

[perttime]

I don't recall ever having renamed a topic file or reordered a project, so haven't run into those issues with context sensitivity... totally change topic content, yes.

[MergeThis]

Willam, we handle the URL call a bit differently in our merged WebHelp environment, not involving developers beyond their initial naming of the form.

Their call looks to the form_path.txt file at the root, which lists the folder(project) name where to find the topic. If the topic file name duplicates the form name, only the folder name is provided. If the file name does not duplicate the form name, that file name is also provided. For example:

FormName, mergedProjects\projectfolder

FormName, mergedProjects\projectfolder\other_file_name.htm

Good luck,

Leon

[Willam_van_Weelden]

Hi Leon,

Your solutions makes sense to me. The problem I've mostly encountered is that the context is completely handled in the program. I've had a few legacy projects which desperately needed to be redesigned and that also meant changing the call in the program. My point is that the help should be independent of the program. If something changes in the help, the program should not be changed. As you say, you can do that by URL's or Id's alike.

Greet,

Willam

[MergeThis]

The other thing I forgot to mention, is that our developers coded the keyboard shortcut Ctrl+Shift+F1 to produce a message box that contains the form name (a pseudo-What'sThis functionality). So, we can easily discover why an F1 call is no longer working, and can simply map the form/topic without resorting to begging the developers for assistance.

Good luck,

Leon

[ktel_1888]

I am experiencing a similar issue and I hope someone can help me determine the last few steps I need to take before I can take my Help files live.

I've made some progress with my context-sensitive help, in that I'm able to get it to open in a popup window with TOC displaying the right page.

My code for this is:

myserverroot/index.htm#<str=map_ID>>

I've been reading the following site and it broke down the API into easy to follow chunks:
http://www.wvanweelden.eu/robohelp/context_sensitivity_in_webhelp/methods_for_calling_Webhelp/regula...

Given the methods described here, I should be able to have my context-sensitive guide open up in my main browser window rather than a popup by utilizing the following string:

myserverroot/index.htm#<str=map_ID>>newwnd=false

However, when I run my tests, the UG still opens in a new popup window.

How can I fix my code so that it displays in my main browser window with the TOC rather than a popup window?