Wrapping WebHelp in a CHM to avoid IE warnings

[Guest]

Is this crazy enough to work, or just plain crazy? For various reasons, my manager wants a WebHelp project we can deliver to the user's PC. Problem is we don't want to deal with the yellow warning bar that IE throws up "Blocking active content." I recalled from another project that you can avoid security hassles when launching a Captivate animation by launching it from within a CHM, so I thought I'd try a similar technique with the WebHelp and it worked.

I created a very simple HTML Help project with no navigation. Then I listed all the output files from my WebHelp project in the HHP for the HTML Help project (different projects). Compile in MS HTML Help Workshop and Voila. Launch the CHM and you get a nice clean window with no IE menu, toolbars, or warnings, and all the WebHelp navigation works, including the search. At least so far. I haven't tested on Vista yet, just XP SP2.

So am I onto something here, or just on something? Is this a legit way to smoke the IE security popup, or will I get smoked when the thing fails to work on users' machines? Is this a triumph of inspiration, or just trivial and unstable? You get the idea. Any insights would be most appreciated.

Must be quitting time.

[RoboWizard]

Hi Tabfoxx and welcome to our community

Indeed it does seem like a good idea. I came up with it a couple of years back. As I recall, FlashHelp output worked just dandy this way, but WebHelp had an issue. The issue (at the time) seemed to be that the Index had issues and would refuse to load any topics I clicked on. At the time, I tried it in an effort to arrive at a "skinned CHM".

I suppose that it's entirely possible that:

1. I could have missed including one of the WebHelp output files in the mix, and this caused the Index not to work
or
2. The scripting for the index was faulty, thus resulting in failure for this configuration

And it's also possible that it failed to work for that particular version of WebHelp. I know there were a couple of versions that subsequently appeared since that initial test.

Actually, I had submitted the idea to Mike Hamilton. (at the time, Mike was Product Manager for RoboHelp) His interest was piqued enough that he tried to get some resources to work on creating this as a possible output type in RoboHelp.

The one big unknown with all this is how (or even IF) it would behave in a Context Sensitive (CSH) setup.

Cheers... Rick

[Peter Grainge]

Once upon a time webhelps and chms roamed the earth freely. They looked much the same and did much the same things but webhelps were more attractive as they had beautiful skins. Then bad men came along and they were known as hackers. Natural instincts took over and webhelps decided they would be safe as long as they didn't try to live in dwellings known as PCs. They could visit but they could not stay. The chms thought about this and decided they would survive better if they only lived in these dwellings. However, they had to pay a price for this protection. It was deemed that they had to continue to live without skins.

For a while this was OK but then some well meaning people wanted to allow webhelps to live in the dwellings and others wanted to give chms the freedom to roam to other PCs. It was thought by some people though that this was playing with nature and they became known as systems administrators. The well meaning people did find ways to do what they wanted but some of the systems administrators got very angry about this. They devised various punishments and sometimes they would not do business with these people ever again.

Tabfoxx: I have dressed this up as a story. Sometimes that helps management understand things better! Decide where you want the help to live and go with the format for that. You might find ways around the basic problem but who is to say the next Microsoft patch will not cripple those workrounds?

[CraigCC]

Tabfoxx,

I think that your expectations of online help are quite sane. Why not have one output that will work well on a server AND still perform on a well locally. It's been the bane of my life that we need to generate different outputs for different platforms and different purposes. Often it is the client the drives the platform and we cannot force them to ALWAYS use the files locally or indeed ONLY use the help files on the server. The particular problem for us is that many of the features that we use in a .chm do not work in the same way as they do in browser based help (shortcut controls and browse sequences are good examples). Sooooo we have the laborious task of creating two outputs to keep various clients happy. The product that causes me so much grief is a set of procedures, neatly wrapped up on a CD - some clients just download it and use it on their PC and some run it off a server as they do not want their staff downloading copies to each PC or have setups with very thin clients. We have not choice but to try and keep all of the people happy all of the time.

Anyway, enough of my problems Tabfoxx. First things first, why not submit this as an enhancement request for the next release of Robohelp - if enough people submit this issue (i.e. the errors webhelp generates when used locally), something may be done about it - you can download a questionnaire where you can submit your request and other feature that you'd like to see in the next release at http://www.hypertexas.com/. This is not an issue in flashhelp as pages where given the glorious mark of the web.

I'd also take on board Rick and Peter's valuable comments. Your fix may work, but make sure you test all the features that you will be using in the final version. Also as Peter says, perhaps you can approach you manager and try and convince him that the .chm is the way to go locally, at least for now while these problems persist.

Out of interest, why does your manager wants a WebHelp project to run on a user's PC?

Kind Regards
Craig

[Guest]

I want to thank all of you for the excellent feedback on this. Basically, we are creating a new documentation product that we hope will serve as a selling point or sales tool for the main product. That's why we are not happy with the staid look and feel of the old reliable(?) HTML Help. However, at the same time we are quite happily using HTML Help for our main user assistance.

As far as I can tell at this point, all features are working well in the "skinned CHM," including the index. We created the WebHelp with RoboHelp X5, so it is probably been improved upon since previous versions. Although another concern we have is Asian characters (we need to localize into Simplified Chinese, Japanese, and Korean). Because Asian language WebHelp would have to be generated with X3 (the last Asian-language capable release) this might be an issue. I'll have to test that pronto. (Although I am willing to try CHMerizing web apps created by other products as well.) As Rick points out, it is an open question as to whether you could get context sensitive APIs to work in this scenario, but fortunately for us, that's not an issue.

I think I will add my $ 0.02 to the RoboHelp feedback site. Actually, I think I probably have suggestions in a variety of areas. Probably comes closer to $2.00. TGIF again.

[Guest]

Oh, by the way, has anyone tried the Microsoft recommended solution of wrapping your web app in an HTA? Just came across this recently and it seems like a similar concept to wrapping in a CHM.

http://www.phdcc.com/xpsp2.htm

This site also talks about a "Mark of the Web" solution, but I'm not having much luck with that. -Greg