Discussion:
Rendering .chm files with the Windows Help Engine
(too old to reply)
David Webber
2008-10-31 18:43:05 UTC
Permalink
Am I right in thinking that, when I call HtmlHelp() to load a .chm file, the
HTML is rendered by the default browser on the computer?

[I am starting to think about putting more javascript in there, and it
appears that some things have to be done in a browser-dependent way.]

Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mozartists/mailinglist.htm
Pete Lees
2008-10-31 19:15:02 UTC
Permalink
Hi, Dave,
Post by David Webber
Am I right in thinking that, when I call HtmlHelp() to load a .chm file, the
HTML is rendered by the default browser on the computer?
No, it's only ever Internet Explorer, even if that isn't the default browser
on the computer. The topic pane of the HTML Help viewer is actually an
embedded IE window (it hosts the IE WebBrowser control, Shdocvw.dll).

Pete
David Webber
2008-10-31 23:46:18 UTC
Permalink
Post by Pete Lees
Post by David Webber
Am I right in thinking that, when I call HtmlHelp() to load a .chm file, the
HTML is rendered by the default browser on the computer?
No, it's only ever Internet Explorer, even if that isn't the default browser
on the computer. The topic pane of the HTML Help viewer is actually an
embedded IE window (it hosts the IE WebBrowser control, Shdocvw.dll).
That is what I *would* have thought except that...

Longish story:

Many years ago I bought the RoboHelp software for writing the old Winhelp
help files for Windows 3.1. I upgraded it several times, (costing an arm
and a leg each time) as it relied on a specific version of Word for editing
the files, and each new computer I got had a different version of Word. I
ended up with Robohelp 9.1 I think. Somewhere along the line I used its
converter module to produce me an HtmlHelp project and all the .htm files
for what was, by then, quite a large help system. (The html syntax was
poor by modern standards, but it compiled.) Its Htmlhelp module did not
rely on Word and that extended the life of the product for me a lot. But
I found it doesn't run on Vista.

It seems that something called RoboHelp is now produced by another company,
and either it's completely different or they started renumbering versions
form 1. I didn't find an upgrade path when I found it didn't run on
Vista. So these days I use FAR which is much friendlier on the pocket.
It is closer to what goes on under the bonnet, and is forcing me to learn a
bit more about HTML help - but that's no bad thing.

However I really treasure one thing from the Robohelp days: a javascript
module eHelpDhtm.js. It is enormous and I probably don't need most of it,
but one thing it does do *brillliantly*: pop-up windows with no frame or
buttons, which can display any HTML topic complete with text and graphics
(and has a shadow): just like the old Winhelp used to have. The pop-up
disappears when you click on the main window.

Recently I have been trying to figure out how it works (in order to get rid
of the parts I don't need) and am not even coming close. It is almost
entirely devoid of comments and it prints out at about 60 pages long! It
is absolutely jam packed with 'if"s, switching on which browser it finds,
and which version.

That's another thing I want rid of - these days I don't really have to test
for versions of IE earlier than 4 or Netscape earlier than 4. [I assume
that modern versions of "Mozilla" will have Navigator objects which register
the same as Netscape.] So I'm wondering why it is testing for non-IE
browsers. I guess the answer is that it was also designed to go on web
sites, (though as far as I knew it came specifically for compilation in .chm
files).

Anyway the two functions I use
(a) respond to onmousover= on a link and note the mouse position (in a
browser dependent way which allows for the scroll position)
(b) go with the href="javascript::...." and launch the pop-up (at the above
determined location)

but the latter calls a vast chain of functions - all with browser switches
all over the place. At least I know now that I can always follow the IE>=4
path!

But so far I can't even see how it opens a window with no frame, or where it
does it, let alone how it determines how big to make it! It may be a job
for a long winter evening (or seventeen), with my trusty javascript manual
to hand. Half of me says it ain't broke so I shouldn't try and fix it.
The other half wants to know *exactly* what is going on.

(I wonder - is there a way to step through javascript in .chm files with a
debugger????)

Anyway, long story, but that was why I asked.

Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mozartists/mailinglist.htm
Rob Chandler [MVP]
2008-11-01 13:33:52 UTC
Permalink
David
I've never found a good JS debugger. I've always just stuck with insterting
alert("Hello") popups. :-)
Rob
Post by David Webber
Post by Pete Lees
Post by David Webber
Am I right in thinking that, when I call HtmlHelp() to load a .chm file, the
HTML is rendered by the default browser on the computer?
No, it's only ever Internet Explorer, even if that isn't the default browser
on the computer. The topic pane of the HTML Help viewer is actually an
embedded IE window (it hosts the IE WebBrowser control, Shdocvw.dll).
That is what I *would* have thought except that...
Many years ago I bought the RoboHelp software for writing the old Winhelp
help files for Windows 3.1. I upgraded it several times, (costing an arm
and a leg each time) as it relied on a specific version of Word for
editing the files, and each new computer I got had a different version of
Word. I ended up with Robohelp 9.1 I think. Somewhere along the line I
used its converter module to produce me an HtmlHelp project and all the
.htm files for what was, by then, quite a large help system. (The html
syntax was poor by modern standards, but it compiled.) Its Htmlhelp
module did not rely on Word and that extended the life of the product for
me a lot. But I found it doesn't run on Vista.
It seems that something called RoboHelp is now produced by another
company, and either it's completely different or they started renumbering
versions form 1. I didn't find an upgrade path when I found it didn't
run on Vista. So these days I use FAR which is much friendlier on the
pocket. It is closer to what goes on under the bonnet, and is forcing me
to learn a bit more about HTML help - but that's no bad thing.
However I really treasure one thing from the Robohelp days: a javascript
module eHelpDhtm.js. It is enormous and I probably don't need most of
it, but one thing it does do *brillliantly*: pop-up windows with no frame
or buttons, which can display any HTML topic complete with text and
graphics (and has a shadow): just like the old Winhelp used to have. The
pop-up disappears when you click on the main window.
Recently I have been trying to figure out how it works (in order to get
rid of the parts I don't need) and am not even coming close. It is almost
entirely devoid of comments and it prints out at about 60 pages long!
It is absolutely jam packed with 'if"s, switching on which browser it
finds, and which version.
That's another thing I want rid of - these days I don't really have to
test for versions of IE earlier than 4 or Netscape earlier than 4. [I
assume that modern versions of "Mozilla" will have Navigator objects which
register the same as Netscape.] So I'm wondering why it is testing for
non-IE browsers. I guess the answer is that it was also designed to go
on web sites, (though as far as I knew it came specifically for
compilation in .chm files).
Anyway the two functions I use
(a) respond to onmousover= on a link and note the mouse position (in a
browser dependent way which allows for the scroll position)
(b) go with the href="javascript::...." and launch the pop-up (at the
above determined location)
but the latter calls a vast chain of functions - all with browser switches
all over the place. At least I know now that I can always follow the
IE>=4 path!
But so far I can't even see how it opens a window with no frame, or where
it does it, let alone how it determines how big to make it! It may be a
job for a long winter evening (or seventeen), with my trusty javascript
manual to hand. Half of me says it ain't broke so I shouldn't try and
fix it. The other half wants to know *exactly* what is going on.
(I wonder - is there a way to step through javascript in .chm files with a
debugger????)
Anyway, long story, but that was why I asked.
Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mozartists/mailinglist.htm
David Webber
2008-11-01 16:50:35 UTC
Permalink
Post by Rob Chandler [MVP]
I've never found a good JS debugger. I've always just stuck with insterting
alert("Hello") popups. :-)
Ah - thanks for another useful confirmation. The message box debugger!
That's what I do too - but I've never tried to follow anything through 60
pages worth of function calls :-)

I suppose I could start by inserting alert("Entering...") at the start of
each function. But it's a bit daunting and the weather is too nice for
the moment :-)

Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mozartists/mailinglist.htm
Rob Cavicchio
2008-11-02 17:31:18 UTC
Permalink
You might try running it in Firefox, where the error console gives far
superior feedback than any flavor of IE, IMO. That won't help for
IE-specific functionality, but it should help for common cross-browser
functionality.
Post by David Webber
Post by Rob Chandler [MVP]
I've never found a good JS debugger. I've always just stuck with insterting
alert("Hello") popups. :-)
Ah - thanks for another useful confirmation. The message box debugger!
That's what I do too - but I've never tried to follow anything through 60
pages worth of function calls :-)
I suppose I could start by inserting alert("Entering...") at the start
of each function. But it's a bit daunting and the weather is too nice
for the moment :-)
Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mozartists/mailinglist.htm
David Webber
2008-11-03 09:30:30 UTC
Permalink
Post by Rob Cavicchio
You might try running it in Firefox, where the error console gives far
superior feedback than any flavor of IE, IMO. That won't help for
IE-specific functionality, but it should help for common cross-browser
functionality.
Funny you should say that: I was just mulling over how to go through it
using alert boxes and decided that *outside* the .chm environment would be a
good first step, and in that case I realised I could easily test the browser
dependence. I have both IE and FireFox installed and have been meaning to
test Google's latest offering.

All I need to do is find the time! The "ain't broke; don't fix it" mantra
is still nagging at me insidiously :-)

[Though I did have to fix it, very slightly, to make it work with IE7 and,
who knows, I may have to do it again when IE8 arrives. I'm sure all this
browser-dependent programming must be bad style!]

Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mozartists/mailinglist.htm
Rob Cavicchio
2008-11-04 01:41:05 UTC
Permalink
Post by David Webber
[Though I did have to fix it, very slightly, to make it work with IE7 and,
who knows, I may have to do it again when IE8 arrives. I'm sure all
this browser-dependent programming must be bad style!]
In rare cases, it's necessary (making transparent PNG files work in IE 6
comes to mind). But you're right; in most cases it's just poor programming.

There are a few cases where context-dependent programming is warranted,
particularly within CHM files. Usually that just involves fixing up URLs to
point to the right place.


********************
Rob Cavicchio
***@mvps.org
David Webber
2008-11-04 15:57:37 UTC
Permalink
Post by Rob Cavicchio
Post by David Webber
[Though I did have to fix it, very slightly, to make it work with IE7
and, who knows, I may have to do it again when IE8 arrives. I'm sure
all this browser-dependent programming must be bad style!]
In rare cases, it's necessary (making transparent PNG files work in IE 6
comes to mind). But you're right; in most cases it's just poor
programming.
There are a few cases where context-dependent programming is warranted,
particularly within CHM files. Usually that just involves fixing up URLs
to point to the right place.
I have started to explore the method for producing the pop-ups. It turns
out that the really nice frameless windows (invoked under IE>=4 on a Windows
machine only) are not windows at all. Rather they are essentially a <div>
containing an <iframe> cunningly inserted into the original document (with
z-index=600!) using the body object's insertAdjacentHTML() method.

I haven't yet worked out why this shouldn't be possible under non-IE
browsers, (or indeed under IE on a MAC) but it does go down a completely
different path for these. Still, in the first instance I'm restricting
myself to chm on a windows machine (with XP as the oldest platform) and so I
should be able to produce some *much* simpler javascript using the same
method.

[Having gone down with the 'flu, inserting alerts in complicated javascript
and plotting the path through it is about the most intellectual effort I'm
capable of at the moment, but it actually feels quite productive in terms of
learning!] :-)

Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mozartists/mailinglist.htm
Rob Cavicchio
2008-11-05 04:46:25 UTC
Permalink
"insertAdjacentHTML" is a Microsoft invention. You probably want to use some
combination of "createElement" and either "appendChild" or "insertBefore".
These do work in other browsers; I've used them many times.

The DOM spec is available at:

http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001
Post by David Webber
Post by Rob Cavicchio
Post by David Webber
[Though I did have to fix it, very slightly, to make it work with IE7
and, who knows, I may have to do it again when IE8 arrives. I'm sure
all this browser-dependent programming must be bad style!]
In rare cases, it's necessary (making transparent PNG files work in IE 6
comes to mind). But you're right; in most cases it's just poor programming.
There are a few cases where context-dependent programming is warranted,
particularly within CHM files. Usually that just involves fixing up URLs
to point to the right place.
I have started to explore the method for producing the pop-ups. It turns
out that the really nice frameless windows (invoked under IE>=4 on a
Windows machine only) are not windows at all. Rather they are
essentially a <div> containing an <iframe> cunningly inserted into the
original document (with z-index=600!) using the body object's
insertAdjacentHTML() method.
I haven't yet worked out why this shouldn't be possible under non-IE
browsers, (or indeed under IE on a MAC) but it does go down a completely
different path for these. Still, in the first instance I'm
restricting myself to chm on a windows machine (with XP as the oldest
platform) and so I should be able to produce some *much* simpler
javascript using the same method.
[Having gone down with the 'flu, inserting alerts in complicated
javascript and plotting the path through it is about the most intellectual
effort I'm capable of at the moment, but it actually feels quite
productive in terms of learning!] :-)
Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mozartists/mailinglist.htm
David Webber
2008-11-05 15:58:51 UTC
Permalink
Post by Rob Cavicchio
"insertAdjacentHTML" is a Microsoft invention. You probably want to use
some combination of "createElement" and either "appendChild" or
"insertBefore". These do work in other browsers; I've used them many
times.
http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001
Thanks Rob,

That would explain why the method doesn't work in FireFox.

My javascript bible is the O'Reilly guide by David Flannagan (5th edition).
It does warn about browser-dependence and describe it - but I do need to get
more conversant with it.

Apart from that, the javascript I'm looking at is ca2000 vintage, and my
impression is that the browsers have converged a bit since then. Maybe IE7
handles the official w3c DOM better than IE4 did. Thanks for the link.

Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mozartists/mailinglist.htm
Pete Lees
2008-11-02 12:35:00 UTC
Permalink
Hi, Dave,
I ended up with Robohelp 9.1 I think ... It seems that something called RoboHelp
is now produced by another company, and either it's completely different or they
started renumbering versions form 1.
Yes, that's right. RoboHelp started out as a product of Blue Sky
Corporation, I believe, and then passed through a number of hands before
being absorbed into the Adobe range of products. The current version of
RoboHelp (7) is logically version 15 or thereabouts.
However I really treasure one thing from the Robohelp days: a javascript
module eHelpDhtm.js. It is enormous and I probably don't need most of it
To confirm what you say a little later in your message, I think this file is
also used in RoboHelp's WebHelp output, which is an uncompiled, cross-browser
format. So this would explain why it tries to accommodate all Web browsers in
some of its functions.
one thing it does do *brillliantly*: pop-up windows with no frame or
buttons, which can display any HTML topic complete with text and graphics
(and has a shadow): just like the old Winhelp used to have. The pop-up
disappears when you click on the main window.
You can achieve the same effect (but without the shadow) by using a
third-party ActiveX control, KeyHelp. It's available from this page:

http://www.keyworks.net/keyhelp.htm

KeyHelp was created by Ralph Walden, formerly Microsoft's chief developer of
both WinHelp and HTML Help, after he retired from Microsoft. The only
downside that I can see to using KeyHelp is that you have to install and
register it on all your users' computers.

There a few other ways to create feature-rich pop-ups, as illustrated in the
HelpTips file available from this page:

http://www.simon-jones.org.uk/help.htm

Pete
David Webber
2008-11-03 09:44:29 UTC
Permalink
Post by Pete Lees
I ended up with Robohelp 9.1 I think ... It seems that something called RoboHelp
is now produced by another company, and either it's completely different or they
started renumbering versions form 1.
Yes, that's right. RoboHelp started out as a product of Blue Sky
Corporation, I believe, and then passed through a number of hands before
being absorbed into the Adobe range of products. The current version of
RoboHelp (7) is logically version 15 or thereabouts.
Ok, that sounds right. Thanks.
Post by Pete Lees
However I really treasure one thing from the Robohelp days: a javascript
module eHelpDhtm.js. It is enormous and I probably don't need most of it
To confirm what you say a little later in your message, I think this file is
also used in RoboHelp's WebHelp output, which is an uncompiled, cross-browser
format. So this would explain why it tries to accommodate all Web browsers in
some of its functions.
Aha!
Post by Pete Lees
one thing it does do *brillliantly*: pop-up windows with no frame or
buttons, which can display any HTML topic complete with text and graphics
(and has a shadow): just like the old Winhelp used to have. The pop-up
disappears when you click on the main window.
You can achieve the same effect (but without the shadow) by using a
http://www.keyworks.net/keyhelp.htm
I found that when googling for alternatives but....
Post by Pete Lees
KeyHelp was created by Ralph Walden, formerly Microsoft's chief developer of
both WinHelp and HTML Help, after he retired from Microsoft. The only
downside that I can see to using KeyHelp is that you have to install and
register it on all your users' computers.
...I didn't realise its pedigree. That makes it more tempting, though I
did balk at having to install/register the thing on users' computers.
I'll keep that as an option if my exploration of the Robohelp method comes
unstuck.
Post by Pete Lees
There a few other ways to create feature-rich pop-ups, as illustrated in the
http://www.simon-jones.org.uk/help.htm
I got that from a previous recommendation (the HelpWare site?) and
downloaded HelpTips.zip - but it seems to be broken: my Windows unzipper
tells me it is "invalid". Tried again; same problem. I have sent a short
e-mail to Simon.

Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mozartists/mailinglist.htm
Loading...