How to call webhelp from C#

Question

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

Answer 1

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.)