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

[heffevuna]

Some of our customers are not able to open the .chm file I created with Flare, even though they could open previous versions I created with RoboHelp. And a few can open the file, but the topic content does not display.

I I've read up on this online and it seems that in the past it could be due to Windows configuration and security settings. However, I'm wondering if it's possible to do anything on my end, or if there is a problem with the way I'm authoring the file.

Any insight would be most welcome.

Thank you!

[RamonS]

If it is indeed a security settings issue then there isn't much you can do other than potentially removing any JavaScript. By any chance, do the users access the help from a network share? If yes, then this is the main cause for the problem. Since quite a while the CHM viewer no longer allows for that (unless you hack the registry and enable it again). This is due to a security issue and Microsoft figured that disabling that feature was easier than fixing it.

[NorthEast]

As RamonS said, a very common cause is that the file is being opened from a shared network folder.

Another thing that may cause issues is if you've sent the CHM to someone via email. We've had problems before when someone had received a CHM sent via Outlook email and saved it locally, as it seemed to block the file on that person's PC. To get round this, we now zip CHM files before we email them.

[planitDocs]

I am experiencing the same problem as Linda, or rather one of our users is.

He can open the CHM file (Index and TOC display okay) but the actual topic pane is empty. Literally empty, no error message. He has no problem viewing the handful of legacy files that were compiled with RoboHelp. It's just the Flare ones that go wrong.
And no, he is not looking at the file over the network or shared drive. The CHM files are sitting on his local drive.

We have tested the same CHM files with several other people and they have no problem. They have all installed from the same master version (incuding the guy who cannot see the topics) , so I am thinking that it must be a setting on his PC. Could it be an XML releated setting he needs to enable or are there any background files the Flare display depends on that he may not have on his machine?

So far it's only one user who has complained (software with the new help files was only released yesterday) but it would be good to find out if there is anything we can do about it in case we get more complaints.

Thanks.
Tina

[i-tietz]

I thought our customer is a fairly exotic case, but this could be another occurrence of
http://forums.madcapsoftware.com/viewto ... 13&t=13974
or
http://forums.madcapsoftware.com/viewto ... 94&p=76697

Looks like MC has to do a bit more research on why those things happen ...

[planitDocs]

I am currently thinking that this in a xhtml problem, but this is really just a shot in the dark. I am thinking this because the legacy RoboHelp files are compiled on an old version (i.e. they are html) whereas the Flare files that go wrong are xhtml.

In my Net search I came across a couple of postings regarding IE 8's inability to interpret xhtml. Unfortunately, for my problem of empty pages this is a red herring. I tested the CHM files on IE8 on one of my machines and they display fine.

Have you explored this at all? Your customer who sees the code page instead of the properly rendered topic, is he using IE8?

Tina

[i-tietz]

I'm not the one communicating with the customer. Windows 7, 32bit - that's all I know.

[planitDocs]

With a little help from MadCap support (thank you Jose!) I found a workaround for this problem (although it would still be good to know which settings/situations on the user's PC causes it in the first place).

Below are the three suggested solutions, and how they worked for us.

1. Browser problem. Solution: Reset the user's default browser back IE. This did not work for us. We even made the poor guy uninstall the browser and then reinstall IE9 - still no luck but I guess it's worth a try.

2. XML declaration in the topic files causing problem. Solution: Manually stripping these out of the compiled .chm topics. This did work but I am struggling to see how I could make this work when shipping our help files.

3. DOCTYPE declaration in CHM output causing the problem. Solution: Generate the .chm output with the DOCTYPE declaration removed (this is an option under the Advanced tab of the HTML Target that you can uncheck.) This did also work and at the moment seems to be the best solution for us.

Hope this helps.
Tina

[i-tietz]

3. DOCTYPE declaration in CHM output causing the problem. Solution: Generate the .chm output with the DOCTYPE declaration removed (this is an option under the Advanced tab of the HTML Target that you can uncheck.) This did also work and at the moment seems to be the best solution for us.

Sigh ... we don't have this checkbox checked anyway ...

I might try producing a help without the XHTML declaration and have it sent to the customer ... we'll see how that works.

[MC Hammer]

One of my colleagues (same OS as me - Windows 7, 64-bit, IE8) is experiencing the same problem. He either gets an empty topic pane or a topic pane with some raw code in it. Everything works fine for me on my PC, for the same help files.
We tried solution 1 and 3 above shared by planitDocs but to no avail. I am not very keen on solution 2 so I was wondering if anyone from MadCap reading these forums or any of you would have any other workarounds or tricks to suggest?

I have a question re: solution 2. What do you mean by XML declaration? Is it the line that I have got at the start of nearly every of my topics?

Code: Select all

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

I told my colleague to test the same help files on the latest version of Firefox (and to select Firefox as his default browser) as I thought it supported XHTML but it did not work.

Thanks in advance for any input.

[RamonS]

I told my colleague to test the same help files on the latest version of Firefox (and to select Firefox as his default browser) as I thought it supported XHTML but it did not work.

Testing the WebHelp output did not work? As far as a CHm goes, it does not matter which default browser is selected, because the CHM viewer will always use the IE rendering engine and adhere to the system wide Internet Option settings.

[MC Hammer]

Testing the WebHelp output did not work? As far as a CHm goes, it does not matter which default browser is selected, because the CHM viewer will always use the IE rendering engine and adhere to the system wide Internet Option settings.

We only produce HTML help (I know, don't get me started on this...) but I guess I can create a new WebHelp target and ask him to test it. Will the WebHelp be rendered with the browser that has been set as default?

Thanks.

[i-tietz]

On CSH: I don't really know ... but I think that calling a specific browser doesn't make sense, cos' the user might not have it.
On doubleclick: Yep.
Whatever "default" is for the user ... could be Firefox, IE, Chrome, ... and in whatever version it's installed ...

[RamonS]

Testing the WebHelp output did not work? As far as a CHm goes, it does not matter which default browser is selected, because the CHM viewer will always use the IE rendering engine and adhere to the system wide Internet Option settings.

We only produce HTML help (I know, don't get me started on this...) but I guess I can create a new WebHelp target and ask him to test it. Will the WebHelp be rendered with the browser that has been set as default?

Thanks.

I asked my question wrong, I guess. I don't think that testing WebHelp output will bring any clues. My point is that making FF the default browser is irrelevant when facing CHM problems. So "testing the help files on the latest version of Firefox" made me wonder how CHMs are tested with FF and lead to me to the guess that it was WebHelp, which did not work either.

[MC Hammer]

I asked my question wrong, I guess. I don't think that testing WebHelp output will bring any clues. My point is that making FF the default browser is irrelevant when facing CHM problems. So "testing the help files on the latest version of Firefox" made me wonder how CHMs are tested with FF and lead to me to the guess that it was WebHelp, which did not work either.

Got you !!!

[MC Hammer]

UPDATE
Just to let you know that we managed to solve the problem using solution 1. IE was the default browser but somehow my colleague had a custom configuration. Everything was reset to default and voila! (Still don't understand why this worked as I can open CHMs on my PC and I also have a custom configuration for my web browser but maybe something went wrong when my colleague tried to uninstall Google Chrome and this could have caused CHMs not to display properly).

[i-tietz]

Then maybe you should have your colleague switch to your settings and find out whether that works, too.

[RamonS]

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.

[i-tietz]

I'm merely trying to find the reason or at least one of the reasons for that, since 3 of our customers have the same problem and we would like to be able to tell them what they have to do to read our help.

[RamonS]

If they are up to it, have them lower the Internet and Intranet security settings to at least medium-low. If that works, have them reset the settings back to previous configuration (from screen shots, don't think there is a way otherwise unless logon scripts cover that), then switch one section at a time to enable / allow until it works, then drill down to the individual setting. I've done this for our ASP.NET based apps once and found the settings for a customer that needed changing. My assumption is that this will be the case for CHMs as well. The first test will show if this has anything to do with the Internet Security settings at all. It is a very tedious task and only works when the customer has rights to make the changes in the first place, many IT departments lock the settings down.

[i-tietz]

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.

[LTinker68]

Ask our customers to lower their security settings?

He didn't mean permanently. You take it down briefly, then start adding in restrictions until you find the one that caused the problem. By the end, the restrictions should be close to what they were before, since it was probably just one, maybe two options that caused the problem.

[RamonS]

And I didn't advertise as an awesome idea either, just mentioned it because it was a successful path in one of the cases I dealt with. In the end the customer had to weaken security minimally, but got a working web app in return. And that ran exclusively on the Intranet, which means getting anything bad from the server is unlikely to begin with. And if that still would happen there are much bigger issues to deal with than an app or help not working.

[i-tietz]

Aha. So we are supposed to tell them: "Yes, a part of our product isn't working, but you will have to find the cause yourself. It's gonna cost you a few hours to check thoroughly but that way you find out if that's the reason. I might not be, though ... maybe the cause of all this is simply a bug of the IE version you're using or a setting of your Windows or network installation or in the scripting of the software we're using. In that case you will have to go on searching for the reason, for the simple reason that we don't know what it is. OH, and: Could you please be so kind to let us know what the cause was, so we can help other customers ... "
... errrr ...
Are you serious? You must have REALLY patient customers ...

[RamonS]

We did that for them. And their choice was to either have us find the cause and fix it or leave them with a system that doesn't work. Besides that, they had the system working before they collectively switched to W7 clients and tighter security. It was quite obvious that our software per se was not broken.
I know that some customers are really uncooperative and call the president when they find a spelling error. No matter what effort you put into, they will never be happy - because they are entirely unreasonable. Aside from that, as long as you can demo that on a properly configured system the apps and help work the customer has not much of a case. After all it is the customer providing the environment to run the apps on and that environment needs to be following requirements.
In our case some customers are that unreasonable, but that is typically in new installations where they boycott the system. They now have to do something different and they may (rightfully?) connect more efficient operations with reassignments or layoffs. In other cases they are suffering in general from neglect of the IT department, often because IT was not in charge when purchasing the software. So in most cases it has nothing to do with 'software being broken', but that happens as well. Our turnaround for that is typically a day or two and customers value that. That's why we have 97% retention rate with support contracts and the few that drop support do so because they don't get the funding for it, not because they dislike someone spending an hour poking around in Internet Security settings to find the root cause of an issue and fix it.