Customers can't open .chm file, or topics don't display

[MC Hammer]

Ask our customers to lower their security settings? German customers are very sensitive about security ... and it sounded like at the company of MCHammer doing that is no problem.
Never mind - we don't have to find the cause.

Errrrrrr...not exactly. If you read my post, you will see that it was a colleague of mine who has had issues opening some of our help files. And German customers are not the only ones senstive about security

Also depends on what the settings were. There are at least fifty check boxes in that list, so custom alone does not mean much. Depending on OS there is no other option than to go custom...otherwise with the defaults you can't even download a file or view a page that has any scripting in it. Very secure, but also very useless.

Hmm, that is why for now, I am not keen on investigating any further. However I have to say I understand i-tietz's concerns. I am dreading the support call that will get fast tracked to me letting me know that some customer somehwere in the world cannot open our help files...

[RamonS]

Hmm, that is why for now, I am not keen on investigating any further. However I have to say I understand i-tietz's concerns. I am dreading the support call that will get fast tracked to me letting me know that some customer somehwere in the world cannot open our help files...

I yet have to come across a support request that complains about help, but that may just be different by industry. Almost all our customers have support contracts and it is much easier for them to call support than search the help.
Generally, unless the customer buys the system from the vendor it is up to the customer to provide an environment that will run the applications. That is why minimum requirements and technical bulletins need to be published. And if a customer complains about something, but does not agree that support finds the cause and fixes it, then all is lost. Support reps tend not to be mind readers and magicians.

[i-tietz]

Those customers who tell us all have a support contract ... and minimum requirements are not helpful in this respect, because that would allow to use the newest version of IE. And in our company the help is sometimes (mostly if it doesn't work) considered to be part of the software, means: They pass it on to the "producers" to analyze and fix it.
Apart from that I don't like to make myself redundant by saying that users don't need the help because they can always call the supoort ...

[MC Hammer]

We have a bug-tracking system that is also used to request enhancements and new features. This also covers help file bugs and improvements. Any help-related support case gets assigned to us. We do not get many help bugs, we get a few: typos, help out-of-date for a given functionality, request to clarify a particularly complex modelling feature. In the past, I have had a couple of requests to do with CHMs not displaying correctly and customers expected us to provide them with a solution. Certainly, our customers (at least the ones working for smaller companies where perhaps there is not a large IT department) see the help as a part of the software we produce and they expect it to work in the same way as they expect our software to work. This is just my experience (We have a large variety of customers worldwide and our software is mainly used by modellers and engineers, but also by control room operators and technicians).

[RamonS]

Those customers who tell us all have a support contract ... and minimum requirements are not helpful in this respect, because that would allow to use the newest version of IE. And in our company the help is sometimes (mostly if it doesn't work) considered to be part of the software, means: They pass it on to the "producers" to analyze and fix it.
Apart from that I don't like to make myself redundant by saying that users don't need the help because they can always call the supoort ...

That is why I mentioned technical bulletins, one of those would detail exactly which security permissions need to be set to have help work. That is a task for QA/devs to figure out and then for the TW to document. One could drop the "minimum" from the requirements. There are still tons of web apps out there that work only in IE6. For those cases "IE6 or higher" won't work.
I also did not suggest that customers rather call support, I was merely stating a fact based on my experience with our customers. We also offer the help as PDF manuals for download, which is another option to provide the content, although not the preferred one as it isn't tied to the app in any way.

[super-structure]

I ended up having a similar issue as originally described by heffevuna & planitDocs. I did attempt the solutions described by planitDocs and the only one that seemed to make a difference was to remove the XML declaration from the beginning of each topic. Sadly, this has to be done manually outside of Flare (post-processing).

I've put in a help request and it seems that this is indeed the issue. There apparently is some system setting which results in the HTML Help View not properly displaying anything beginning with an XML declaration. This may be some third-party software which associates itself with opening XML files or some security setting; MadCap tech support hasn't yet identified what exactly. It does appear that resetting IE to the defaults corrects the issue, but it may not always be easy to convince a user to do so (particularly, as previously stated by others, if they have higher than default security settings in place).

However, as removing the XML declaration does no harm to the HTML files in the compiled HTML help, I have requested that an option--similar to that available to remove the DOCTYPE declaration--be added for HTML Help targets. I've been told this has been passed on as a feature request. As this is (seemingly) something easy to implement, it could be added in a future update; particularly given the extra manual effort to clean these up is tedious.

But, for the sake of thoroughness, my process is this:
1) Build the HTML Help target in Flare normally
I don't know that the DOCTYPE declaration option has any affect on this issue, but it doesn't hurt to just leave it out as well.

2) Locate the temporary HTML Help project files:

Code: Select all

{Flare project location}/Output/{user name}/Temporary/(Flare project name}/Content/

3) Use RegexBuddy (or some similar bulk file search & replace tool) to comment out the XML declaration from each HTML file in the project

Code: Select all

<?xml version="1.0" encoding="Windows-1252"?>

(If you neglected to remove the DOCTYPE declaration, it can be removed in the same process)

4) Open _Temp.hpp in Microsoft HTML Help workshop and recompile. Redistribute the new CHM output from the same temp project folder.

[planitDocs]

I have now had another case where the user only sees empty pages and in this instance the DOCTYPE solution did not work, but removing the XML declaration did. Thank you Jason for sharing your workaround, I was wondering how to best implement this solution.

Let's hope we will soon get an option in Flare to remove the declaration. However, part of me would still like to know why this happens in the first place.

Interesting to hear that MadCap tech support seem to think that there is a system setting, which results in the HTML Help Viewer not properly displaying topics with an XML declaration. I mentioned my problem to a colleague who develops our online customer portal and he has experienced similar problems with customers only seeing empty pages. Apparently this was due to an XML parser error on their PC, which in turn was caused by a faulty MSXML installation. He tells me that a version of MSXML is installed on every PC and when you visit a web site or run an application that loads XHTML documents the machine refers to it. According to him there have been problems with Microsoft Winodws service packs messing up the installation so he solved his customers' problems by having them reinstall MSXML (http://support.microsoft.com/kb/973688). I might try this with my 'problem customers'.

Tina

[Telemarker]

I don't know if anyone has found this solution? We had similar problems when transferring chm files through Google Docs using zipped files, that was cured by this fix.

http://support.microsoft.com/kb/2021383

Another possible reason for this 'Navigation to the webpage was canceled' error is outlined in a LANSA Technical Note on Blocked Files. Although the technical note refers to Zip files, the same security block can occur when downloading CHM files. For more information, refer to the following Microsoft page regarding CHMs http://support.microsoft.com/kb/2021383

HTH