This content has been marked as final. Show 11 replies
thanks for he link. Although it does provide a solution, it has prompted me to post to the forum you linked to. Thanks.
The help file is standalone, so the problem of linking from the application is not an issue. The problem ONLY occurs when using the shortcut link and not when opening PDFs directly. Will let you know if it gets resolved.
So a virtual pint will have to do for now
LOL, nah... I don't go for beer anyway. Smirnoff Ice is my choice of beverage! Then again, I was once at a drinking establishment where I asked about beer alternatives. I was steered toward this "Raspberry beer". It was really good! Then I got the bill. What?!!! You have GOT to be kidding me. $8 a glass?!!!
On a more serious note, I originally saw your link and somehow inferred it just pointed to another thread. My bad. I see it points to basically the same information.
Apologies to both you and Craig... Rick
Entirely different link Rick, so thanks.
Very handy piece of code and I will incorporate it if all else fails!
Looks like it could be my round!
I just found this thread because I'm hitting this issue. There are some links that are referenced here, but they're not showing up. Does anyone still have these links or know a solution to this issue?
This article on Rick's site pulls together all the proposed solutions to the issue:
These solutions are designed to work around the "relative path bug" (described in some detail here), which causes ShortCut controls to fail when the help file is opened from an application. The same controls may work fine when you open the help file from Windows Explorer.
ShortCut controls can also fail for another reason — because the help file is stored remotely, on a network drive — and in that case there isn't really an effective workaround. This article in the Microsoft Knowledge Base describes the issue:
Thanks for the reply, Pete. Unfortunately, I think my issue is slightly different. We have a CHM file that just contains a bunch of shortcut controls with links to our documentation, some of which is .pdf files and some is other help files. There is one user who can open the other help files with no problems, but when he selects one of the .pdf buttons, nothing happens. He doesn't get an error, just dead air. Any ideas?
It sounds like this may be an issue with the user's computer if he's the only one to suffer it. Do you know if he can open the PDF files without problem when double-clicking them in Windows Explorer? And do you have any information on his computer set-up, such as version of Windows, Acrobat Reader (if installed), and Internet Explorer?
Out of curiosity, can you paste the HTML source of one of these shortcut controls into a reply? It will look something like this:
<object id="ShortCut" classid="clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11">
<param name="Command" value="ShortCut">
<param name="Button" value="Text:Click Here">
<param name="Item1" value=",UserGuide.pdf,">
One thing to note is the application used to open PDF content. Most of the time it's the Acrobat Reader. But a year or more ago I had read an article about a wonderful application called the Foxit Reader. The article was in a PC magazine and listed among the top freeware apps to use. It was said this reader displayed PDF just fine and was a LOT more light weight than the Adobe Reader. So I installed it. And things were dandy until I attempted to open a PDF from RoboHelp and Captivate. It behaved just as you were describing until I elected to return to Adobe PDF viewer as the default application to use.