9 Replies Latest reply on Jul 12, 2007 10:07 AM by Applied CD

    Buddy API and Acrobat 8 Solution

    Level 7
      Hi all,

      Am posting this message multiple times. The question was asked a couple
      weeks back and then again just recently. Have posted in both of those.
      But, just to ensure anyone who has seen tis issue gets te information,
      I'm starting a new thread.

      I have emailed Gary who develops the Buddy API Xtra and he did some
      testing and this is what he reported.

      It seems that when Adobe install Reader 8.0, they don't implement an
      'Open' association, but a 'Read' one. If you right click on a .pdf file
      you will see that the actions available don't include Open. Now, this
      should only affect people using an older version of Buddy, that was
      something changed for Acrobat 7 and .fdf files, so that if there wasn't
      a Open action, it used the default one instead. So the best option is to
      use the current version of Buddy. But to make it work with programs
      still older buddy that can't be changed, it should be possible to write
      a .reg script or updater to add the Open command to the list of actions,
      then older version of buddy will work. You can use this script in a
      projector to update the registry so that pdf files will open. So that
      could be used in a updater projector.

      on setAcroOpenReg
      str = baReadRegString( "Applications\AcroRD32.exe\shell\Read\command",
      "", "", "HKEY_CLASSES_ROOT" )
      if length( str ) > 0 then
      baWriteRegString( "Applications\AcroRD32.exe\shell\Open\command",
      "", str, "HKEY_CLASSES_ROOT" )
      end if
      end

      Hope that helps.

      regards
      Dean

      Director Lecturer / Consultant / Director Enthusiast
      http://www.fbe.unsw.edu.au/learning/director
      http://www.multimediacreative.com.au
      email: d.utian@unsw.edu.au


        • 1. Re: Buddy API and Acrobat 8 Solution
          Applied CD Level 1
          Thanks for doing the leg work on this Dean. I’m putting together a test rig right now to confirm the solution but I wanted to point out a clarification in Gary’s response if anyone else tries this…

          By “old” version of Buddy API I believe Gary is referring to v 3.7 which is still the version offered by his download page. To get the newer 3.76 version you must visit his “Version History and BugWatch” page and scroll to the bottom for the link.
          • 2. Re: Buddy API and Acrobat 8 Solution
            Level 7
            Applied CD wrote:

            > Thanks for doing the leg work on this Dean. I?m putting together a test rig
            > right now to confirm the solution but I wanted to point out a clarification in
            > Gary?s response if anyone else tries this?
            >
            > By ?old? version of Buddy API I believe Gary is referring to v 3.7 which is
            > still the version offered by his download page. To get the newer 3.76 version
            > you must visit his ?Version History and BugWatch? page and scroll to the bottom
            > for the link.

            Let me know how you go and I'll pass the info onto Gary. Wish you all the best with
            it.

            regards
            Dean

            Director Lecturer / Consultant / Director Enthusiast
            http://www.fbe.unsw.edu.au/learning/director
            http://www.multimediacreative.com.au
            email: d.utian@unsw.edu.au


            • 3. Buddy API and Acrobat 8 Solution
              Applied CD Level 1
              After two days of writing and testing the issue boiled down to a problem with using forward slashes as a path separator with Buddy API 3.7x and Reader 8 on some machines. Both 3.70 and 3.76 work fine on all machines without the registry patch as long as the document path uses backslashes only. Forward slashes + Buddy API + Reader 8 will poison some machines but not others. Forward slashes issued directly from the command line work fine. The registry patch had no effect. Read on for details…

              Fate was kind to me last week and delivered a brand new Dell (XP Pro SP2 preinstalled) that had never had any version of Acrobat except Reader 8 which I personally installed. This system exhibited exactly the same symptoms as my client, AcroRd32.exe would launch and be added to the process list but no window would open and the reader had to be terminated using the Task Manager.

              At the same time, I installed brand new disks into the older Dell and rebuilt the system to XP Pro SP2 starting from SP 0 disks. Once again, I thought I had a machine with nothing in the system registry other than what the Acrobat Reader 8 installer put there. To my surprise this machine worked fine, AcroRd32.exe would properly open a document regardless of the path separators used.

              Specific examples (I did many more tests but these illustrate the problem):

              Test: Buddy API 3.70 and Acrobat Reader 8 opening a PDF from a sibling folder using the path below

              C:\Documents and Settings\Robert Gallo\My Documents\Work\PDFtest\movies\..\PDFs\Poster.pdf

              Result: Works on all machines
              ------------------------------------------------------------------------------------------ --------------
              Test: Buddy API 3.70 and Acrobat Reader 8 opening a PDF from a sibling folder using the path below

              C:\Documents and Settings\Robert Gallo\My Documents\Work\PDFtest\movies\../PDFs/Poster.pdf

              Result: Works on rebuilt Dell, fails on new Dell and client machine (XP Pro SP2 with upgrade to Acro 8 from 7)
              ------------------------------------------------------------------------------------------ --------------
              Test: Use the following path to open a PDF directly from the command line

              C:\Documents and Settings\Robert Gallo\My Documents\Work\PDFtest\movies\../PDFs/Poster.pdf

              Result: Works on all machines

              So the workaround is clear, always use backslashes as path separators. The cause is very fuzzy. Forward slashes don’t work with Acro Rd 8 on some machines when Buddy API is involved. Any thoughts?

              PS: You get the same results with Buddy API 3.76 in all cases.
              • 4. Re: Buddy API and Acrobat 8 Solution
                Applied CD Level 1
                OK, I’m gonna cry now ;-) … I did a quick review of recent projects to determine how much trouble this was going to be for us. Out of dozens of projects the forward slash was used very rarely but when it was used it caused the expected problems except in one case. In this case there are two buttons in the same frame, calling PDFs from the same child folder, using the same behavior, both have forward slashes in the path, both documents are of the same PDF vintage, one is problem free the other is not. This was not my project so there could be something else going on but at this point I have no explanation for why one works and the other not. In all other cases a forward slash flagged a guaranteed problem.
                • 5. Re: Buddy API and Acrobat 8 Solution
                  Level 7
                  Applied CD wrote:

                  > OK, I?m gonna cry now ;-) ? I did a quick review of recent projects to
                  > determine how much trouble this was going to be for us. Out of dozens of
                  > projects the forward slash was used very rarely but when it was used it caused
                  > the expected problems except in one case. In this case there are two buttons in
                  > the same frame, calling PDFs from the same child folder, using the same
                  > behavior, both have forward slashes in the path, both documents are of the same
                  > PDF vintage, one is problem free the other is not. This was not my project so
                  > there could be something else going on but at this point I have no explanation
                  > for why one works and the other not. In all other cases a forward slash flagged
                  > a guaranteed problem.

                  So, besides the extra work, is teh issue solved now?

                  regards
                  Dean

                  Director Lecturer / Consultant / Director Enthusiast
                  http://www.fbe.unsw.edu.au/learning/director
                  http://www.multimediacreative.com.au
                  email: d.utian@unsw.edu.au

                  • 6. Re: Buddy API and Acrobat 8 Solution
                    Level 7
                    Hi AppliedCD,

                    ---
                    From Gary:
                    I've noticed in the past some systems seem happy to work with forward slashes, some
                    don't, so only using back slashes is the way to go. I don't do any processing of the
                    file name in Buddy for the baOpenFile function (unless the @ operator is used), the
                    file name is passed directly on to the ShellExecute function. I'd be interested to
                    see if there are different versions of shell32.dll on the different machines.
                    ---

                    Anything you can add to this?

                    regards
                    Dean

                    Director Lecturer / Consultant / Director Enthusiast
                    http://www.fbe.unsw.edu.au/learning/director
                    http://www.multimediacreative.com.au
                    email: d.utian@unsw.edu.au


                    • 7. Re: Buddy API and Acrobat 8 Solution
                      Applied CD Level 1
                      That would have been a great explanation but the C:\WINDOWS\system32\shell32.dll file on both machines is 6.0.2900.3051.

                      I can contribute the following new information:

                      1. The problem is very specific for Reader 8. I installed Acrobat Pro 7 on the “slash sensitive” machine and suddenly it works with both forward and backslashes. Just for fun I changed the default application for PDF files back to Reader 8 and the forward slash problem returned so now I can turn the problem on and off at will.

                      2. Using baShell("open",myAppPath,myPathString,"","normal") and/or _player.open(myPathString,myAppPath) (where myAppPath and myPathString are the short file name versions of the full path) produces the same results as above, works with backslashes but not forward on slash sensitive machines.

                      3. This is interesting: Valentin Schmidt’s Shell Xtra v1.1 with the following code shell_cmd_thread(myPathString) (where myPathString is again the short file name path) IS NOT forward slash sensitive with Reader 8. I echoed myPathString just to make sure baShortFileName wasn’t reversing the slashes, it’s not. The path matching the problem example above was: C:\DOCUME~1\ROBERT~1\MYDOCU~1\Work\PDFtest\movie\../PDFS/Poster.pdf

                      So, if you really like forward slashes and need to open files in Reader 8 on all machines, option 3 will work … personally I’ll just stick with Buddy API and keep all my slashes left leaning.

                      Dean, in answer to your earlier question, as far as I’m concerned the problem is resolved. As long as we only use backslashes we will be happy and wealthy and never experience coding bugs ever again ;-)
                      • 8. Re: Buddy API and Acrobat 8 Solution
                        Level 7

                        "Applied CD" <webforumsuser@macromedia.com> schreef in bericht
                        news:f711hl$dgn$1@forums.macromedia.com...
                        > That would have been a great explanation but the
                        > C:\WINDOWS\system32\shell32.dll file on both machines is 6.0.2900.3051.
                        >
                        > I can contribute the following new information:
                        >
                        > 1. The problem is very specific for Reader 8. I installed Acrobat Pro 7 on
                        > the
                        > ?slash sensitive? machine and suddenly it works with both forward and
                        > backslashes. Just for fun I changed the default application for PDF files
                        > back
                        > to Reader 8 and the forward slash problem returned so now I can turn the
                        > problem on and off at will.
                        >
                        > 2. Using baShell("open",myAppPath,myPathString,"","normal") and/or
                        > _player.open(myPathString,myAppPath) (where myAppPath and myPathString are
                        > the
                        > short file name versions of the full path) produces the same results as
                        > above,
                        > works with backslashes but not forward on slash sensitive machines.
                        >
                        > 3. This is interesting: Valentin Schmidt?s Shell Xtra v1.1 with the
                        > following
                        > code shell_cmd_thread(myPathString) (where myPathString is again the short
                        > file
                        > name path) IS NOT forward slash sensitive with Reader 8. I echoed
                        > myPathString
                        > just to make sure baShortFileName wasn?t reversing the slashes, it?s not.
                        > The
                        > path matching the problem example above was:
                        > C:\DOCUME~1\ROBERT~1\MYDOCU~1\Work\PDFtest\movie\../PDFS/Poster.pdf
                        >
                        > So, if you really like forward slashes and need to open files in Reader 8
                        > on
                        > all machines, option 3 will work ? personally I?ll just stick with Buddy
                        > API
                        > and keep all my slashes left leaning.
                        >
                        > Dean, in answer to your earlier question, as far as I?m concerned the
                        > problem
                        > is resolved. As long as we only use backslashes we will be happy and
                        > wealthy
                        > and never experience coding bugs ever again ;-)
                        >

                        Hi,
                        I do not quite understand all this about forward slashes, can you explain
                        why you used them in the first place?

                        As far as I know there is only 1 path separator in the Windows / DOS world
                        and that is a backslash?
                        The forward slash is reserved for specifying option on the command line, so
                        maybe the reader interprets this (correctly) as an option!
                        In URL specifications you must use forward slash, not backslash. Maybe this
                        is where the confusion originates?

                        I also would not use . or .. in a path/filename
                        Much better to work out the absolute path first, and give that to the
                        system.

                        Regards,
                        Richard.




                        • 9. Re: Buddy API and Acrobat 8 Solution
                          Applied CD Level 1
                          quote:

                          I do not quite understand all this about forward slashes, can you explain why you used them in the first place?


                          Sloppiness I’m afraid. The relative path to PDFs was originally specified as ../PDFs/ and that behavior was then attached by copy/paste to about 40 sprites. Since the PDFs were all in the same folder and since the project worked at the time no one looked back at the path reference. We’ve been using the same openFile behavior for many years in many projects, I only found two projects with forward slashes.

                          Just for my own information I did some digging on the history of using the forward slash as a path separator in Microsoft operating systems. It was first allowed in DOS 2 to facilitate migrating Unix code to DOS, also, some of the low level DOS commands were taken directly from Unix and accepted the forward slash even in DOS 1. To maintain compatibility with legacy DOS programs the Windows API will convert forward slashes to backslashes when presented with a path in 8.3 format using the first space to separate the path from command line switches, it will not convert paths in Joliette format. In our tests above this is probably why the Shell Xtra worked where Buddy API did not. Shell Xtra was given an 8.3 path where Buddy API was using the Joliet path.

                          As for using . or .. in the path name, I’m not sure I agree. Their use allows our behavior to accept both relative and absolute path statements … it’s legal on the web (where the absolute path can be very messy) and also in Windows so I feel fairly comfortable using it.