This content has been marked as final. Show 36 replies
I have the similar problems. Does anyone have a solution to this?
maaf82 (Welcome to the forum!) and gimkrak,
Might be something with how the browser loads the index at runtime from its database, which has its own housekeeping index in one or more files, pointing to keywords and definitions in one or more separate files. Each click of an Index term triggers a navigation pane reload.
The key, I believe, is response time from the servers. If it's a little slow or intermittent while IE is loading and reloading Index segments, the browser breaks down.
To test this, generate WebHelp optimized for local (LAN) network and again, optimized for Internet (Web). One output package will have more files in the whxxxx directories, breaking the Index into smaller chunks.
If you find that IE runs better with LAN optimization than with WEB output, or vice versa, check Firefox and Netscape again.
If the optimization setting makes no difference, please post back. I can suggest some easy code fixes that may smoothe out navigation pane loading in your environment.
Thank you so much for your quick reply. But i tried to generate webhelp optimized for local PC or Intranet, and i still had the same problem. Is there anything else i can do to make this work?
I can get back to you next week.
Meanwhile, anyone who knows about this should jump right in.
Thanks Harvey. I look forward to hearing from you or anyone else that has a suggestion.
Hi Harvey, I just tried your suggestion for generating while optimized for local (LAN). Didn't seem to make any difference. Still seeing the same behavior in IE (crash following rapid sequence of clicks on index entries) vs. other browsers (tried Opera this time too, and like Firefox and Netscape it held up fine under the barrage of clicks). I'd very be interested in the info. you have about code fixes that improve nav pane behavior. Thanks for your help.
Based on errors in html syntax reported by a code checker, and
From research on what ails the WebHelp toolbar and navigation pane,
Code revisions I have made over the past two years in WebHelp output files are attached
An experienced js developer might say some don't accomplish anything, and I wouldn't
quibble. Over time, though, I've seen some real improvement for WebHelp in IE and other
Some of these files have templates in the RH directory:
Program Files/RH Office/RoboHELP/WebHelp5Ext
Where possible, I have patched the templates to get the head and body tags where they
belong. The really important ones are in the WebHelp output package.
Generally, these are fixes for Firefox, Netscape and Opera browsers because the
original output seems to work fine in Internet Explorer.
However, I think IE does notice some of these irregularities and takes just a little time to decide to ignore them. Most of the time you wouldn't notice. But if you are loading and reloading the Index (or Glossary, or TOC if they are long) several times in quick succession, and the browser just quits, maybe these patches will fix that.
I can't swear to the need for all of these changes. But they seem to do no harm either, so I haven't taken time to remove any for more testing. Those that seem most important are at the top. If I were to start from scratch for the Index, I'd try
Good luck, and please post back.
Results not guaranteed; back up everything; it works for me but I can't promise; yadayadayada.
I tried the code fixes that you suggested but it still didnt work. Everytime i made changes in the code and then published it, it would revert back to the intial code. IE is still crashing when i click items in the index. Do you or anyone else have any more suggestions? I will gladly try anything to make this work.
In your original post you said "I find that clicking quickly on 6-7 entries in a row causes the browser to shut down. I can click all day, slow or fast, in the same index using Netscape or Firefox, without incident. Any thoughts on a possible cause?"
The sarcastic answer would be "Yes, clicking 6-7 entries in a row causes the browser to shut down so don't click so quickly." :-) What hasn't been asked is whether the speed of clicking on one after the other is realistic. Is it just you testing something a user would never do or are you clicking at a truly representative rate?
Have you opened the help from another PC? Does that have the same problem?
The speed i can clicking in is the same speed anyone would use when clicking on items in the index. it is neither too fast or too slow. i did try opening the project on another computer and the same problem happened. i asked another person to test it on their computer and it still crashed.
Hi Harvey, thanks very much for your code fixes. On early testing, they seem to improve the speed of page loading. Sadly, like maaf82, I must report that the fixes don't seem to address the IE crash problem. As before, IE still crashes following a rapid series of clicks in the index list, while Netscape, Firefox, and Opera hang in there.
Hi Peter, thanks for your input on this. Good point. The IE crash behavior was originally noticed/reported by one of our QA testers (working on another PC). After reproducing the problem on my PC, and then being unable to change/correct it, I'm assuming that what I'm still seeing is what the QA tester would continue to see as well. But I will retest again myself on another PC. As for how 'real-world' likely the behavior is (users accessing index entries in a rapid sequence, causing the IE crash), I don't know. The thing that mainly bothers me is the diff. response of IE from the other browsers. In the case of other WebHelp browser-based issues I've had, non-IE browsers seem to be the ones acting up. This is the first time I can recall having a problem on IE and NOT having it anywhere else.
Until my QA group flags it as a major problem, I'm not going to consider it as one. But I would still like to find a solution for it.
You can break many programs by doing unrealistic things. Do your testers also pour coffee over the keyboard and then complain it doesn't work? To be more serious, this is not an oft repeated problem so I don't think you will get adverse reactions from real users.
There has to be a reason why you guys are having this problem, obviously. Harvey suggested server response time and that does look like a likely candidate. If you generate the help to your hard disk and then do the same things with the index, do you then have the same problem?
Peter, you're probably right about this not being an oft-repeated problem. At least in my case, the required stimulus is a series of rapid (almost spastic) clicks. However, sounds like maaf82 may experience the IE crash after more normal/common clicking on index entries.
Again, at least just in my case, server access doesn't seem to be involved. The QA tester who first pointed out the problem to me was accessing the Help over a server connection, but I am not. I'm accessing the Help on my hard drive.
I am generating the help from my hard disk and i had another person generate the help from their computer and IE still crashed on us. I am clicking at a normal speed and it still crashes.
Yes but are you generating an output TO your hard disk rather than the server that will ultimately be used. My thinking is that if the problem occurs only when the help is accessed from the server but not when you access an output on your hard disk, you have confirmed Harvey's suggestion that the network response times are kicking in.
Thanks gimkrak. That sort of rules out the thinking, at least in your case. I'll do some testing tomorrow on one of my projects.
Hi Peter and all
For what it's worth, I just now tried this with a fairly large project on my local drive. I'm not sure how fast "spastic" clicking would be, but I did try rapid clicking. Unfortunately I'm not able to replicate the problem either.
Like Peter, I also wondered why anyone would ever see the need to rapidly click through the index. I mean, normally one clicks an entry, pauses to at least skim what is on the topic page to the right, then possibly clicking another entry. I cannot fathom why (unless someone is intentionally trying to induce an issue or is testing) someone would ever have a need to rapidly click from link to link to link in the Index.
I agree that server response time is always an issue. RH has timeout/escapes in more than one location. Either they don't do what they're supposed to do, or WebHelp needs another timeout/escsape right here, or the problem is caused by the ones in the code now.
It stands to reason that anything we can do to eliminate an unnecessary chore will help the browser do its job faster. And that's better in all circumstances.
There is one more quirk that can slow down the nav pane (re)load.
By any chance, are you using a background image in the main toolbar -- repeat, main toolbar -- and do you see it repeating in the small toolbar (minibar) over the TOC/Index/Glossary?
By the way, maaf82, did you install all the patches, or did you decide one or more are unneeded?
I generated it from my hard disk and the sever, and it still crashes IE. If I select an item in the index and it displays the links related to it, and if i dont click on any of the links and click on the next item or any other item in the index it crashes. Once again i am doing this at a normal speed. I can click on an item and then select a related topic and keep doing this and it will not crash. but whenever i click on an item in the index and then click another item in the index and the related topics box remains open it crashes. Is there a way i can make this related topics box disappear soon, so it wont crash when selecting another item in the index without selecting a topic from the related topic box?
I am not using a background image in the main toolbar and i do not see it repeating in the small toolbar (minibar) over the TOC/Index/Glossary.
I have installed all the patches.
I am not using a background image in the main toolbar. In fact, I get the same error (IE crash immed following intensive index access) in WebHelp projects generated without a skin -- i.e., with the '(Traditional style - no skin)' option selected on the first page of the WebHelp compile wizard. And as with 'skinned' WebHelp projects, IE crashes but the other browsers do not.
I ran a test on a 12,000 topic merged webhelp project where every topic has at least one keyword. Nothing I could do would break it.
One last thought as I don't know what else to suggest, are your keywords stored in the HHK file or do you save them in the topics?
Peter, I save all my index keywords in the topics. Is that a possible cause of the problem?
I save all my index keywords in the topics.
Come in maaf82. Tell us that you do the same and maybe we are getting somewhere. I don't save my keywords in the topics so that is a key difference.
I wonder if RoboWizard's knowledge of the mechanics of the RH files can shed any light on this?
And therein lies the problem. I've done a fair amount of code spelunking with Skinned WebHelp files, but almost none with the basic non-skinned files. I do recall Tommy Simmons (a former MVP/Community Expert) did a lot of it in a file he used to share, but not sure if it's relevant any longer.
Just thinking out loud... Rick
Hi Rick, you were not hallucinating. ;> I did mention that the IE crash following intensive index access happens in my non-skinned WebHelp projects as well as in my skinned WebHelp projects. One thing that both types of projects have in common is, the keywords are stored in topic metadata instead of in the HHK file. Sounds like maaf82 does the same (stores keywords in topics) so maybe that's the common culprit.
i used the smart index wizard to build my index and eliminated the keywords i didnt want.
Just to be sure --
Your WebHelp index is the kind that displays only the keywords, right? If the term appears in only one topic, that topic opens; if two or more, you see a popup list of topics. Right?
It's not the kind that lists the index with A-B-C, etc. headlings by alphabet, with one or more links to the right of each index term for the topic(s) where the term is found, right?
I apologize in advance if your reaction is, "Yes, of course, whaddaya think I am? ....."
When you generate without a skin, which type of index appears?
Hi Harvey, yes, my generated index displays only keywords. I should add, though, that that's what I see testing on current browsers on my own PC. In testing on some older browser versions in our Lab, I do sometimes see my indexes display in the A-B-C format. That seems to happen only within older versions of non-IE browsers.
Whether I generate with or wthout a skin, I see the keyword-only type of index display on my PC. On PCs in our Lab, I've seen the A-B-C format in WebHelp projects generated without a skin. I've only just started generating WebHelp projects with a skin (in order to support context-sensitive topics), so as yet I have no testing data on how those indexes appear on other PCs and in older browser versions.
Yes my index displays only the keywords. If the term appears in only one topic, that topic opens; if two or more, I see a popup list of topics. If i click the next keyword without selecting a topic from the popup it tends to crash.
I only see the index with A-B-C, etc. when I dont right click on the Internet Explorer Information Bar and select Allow Blocked Content.
But i do have a skin applied to my project, and even if i dont have a skin it still displays only the keywords.
The older and non-IE browsers use a different set of files for loading the A-B-C version of the index. So I wanted to be sure we were looking at similar index structures.
I just made a copy of a 271-topic project heavy on tables, with file names like acppd_format_ name_keys and in-topic references to these files, so they show up as text as well as file names. The Index Wizard picked up about 8,000 keywords.
I did the index with a project setting for "Add keywords to" HHK and generated WebHelp.
Then I discarded the HHK file and set "Add keywords to" Topics, created an index and generated WebHelp to a separate directory.
The WebHelp output packages were substantially the same. The wizard picked up a few more keywords in the second pass, but this affected only a few output files. Their structure was the same, most counterpart files were the same, and the whxxx directories were only slightly larger the second time. They totaled just under 4 MB. Are your whxxx directories a lot bigger?
I put both versions up on a Dev sever and tried to make IE crash with rapid clicks in the Index. No crash.
Overall, the second WebHelp package was only a little bigger, at about 6.25 MB.
The only important difference was in the project folder. As I specified, Index terms were in the HHK file, or they were stored as Metadata in the source code (and only in the source files, not the output files).
So I'm grasping at straws now.
How big are your whxxx directories?
Do you have any file names or index terms with strange characters, aside from - hyphen and _ underscore? Spaces, of course, are OK in the index but not in file names. How many layers deep are your topics? An unusually long link path, including a really long file name, can cause trouble elsewhere. I don't know whether these issues are relevant to index loading.
One more thought.
Try to find a Web site built with RH, with a substantial Index. See if the browser quits there. If not, I'd look more closely at your server.
Hi Harvey, thanks for your diligent research. You've given me, for one, a lot to consider. I can say for now that the projects I've experienced this IE crash problem with have all been relatively small (200 topics or less), with index terms stored as metadata in the source code only, and with small whxxx directories (in the 95-topic project that intiated my query in this thread, the whxxx dirs are 111, 552, and 138 KB). I *used to* have 'R' trademark symbols on some index terms, but I took those out prior to my current round of testing. Nothing else seems strange, re: index or file names, topic levels, or path length. My last thing to try (but may not get to it till after Thanksgiving) is create a project index using only the HHK file. Thanks again for all your efforts. This is a very informative & helpful forum.
Thank you so much for your research. I have noticed that my file names have underscores and this is because i have spaces in it. Other than that i have not noticed anything different. my whxxx directory is 10mb. I did find a Web site built with RH, with a substantial Index and the browser did not quit. I will try to create an index using only the HHK file. I am not sure how to use it but i will research about it and try it.
Thank you once again for your research! I have learned so much about RoboHelp from this forum.