How to call webhelp from C#

[kkkwj]

I don't want to seem too simplistic, but I've spent at least 2 hours trying to call webelp files from c#, without any luck at all. All I ever get is three little beeps from my computer, and the IE browser never shows up at all. Here is some background information:

I read all the documentation, beginning to end.

(On WinHelp_4) I compiled up the CSH_CS (csharp version) project, and am able to call my simple RH WinHelp file (Dummy.chm) just fine, using a primary url of "c:\\Docs and Settings\\etc\\RoboHelp 6.0\\Dummy\\!SSL!\\WinHelp_4\\Dummy.hlp". A MapID = 1 is required in the CSH test dialog in order for my help file to load. This loads my help from the little CSH test dialog fine.

(On WebHelp) After getting the WinHelp_4 version to work, I switched the primary output to WebHelp in the SingleSource Layout section, and specified that RH should create a subdirectory (HTMLHelp) to store the WebHelp files. I regenerated the project, and successfully viewed the resulting web output using the View Results or the View Primary Layout on the RH toolbar. So I'm thinking my help files are ok. But..... I can't get the WebHelp to display from the CSH test dialog, no matter what I try.

Currently I am using roughly the same primary URL in the CSH c# project: "c:\\Docs and Settings\\etc\\RoboHelp 6.0\\Dummy\\HTMLHelp\\!SSL!\\WebHelp\\Dummy.htm". I do not append a window >main to end of the primary URL. It doesn't matter if I use a MapID of 1 or blank. It doesn't matter if I choose Context, Index, Search, etc. No matter what combination of things, the help file will not show. The file exists---if I double click the Dummy.htm file, the help file loads immediately in IE.

So my help files seem ok, and the CSH_CS code seems ok (at least it works with WinHelp_4). All I have changed is the path to my help file. (Oh, and I tried to point at an existing example *.htm in the RH Samples directory, with the same results---just a couple of little clicks from IE (presumably to say "There's an error somewhere").

Could anyone give me specific instructions on what I might try to solve the problem? I'd like to know the specific syntaxes for using windows, and MapIDs in my URL string too, if you know that. Here is what I think they are:

url = "Startpage.htm" - to load the whole help system
url = "Startpage.htm>main" - to display in a particular window
url = "Startpage.htm<id=2" - to display mapid 2

Thanks for your help

[Peter Grainge]

Welcome to the forum.

I can't help you on this one as it is outside my expertise. However, there is a topic on my site about calling webhelp using URLs and another topic about using map_ids which points to John Daigles article on this subject and another article. Perhaps they will help you.

http://www.grainge.org/pages/authoring/calling_webhelp/using_map_ids.htm

[kkkwj]

Thanks for the fast response Peter. Unfortunately for me, the articles you cite don't really help. (I did my homework searching forums and read both those sets of articles before posting here, in desperation.)

The articles mostly talk about calling RH from web pages (java and javascript), and not how to call RH from C# programs. They especially do not talk about how to call WebHelp from the Adobe CSH_CS example program.

(You would think that the Adobe CSH_CS demo program--being an example--should be showing all the "how do I call RH from C# in N different ways" in a perfectly clear manner). But the CSH_CS example program does not do a decent job of this at all, so I am having problems. (sigh)

[kkkwj]

I have made some progress (with no thanks to the Adobe CSH_CS program example, which I believe to be defective). I went to codeproject.com, and found an example that at least lets me load my help files. Here is a code summary.

SHDocVw.InternetExplorer ie = new InternetExplorer ();
SHDocVw.IWebBrowser2 browser = (IWebBrowser2) ie;
browser.Visible = true;

string foobar;
foobar = "C:\\..my pathname\\RoboHelp 6.0";
foobar += "\\Dummy\\HTMLHelp\\!SSL!\\WebHelp\\Dummy.htm";
object novalue = System.Reflection.Missing.Value;
browser.Navigate (foobar, ref novalue, ref novalue, ref novalue, ref novalue);

This code opens a new IE instance, and displays the top-level WebHelp system created by RH. It does not display any particular page, and of course does not go through the RH API (eg. "CRoboHelpAPI cHelp = new CRoboHelpAPI();") that provides Context,TOC,Index,Search options for loading the generated help system.

So at least I can display my help files from C# now. Now, back to the problem of how to get the C# RoboHelp API working...

[kkkwj · Accepted solution]

Well, another hour and a little more progress. Now I can display WebHelp from C# through the RoboHelpAPI (although it seems pointless, because of the bugs and problems in the CSH_CS example program and IE web browser popup window problems). First, here is the code that displays the WebHelp system (from the top level, in a standalone IE browser instance)

// try 2
int cmd = CRoboHelpAPI.CSH_DISPLAY_CONTEXT;
CRoboHelpAPI cHelp = new CRoboHelpAPI ();
int ID = 1; // context id; the number doesn't matter at all
string foobar;
foobar = "C:\\my pathname\\RoboHelp 6.0";
foobar += "\\Dummy\\HTMLHelp\\!SSL!\\WebHelp\\Dummy.htm";
string second = foobar;
cHelp.RH_AssociateOfflineHelp (foobar, second);
cHelp.RH_ShowHelp ((int) this.Handle, foobar, cmd, ID);
return;


From RoboHelp_CSH_CS.cs:
// reset the command
switch (nCommand) {
case CSH_DISPLAY_CONTEXT:
// notice that I commented this line out -- this is what allows it to "work"
// This is also why the ContextID number above doesn't matter--we ignore it.
//strHelpURL += "#<id=" + nData.ToString();
break;

From RoboHelp_CSH_CS.cs:

public static IWebBrowserApp
GetBrowser () {
for (int nIdx = 0; nIdx < 2; nIdx++) {
try {
if (m_cExplorer == null)
m_cExplorer = new InternetExplorer ();
if (m_cBrowser == null)
m_cBrowser = (IWebBrowserApp)m_cExplorer;
// I had to add this code myself, because the browser is not made
// visible by the Adobe CSH_CS.cs example program. A defect,
// in the example program, for sure.
==> m_cBrowser.Visible = true;


So to summarize, if you fix the CSH_CS example code (1) to make the browser visible, and (2) to ignore the contextID number, the code in this posting will show your WebHelp system in a new IE window, with the usual TOC frame on the left, and the topic window on the right, in a main window. But wait... there's more...

IE POPUP WINDOWS

The example above commented out some code under the case branch for CSH_DISPLAY_CONTEXT. The code appended some extra characters to the URL to tell the browser to display a specific page, rather than just the start page. Similarly, the code for CSH_DISPLAY_TOC/INDEX/SEARCH branches also appends characters to the URL, to tell the browser to display a specific page in the help system.

The problem with all of this is that IE treats all these single page displays as pop-up windows, and blocks them. So that's why in my original case at the top of this posting I only heard a couple of clicks (and saw nothing) when I tried to display my WebHelp. I saw nothing because the browser was not made visible by the code. I heard the two double clicks (click-click, click-click) because IE "plays a sound when a pop-up window is blocked".

So there will probably be a big policy collision on user desktops if your C# app tries to display specific web pages in WebHelp. If users want to block popups for general web surfing, they can't see specific WebHelp pages, and vice versa. Ugh.

One possible workaround is to tell IE to "Always display popups in separate tabs" (in Options/General/Tabs/Settings). I tried this setting, and then uncommented my CSH_DISPLAY_CONTEXT/etc code blocks. As expected, all the appended characters on the URLs forced the display of specific pages, which meant that IE treated them as popups, and forced them into new tabs.

So what you actually see is

(1) a new instance of IE becomes visible,

(2) the pathname to the help system (plus appended control characters) is shown on the first tab (in my case, file:///C:/Documents%20and%20Settings/kkkwj/My%20Documents/RoboHelp%206.0/Dummy/HTMLHelp/!SSL!/WebHelp/whcsh_home.htm#id=2). This is odd, because the primary URL I fed in to the API in the code above was "C:\\...path\\Dummy.htm" (with a ContextID = 2 parameter). I have no idea how my Dummy.htm was changed to whcsh_home.htm by the API. Go figure. I suppose the switch takes place if appended characters are found on the end of the URL, and the switch is done to support context IDs somehow.

(3) the desired page is displayed in a separate tab in IE.

My conclusions are that:

(1) Adobe should fix their examples to save people all this headache. They should fix the code, make the browser visible, and provide some nice documentation on what the secret syntaxes are for the appended characters (<id=, cmd=idx, cmd=fts, cmd=toc, <windowname), how and when you should use the secret syntaxes in the URLs you feed into the RH API, how the whcsh_home.htm switch works to support appended characters, what will happen on the user end with popups if you use appended characters, and the policy collisions that will result, and a recommended course of action for developers.

(2) The hassle with the popups just isn't worth it. So I will be calling my help system from the top level all the time, and will forego the utility of context sensitive help. It's WAY too much of a problem with WebHelp. (Of course, context sensitive help works great with the old WinHelp_4, but WinHelp_4 has other limitations.)

What a long process to debug all this stuff. Adobe fell way short on this one. But hopefully others can use my postings here in a time of need. (Thanks to Adobe for the forums, and for Peter's fast response.)

[Gleedo]

Thanks kkkwj

I have spent many hours trying to call winhelp from a c# winforms application.

After a fair amount of googling, i found this thread. Again, many thanks to kkkwj .

I have also been unable to get Context Sensitive Help working which is totaly ridiculous IMO.

Its help for god sake, not rocket science, yet ive spent more time looking at this, than actualy cutting code ;(

CSH is vital in our app and i guess i will have to look elsewhere for a help solution cause this is bonkers.