opening Help to a mapped ID from a webpage - skin and all

Report · Feb 09, 2012

I'm testing my way through a couple different options for doing this, courtesty of materials from Mr. W. VanWeelden and others. Here's the scenario: I want to open specific topics within a webhelp project via links from webpages (all pages will be on the same server. I want not just the topic, but the skin the webhelp project uses ... so that users experience the same Help file interface they are used to, from linking to it via the application toolbar.

I have mapped topics and output the help file. It looks like two different methods work.

JAVASCRIPT

<a href="javascript:RH_ShowHelp(0, '../WebHelp/welcome_to_worldox_gx3.htm', HH_HELP_CONTEXT, 4)">javascript link to topic 4

</a>

DIRECT

<a href="../WebHelp/welcome_to_worldox_gx3.htm?#<id=4>">direct link to topic 4

</a>

OR

<a href="../WebHelp/welcome_to_worldox_gx3.htm?#<id=4>>newwnd=false">direct link to topic 4

</a>

However, both methods get me to the right topic, but without skin. I have tried the "topicurl" option instruction in the Direct method, as Mr. VanWeelden's notes indicate that will load the skin:

<a href="../WebHelp/welcome_to_worldox_gx3.htm?#<../WebHelp/favorite_matters.htm>">direct link to topic 4

</a>

Doesn't work ... not even seeing the main topic.

Is the problem one of syntax, or something more fundamental ... as in having to create a window in the project just for such links? That would lead to two experiences of the same help file, which I don't want. Thanks so much in advance for your suggestions.

Michael D.

Report · Feb 09, 2012

Hi Michael,

Mr. Van Weelden... I feel real old now

For this, you want to use a window. Go to Project Set-up > Windows and create a new windows. (Make sure that WebHelp is set as your primary layout.) Select the Two pane layout. In your CSH call, include the window defintion you want to use.

Say that your window is called 'WithPane'. The correct calls would be:

<a href="javascript:RH_ShowHelp(0, '../WebHelp/welcome_to_worldox_gx3.htm>WithPane', HH_HELP_CONTEXT, 4)">
<a href="../WebHelp/welcome_to_worldox_gx3.htm?#<id=4>>wnd=WithPane">
<a href="../WebHelp/welcome_to_worldox_gx3.htm?#<id=4>>wnd=WithPane>>newwnd=false"> Note: To be able to use an window and use newwnd=false, you need to modify your output file. See www.wvanweelden.eu/robohelp/context_sensitivity_in_webhelp/methods_for_calling_Webhelp/regular_start_file#newwnd_bugfix for how to fix your output to allow window definitions and opening the help in the same window.

Alternatively, you can use the _csh startfile which will also display the skin. But this _csh startfile is only partially compatible with the new RoboHelp 9 Dynamic User Centric Content. So I'd advise you to only use this method if all else fails.

Greet,

Willam

Report · Feb 09, 2012

Can I call you William?? Will??

Thanks so much for your speedy reply. I'm in the process of playing with windows now. It sounds like this favored solution will enable a sort of parallel Help file experience - a different look and feel from the skinned version, but with access to the Navigation pane. Am I understanding correctly?

If that's true, it's workable, but not really ideal. I'm surprised that it's so hard to link down into a webhelp project and still show the skin. One alternative I'd consider is providing a button link to the main help file in the contextual help window, so that contextual help and the skinned help available from the application toolbar would be quite distinct. Not sure if that can be done.

Question on _csh startfile method ... I am using Robohelp 8 now. Does that make me a good candidate for using this? does it replace the RH_ShowHelp call?

Michael D.

Report · Feb 09, 2012

Haha, whatever you like. Most people say William even though the correct spelling is Willam without the extra i. If you're feeling very tired, I'll accept W as well

The window simply controls how the help is displayed. By default it always opens the help in a popup and the window controls whether the skin is visible and the window controls the size and location of the help. You can create multiple windows for different uses. Just call the correct window name in the call. It's the same help, but you can control the way it is presented to the user.

If that's true, it's workable, but not really ideal. I'm surprised that it's so hard to link down into a webhelp project and still show the skin. One alternative I'd consider is providing a button link to the main help file in the contextual help window, so that contextual help and the skinned help available from the application toolbar would be quite distinct. Not sure if that can be done.

Yes this can be done. For instance, you create two window definitions: One that shows the pane and one that hides the pane. To call the complete help, you can call the start file or use the window definition that will show the pane (Two pane layout). For the context sensitive help call, you call the same project, but you use the window that hides the pane (Single pane layout). That's all it takes.

Question on _csh startfile method ... I am using Robohelp 8 now. Does that make me a good candidate for using this? does it replace the RH_ShowHelp call?

The _csh startfile completely replaces the RH_ShowHelp call. The 'problem' with RoboHelp is using DUCC. The _csh startfile is still present than, but only for each content category, not in the main folder. It will still work in RoboHelp 9, but you may need to amend your call. That said, the _csh startfile is a legacy method, so you never know when Adobe will drop it. So using an API is always advisible so you can quickly amend the API when the call changes without having to modify the links themselves.

Personally, I don't like the default Adobe API because it's rather complex. For WebHelp (not WebHelp PRO!) I've created a simple custom API you can use for calling WebHelp. See: http://www.wvanweelden.eu/robohelp/webhelp_api/javascript

Greet,

willam

Report · Feb 09, 2012

Willam:

Thanks to your helpful explanations, I've gotten this working both as a direct link, and via the javascript method. It works perfectly in IE. Firefox won't allow popups period. (Tried it in safari also ... no luck with either type of link.).

So I moved along to your instructions on modifying whcsh_home.htm, to then be able to set an add'l option ">>newwnd=false". Where do I find that htm file to modify it? Is there any other way to end run around Firefox?

Thanks again.

Michael D.

Report · Feb 09, 2012

Hi,

whcsh_home.htm is in the root of your generated project. You can also modify the seed file in %RoboHelp install directory%\RoboHTML\WebHelp5Ext\template_csh

When you modify the seed file, you don't have to modify the output file every time you generate. Beware though! If you modify the seed file, first create a backup of the original file.

For FF and other browsers that block popups, the best way is to use the >>newwnd=false or use the _csh start file. Or you have to allow FF to open popups from the location of the help, but every user would need to allow that themselves.

Greet,

Willam

Report · Feb 09, 2012

Willam:

The whcsh_home.htm mod only affects the javascript call method of linking into the help file, yes? I did add ">>newwnd=false" to the direct links (not using RH_ShowHelp), and was able to use the links in Firefox.

Now that I'm thinking of it, is there any advantage to using the javascipt linking as opposed to direct links? FYI: These links will be from and to pages hosted on the same server ... no external links that I know of.

You have been tremendously helpful. I cannot thank you enough!!

Michael D.

Report · Feb 09, 2012

Hi,

The whcsh_home.htm modification only allows you to use >>newwnd=false in the CSH call. There's some code in there that always open a popup, even if you tell WebHelp to not open a popup. The modification has no other impact to the WebHelp system.

Now that I'm thinking of it, is there any advantage to using the javascipt linking as opposed to direct links?

Well, it depends on who you ask. If you ask me, the advantage is that the structure of the project is completely separate from the application if you use map numbers or topic id's. I did have a project that used URLs and it worked perfectly. The only downside was that my developers required all the CSH help files to be in the project root. Thus having several hundreds of files in the project root. When you use id's, it doesn't matter how you structure your help. That's the advantage, but there of course simple ways to just tell your developers the URLs they need to use and open the help by the URL.

Greet,

Willam

Report · Feb 09, 2012

Willam:

I may have to go with the direct URL approach, can't make the javascript call work without popping the window. I did modify the output whcsh_home.htm file as mentioned, though there is a discrepancy. In your illustration, you comment out lines 211 through 219, while in the instructions, you mention commenting out 211 through 220. I left line 220 active.

With that changed, I modified the test link which does work in IE, but not Firefox, since it pops the window. Here's that link before the change:

java link to DYK

After the change:

java link to DYK

I must be screwing up the syntax ... can't get it to recognize both window parameters. As written above, it doesn't work in either browser.

Which leaves the non javascript method; that should work fine even if I can't get the other one going. I am linking to map IDs rather than topic names even in this direct approach. As long as I don't change map IDs in the project, it should work.

Michael D.

Report · Feb 10, 2012

Hi,

Your links didn't come through. Can you post them using the browser? Replying by e-mail will scramble them.

You should leave document.location=sURL; active.

Greet,

Willam

Report · Feb 10, 2012

Just another note. I took another look at the code and devised an alternative method for modifying whcsh_home.htm. Just tested and it works better than the previous method. The previous method just ignored some window settings regardless of whether a popup was openend. This new method only ignores those settings when there is no popup:

Open whcsh_home.htm in a text editor or HTML editor.
Go to the function SwitchURL();
Find the second instance of if(gsWindow) on line 210 (RoboHelp 8).
Change the if statement if(gsWindow)to if(gsWindow && gsNewWnd == "true"):

else
{
  if(gsWindow && gsNewWnd == "true")//This line has been changed
  {
    var nTop=getSValue(oWnd.sBTop,screen.height);
    var nLeft=getSValue(oWnd.sBLeft,screen.width);
    var nWidth=getSValue(oWnd.sBWidth,screen.width);
    var nHeight=getSValue(oWnd.sBHeight,screen.height);
    window.resizeTo( nWidth , nHeight);
    window.moveTo(nLeft , nTop);
  }
  document.location=sURL;
}

Save changes and close whcsh_home.htm.

Report · Feb 10, 2012

Willam:

Good morning (over here anyway). Attached is a notepad file of my last email from yesterday. Thanks for that redo on the whcsh_home.htm. I'll try that out this AM.

Michael D.

Report · Feb 10, 2012

Hi,

The notepad file didn't come through. Unfortunately, the forum doesn't allow attachements. Can you post the content of the file in a new post?

Greet,

Willam

Report · Feb 10, 2012

Willam:

Certainly. Here is what I had written yesterday:

I may have to go with the direct URL approach, can't make the javascript call work

without popping the window. I did modify the output whcsh_home.htm file as mentioned,

though there is a discrepancy. In your illustration, you comment out lines 211 through 219, while in the instructions, you mention commenting out 211 through 220. I left line 220 active.

With that changed, I modified the test link which does work in IE, but not Firefox,

since it pops the window. Here's that link before the change:

<a href="javascript:RH_ShowHelp(0, '../WebHelp/welcome_to_worldox_gx3.htm>DYK2', HH_HELP_CONTEXT, 4)">java link to DYK</a>

After the change:

<a href="javascript:RH_ShowHelp(0, '../WebHelp/welcome_to_worldox_gx3.htm>DYK2>>newwnd=false', HH_HELP_CONTEXT, 4)">java link to DYK</a>

I must be screwing up the syntax ... can't get it to recognize both window parameters.

As written above, it doesn't work in either browser. Which leaves the non javascript method;

that should work fine even if I can't get the other one going. I am linking to map IDs

rather than topic names even in this direct approach. As long as I don't change map IDs

in the project, it should work.

Michael D.

Report · Feb 10, 2012

Ah, I see now. It's not your fault, it's the fault of the API you are using. The default Adobe API will always open the help in a new browser window. The >>newwnd=false will prevent the help from opening another popup, not the API from opening a popup. When you don't include the >>newwnd=false, the API will open a popup and the help will open a second popup and close the parent popup.

Best to drop the Adobe API and use URLs or a custom API. Sorry about not being clear on this.

Greet,

Willam

Report · Feb 10, 2012

Willam:

Interesting. The URL method works in Firefox and IE, so I should be good here. If I ever did want to use Javascript, where would I get a custom API? And how would I make that available to users? All these pages will be hosted ... would I have to load this custom API onto each calling page (page with the link into my help file), or save it locally and call it as a resource on those pages?

MD

Report · Feb 10, 2012

Hi,

Some example APIs: http://www.wvanweelden.eu/robohelp/webhelp_api But you can also create your own. URLs will also work fine in any browser. An API to create those URLs may save you work later on if Adobe decides to change the CSH call of WebHelp in an upcoming version of RH. You would then only need to amend the API instead of all the URLs.

For the JavaScript API, you just save the API on your server and make sure that every page on your site has a link to the API. Just like the default Adobe API. But the API is normally something that your developer will incorporate into the application. You can just use the custom APIs as an example so your developers kan create their own.

Greet,

Willam

Adobe Community

opening Help to a mapped ID from a webpage - skin and all