I met with the developer. There are several issues. This will
be simplified somewhat due to my limited coding ability (ummm, I
had Pascal in High School about 15 years ago - heh).
First, the RoboHelp CSH JS API appears to be broken. We are
using IE6, and in the JS API, there is a browser check. First it
checks to see if you are using IE4 or greater, and then another
check for other browsers. Since this company requires IE for use
with their application, the other browser checks are irrelevant to
us.
Now, the code for the IE check is intended to identify the
browser version, either IE4, IE5, or IE5.5 or greater. Our browser
is correctly identified as 5.5 or greater in the RoboHelp JS API.
By adding a warning message - some sort of alert syntax, iirc - we
were able to determine that for sure, the JS API does indeed
recognize the browser as IE5.5 or greater correctly.
After identification, the RoboHelp JS API then makes a call
to display the CSH topic.
If you have IE4, due to compatibility I would guess, the
RoboHelp JS API calls an iFrame to display the CSH.
If you have IE5 or 5.5 or greater, a JS command called
window.open is used instead.
To our surprise, the browser was being identified as IE5.5 or
greater, but the iFrame method was being called. This is the method
that contaminates browser history. WHY the iFrame does that, I do
not know. - one possible solution to the problem would be to find
some code that prevents the iFrame call from contaminating browser
history. I am not aware if this is possible or not.
This is where the RoboHelp JS API is broken. Where the JS API
decides what browser to use, all of the IE specific methods are
dependent on identifying the browser as IE4 or better first (vs.
some other browser). That's all fine and good, but the logic is set
up like this:
First it asks if the browser is IE4 or better, or some other
browser altogether. If it is IE4 or better, it sets the IE4 value
to True. Since the IE5.5 or greater value is buried beneath this
IE4 = True value, the API will never hit any method other than the
iFrame method, because in order for IE5.5 or greater to be True,
IE4 must be True (which identifies it as an IE vs Some Other
Browser), and if IE4 is True, then it uses the iFrame method.
Basically this logic is broken.
So we jimmied it - because someone else wrote it so it's time
consuming to fix, we rigged the code to jump to the window.open
method using a command like && !gbIE5 - which says only use
the IE4 method if IE4 is True and IE5 is FALSE. That made it skip
the IE4 method and jump down to the IE5 method.
Well, that worked, and our Browser History issue was fixed
(because it used the open.window command instead of the iFrame).
Unfortunately, there is some sort of additional window opening
before the CSH Help window comes up using the open.window method.
This additional window is filled with nothing, and does not close
after you close the Help window. Thus, it stays onscreen until you
close it manually. Here is the code that calls the CSH with the
open.window method.
if (gbIE5)
window.open("about:blank", "__webCshStub", sParam);
window.open(a_pszHelpFile, "__webCshStub");
And a picture of the window properties of this blank window
that ruins our "fix" of the API.
Link
to Screen of Blank Window Properties
So.... Anyone have any suggestions as to how to do one of
three things:
1. Make the iFrame window not contaminate browser history
2. Make the window.open command not open two windows to
display a single help CSH call.
3. Call CSH some other way using a JS command that does not
cause this kind of issue.
Seems like the API provided with RoboHelp should work a bit
better for WebHelp than it does now. Hopefully the new dev team
assigned to RoboHelp can fix this.
If you need any more info about this to help me, please let
me know.