This content has been marked as final. Show 7 replies
It is almost certainly caused by an erroneous path. You can right click on the TOC or frame and select "Jump to URL" and it will report the current URL. This should be correct for the user's computer.
I had something similar happen when I launched the help from the application. Our application can run on two or more computers that share a data directory. After loading data from another computer, the "current directory" in Windows was a network drive and the help quit working - it was actually trying to access the help on the colleague's computer. We think this problem is limited to uninstalled applications, where the app and help are simply copied into a directory and this could be happening in your case. We haven't had this problem reported by any of our commercial customers or during beta testing - only during development.
Hope this helps,
Are they simply opening the help and getting the problem or does the problem occur in their calls from the application to the help?
Create a new project with just a couple of simple topics. Send that to development to see if they get the problem with that.
Then post back here.
The file is actually a draft sent for our next software release to our development team. Right now, our QA just wants to open it as a stand alone file and review some changes I put in that are not context sensitive.
On a hunch, I rebuilt my build tags expression and resent it to them - haven't heard a peep since. But I also forwarded John's advice about checking the URL in case they are still getting errors. The really weird thing is that I can see the entire system perfectly well not only on my development PC, but on my home computer. No errors. So I have to think it is the file location on their side, even though they swear up and down that they have saved the .chm to their own drives. Checking the URL might pop up the problem - thanks to both of you, no matter which way it goes!!!
Are those drives shared? I think that can have the same effect. Not sure but worth checking.
well it gets weirder. I had one of the development guys right click to see the Jump to URL entry and all he sees is Print on the altmouse menu.
I haven't seen this one offered up yet, so here goes. I'm not sure if this applies, but I could easily see it being the case.
If you download a .CHM from the web, Windows XP will typically block the file until you pat XP on the head and convince it that you really DO want to see the information and the world won't REALLY come to an end if it shows it to you. So how to do this? Try right clicking the file after you save it, then examining the Properties. Once you do this, you should see a button labeled "Unblock".
As I said, I know this happens when you download a file. Not sure if it happens when you send one via the methods you outlined, but it might just be why it happens.
an update - I sent the Unblock suggestion to my QA, who used it, and was able to get into the help file. But when she copied the .chm to the development environment to be included in the build, our developers can't open it, and there is no Unblock available.
For now, because we are doing an interim build, we will just incorporate the file as is into the build and see how the help system works from within the program, which is how our clients access it. We have never had a complaint from clients, by the way, about accessing topics. It just seems like in the past two or three months, something has changed on PCs here in the office to cause these errors when the chm is viewed as a standalone. And not on every PC - I have never had the problem, either on my own production laptop or on my home PC. It's enough to drive me to drink. Heavily.