Getting CSH WebHelp to Reuse Target Window

[milewski]

We are using CSH with WebHelp. We have a target set for the WebHelp window from inside the application. Initially, the CSH starts to open in the target window, but when the frameset is applied, it appears to NOT use the existing target name when it refreshes.

The problem occurs if a user navigates to another position in the application and clicks Help again. Rather than opening Help in the window that already has a help topic loaded, it opens another window. Now the user has multiple version of Help open at the same time.

I thought I would ask if someone already knew the answer before I went poking around the Flare scripts myself.

[TheGreatAndPowerfulOz]

We have just begun an attempt to integrate our WebHelp output with a new web application our developers are writing using Silverlight. We hare having the exact same issue!

One of the developers is experimenting with opening a new browser instance via some JavaScript code which holds a frameset. The application will pass the Help topic ID to a hidden frame in the frameset (that always has a particular "window.name"/"target" name), which will in turn send the appropriate URL to a visible frame in the set, displaying the desired Help topic. When a user goes to a different area of the application and clicks "Help" again, a new topic ID is passed to the hidden frame (still has the same "target" name, so in theory a new browser instance won't be opened), and the new Help topic will appear in the visible frame.

We still haven't proven this method out, and it's admittedly a bit of a kludge, but we're hoping for the best!

Does anyone else out there know how to handle this situation "out of the box", without having to resort to employing such workarounds?

[RamonS]

Usually, you can call a URL by specifying a window name. If you send subsequent calls using the same window name it will display it in the same window if it exists.
You need to craft a link that basically looks like this:
<a href="somewhere.html" target="otherwindow">Click Here</a>
But, you may want to dig a bit further to make sure that you really talk to a window and not a tab. The tabbing feature puts a new twist on the whole thing.

[TheGreatAndPowerfulOz]

Usually, you can call a URL by specifying a window name. If you send subsequent calls using the same window name it will display it in the same window if it exists.
You need to craft a link that basically looks like this:
<a href="somewhere.html" target="otherwindow">Click Here</a>
But, you may want to dig a bit further to make sure that you really talk to a window and not a tab. The tabbing feature puts a new twist on the whole thing.

Tried this, but it seems that the frameset created in WebHelp output is somehow altering the window.name attribute, such that subsequent calls to the same target *don't find* the target so named, and thus open a new instance of the browser.

[RamonS]

That rapidly inhales.

[jlockard]

We recently had the same issue: We were calling the help using a target="mywin" setting and seeing multiple tabs/windows appear--one for each time the help link was clicked. Our expectation was that each help link, pointing to the same target="mywin", would reload the help topic requested in the existing help window/tab rather than spawning a new window/tab each time.

After doing a lot of research and testing, we ended up calling tech support. I don't believe this issue is answered anywhere else in the forums, but here it is:

Flare's webhelp output dumps any window handle assigned with the target= setting and uses "MCWebHelp" instead. So by simply changing the target= value to target="MCWebHelp" you can get your webhelp to consistently use the same window.

Hope this helps others resolve their issues more quickly than I was able to resolve mine. (That said, MadCap's tech support was excellent, timely, and thorough.)

[bobmoon]

Thanks for posting this! I was just starting to wrestle with the question.

Bob

[RamonS]

Flare's webhelp output dumps any window handle assigned with the target= setting and uses "MCWebHelp" instead. So by simply changing the target= value to target="MCWebHelp" you can get your webhelp to consistently use the same window.

Which solves the problem when one uses only one window. If for whatever reason one needs more than one it will not work. I can't think of any reasonable use for more than one help window, but this behavior is clearly inside of the the bug territory.

[bobmoon]

...this behavior is clearly inside of the the bug territory.

I agree, and just submitted a bug report. I think it also warrants a KB article, since the restriction isn't documented in the Flare help, as far as I could find. The code examples in the help do use target="MCWebHelp", but nothing states that it is required.

Bob

[pe_thiemann]

Hi David,
one possible use case for this problem is that 2 different helps running on the same machine or web server suddenly use the same target window. Then it must be possible, to rename the window other wise one help overwrites the other in the help window, as it is the case for our customers products.
You have to use the target property, otherwise the help is opened in the application window. So the target is mandatory and the value cannot be changed.
This is definitively a bug, a major one for our customer!!

[Andrew]

You should be able to change whatever code makes the target require MCWebHelp. Of course, you'd have to change it with every output, which is rather annoying, but it may get you by until (if?) MadCap fixes this.

[NorthEast]

I had this problem too, thanks for the info.

It still hasn't been fixed; I've submitted a bug report.

[JohnB]

Hi -

We reuse two Help displays in some WebHelp projects. One is a full-blown frame set and another is a pseudo pop-up, which we design using skins. As already mentioned, target="MCWebHelp" works. For maintaining/reusing a second window, we specify target="_MCWebHelpCSH" in the Help calls associated with the pseudo pop-up skin. So, if you want to do something like this, it can be done.

I think I entered an enhancement request at some point to allow defining named windows in a Help project, which you could then 'target' in the CSH Help calls. So, you wouldn't be tied to "McWebHelp". Earlier versions of the RoboHelp Server API supported this. (They broke it with version 8, not sure if they ever fixed it.)

- John