4 Replies Latest reply on Jul 2, 2011 12:20 AM by Peter Grainge

    Elementary Relative Path Issue

    Jack DeLand

      RoboHelp 9.0.1.232 / TCS3 on WinXP Pro SP3

       

      This is embarrasingly simple.  I am creating HTML Help and WebHelp from the same source. I want to open a PDF outside my CHM and outside of the WebHelp browser. Putting the PDF in baggage is not an option for me.  The CHM (on Windows) or WebHelp (on Linux) are stored in a subdirectory called "contexthelp".  The PDF is stored in a subdirectory called "docs".  Shouldn't the relative path for launching the PDF be "..\docs\pdfname.pdf"?

       

      <a href="../docs/glyphref.pdf">webhelp link</a> works for WebHelp, except that it displays the PDF inside the browser, which I don't want. I can't get the relative path to work at all in the CHM.  I am trying to use the "Shortcut" Help control, which would be a nice to have because it's so pretty, but I would settle for just a link. What is the proper, complete syntax?

        • 1. Re: Elementary Relative Path Issue
          Jack DeLand Level 1

          Answered by Rob Cavicchio, MSVP.  Thanks, Rob.

          • 2. Re: Elementary Relative Path Issue
            Captiv8r Adobe Community Professional & MVP

            Hi all

             

            I saw the thread on HATT.

             

            In the event folks may find this thread later and want to know what Rob actually suggested instead of knowing he fixed it, here is a copy/paste from Rob's reply on HATT. (Rob is a Microsoft Help MVP)

             

            =====> Begin Copy/Paste <=====

             

            Not as elementary as it seems. The CHM is a self-contained file system, much
            like a ZIP file. When you use a relative path from a file inside the CHM, it
            goes to another file inside the CHM, not to the actual file system. To do
            what you want requires a bit of JavaScript. Luckily for you, everybody and
            his brother wants to do this, so there's a Microsoft KB article on it:

            http://msdn.microsoft.com/en-us/library/ms644690%28VS.85%29.aspx

            To ensure that the PDF opens in a separate PDF reader rather than in the
            browser, you'd want to write the URL to a Shortcut object rather than to a
            link, something like the following:

            <html>
            <head>
            <script type="text/javascript">
            function setPDFPath(fn, text)
            {
            var X, Y, sl, a, ra, link;
            ra = /:/;
            a = location.href.search(ra);
            if (a == 2)
            X = 14;
            else
            X = 7;
            sl = "\\";
            Y = location.href.lastIndexOf(sl) + 1;
            link = 'file:///' + location.href.substring(X, Y);
            // ACCOUNT FOR PATHS THAT GO UP IN THE TREE;
            while( fn.indexOf('../') == 0 )
            {
            fn = fn.substring( 3, fn.length );
            link = link.substring( 0,
            link.lastIndexOf(sl, link.lastIndexOf(sl) - 1) + 1 );
            }
            link += fn;
            document.getElementById( "pdflink"
            ).insertAdjacentHTML( 'afterBegin', '<object
            classid="clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11"
            type="application/x-oleobject"><param name="Command" value="ShortCut"><param
            name="Button" value="Text:' + text + '"><param name="Item1" value=",' + link
            + ',"></object>' );
            }
            </script>
            </head>
            <body onload="setPDFPath('../docs/glyphref.pdf', 'Click to open the PDF');">
            <p><span id="pdflink"></span></p>
            </body>
            </html>

            For WebHelp, you might be stuck. I'm not sure there's a consistent and
            reliable way to ensure that a PDF opens in a separate window if a user has a
            PDF plug-in installed. You can try to force it to be treated as an
            executable file by playing around with MIME types via the <a> element "type"
            attribute, but I think those are often ignored.

            ********************
            Rob Cavicchio

             

            =====> End Copy/Paste <=====

             

            Cheers... Rick

            • 3. Re: Elementary Relative Path Issue
              Jack DeLand Level 1

              Didn't think many people cared, with only 7 views yesterday!  Rob also notes that you need to remove extra line breaks in the posted code at the line beginning document.getElementById.

               

              This works with the PDF, but RoboHelp removes the line <p><span id="pdflink"></span></p>.  I got around it by saving it as a snippet.  Now if I could only get it to launch an swf. ...

              • 4. Re: Elementary Relative Path Issue
                Peter Grainge Adobe Community Professional (Moderator)

                The number of views is misleading. Many people follow the forums by email or RSS feeds and those views don't get counted.

                 


                See www.grainge.org for RoboHelp and Authoring tips

                 

                @petergrainge