Webhelp opens in multiple browser windows

[Joseph_McMullen]

I am creating context-sensitive help for a software project. I provided the webhelp build to the engineering team and the online help is integrated into the product.

When the user clicks a help link from the software user interface, a web browser opens with the webhelp open to the desired topic, as expected. However, if this browser window is left open, and the user then clicks on a different help link, another browser window opens. The original browser window remains open at the original topic.

How can I specify that the same browser window should be re-used for additional context-senstive help topics?

I've tried out the _parent and _same arguments in the topic properties, thinking that this would solve the problem. Instead, the contents frame in the online help gets replaced with the same content as the topic window.

What do I need to do to fix this issue?

[RamonS]

When the new browser window is opened it needs to be assigned a name and that name needs to be used for any subsequent calls.

[Joseph_McMullen]

>When the new browser window is opened it needs to be assigned a name and that name needs to be used for any subsequent calls.

What is the procedure for assigning a name for the browser window so it can be used for subsequent calls? Is that controlled through Flare or from the HREF code in the software product? Can you provide an example of the code that assigns a name to the browser network?

[RamonS]

This is done through the URL call, either as straight HTML

Code: Select all

 <a href="http://www.yourwebserver.com/targetfile.htm" target="helpwindow">Help</a> 

or through JavaScript, see here:
http://www.w3schools.com/jsref/prop_win_name.asp

[NorthEast]

For WebHelp output, you can't just use any window name, the window name specifically has to be 'MCWebHelp'.

That's because when WebHelp is opened, it actually renames the window name to 'MCWebHelp'. So if you specify a different window name, any subsequent calls do not find your original window name, and the help will be opened in a new window each time.

You can use any window name for HTML5 output though, it doesn't have this same problem.

[lcvannarsdall35]

While use of the Anchor tag and JavaScript is possible when invoking HTML5 help from a web page (that is, from HTML), this approach is not feasible when invoking help from within a desktop application. Typically, all that a desktop application can do is pass a URL to a browser. In doing so, it cannot specify the browser window. Can you explain how a desktop application (written in C or C++ or Delphi) would resolve this problem with multiple browser windows?

[NorthEast]

You might get a reply here, but there's not many developers - I'd suggest searching somewhere like Stack Overflow.

Note that the 'MCWebHelp' restriction on the window name doesn't apply to HTML5 help, only WebHelp.

[RamonS]

While use of the Anchor tag and JavaScript is possible when invoking HTML5 help from a web page (that is, from HTML), this approach is not feasible when invoking help from within a desktop application. Typically, all that a desktop application can do is pass a URL to a browser. In doing so, it cannot specify the browser window. Can you explain how a desktop application (written in C or C++ or Delphi) would resolve this problem with multiple browser windows?

I spent some time looking for solutions online can cannot find anything. The only solution is either the js route or using the target attribute within the anchor, but that is not the same as passing through a parameter via URL. It would be up to the browser to process that extra URL parameter and act on it accordingly and there is no such thing.
The only solution I can think of is not to use a shell execute to the default browser, but stuff a browser control inside an app window. That should allow for targeting that window and the control inside. You basically need to embed a browser in your desktop application.