This content has been marked as final. Show 9 replies
> errCode = baOpenFile(myPathString,"")
While it is probably completely unrelated (since it has worked in the
past), the second parameter that baOpenFile() takes should be one of 4
state options and I always use one of these (instead of passing an empty
Just a note to add we've hit exactly the same issue, with Acrobat failing to launch, no error, no nothin'. Robust with Acrobat 7, but somewhat tempramental with v8. We're investigating options...
Are you using Buddy API (or another xtra) to do the opening? If so, is
there an error returned?
Just a quick update. The client has confirmed that they can open the PDFs externally, no error is generated by BuddyAPI from our app. I have an appointment this afternoon to walk the client through some tests … we use the same code in the same project to open Word docs as well … it will be interesting to see if the problem is Acro specific. Fortunately my contact is local so I can build and send over a diagnostic CD if required. I’ll post results when I have them.
BTW: I’ve been using the code above so long I don’t remember why I set the state string to “” … might have been an ancient carry over from the Mac. I'll fix it going forward and look into that being the cause here.
Applied CD wrote:
> Just a quick update. The client has confirmed that they can open the
> PDFs externally, no error is generated by BuddyAPI from our app. I
> have an appointment this afternoon to walk the client through some
> tests ? we use the same code in the same project to open Word docs as
> well ? it will be interesting to see if the problem is Acro specific.
> Fortunately my contact is local so I can build and send over a
> diagnostic CD if required. I?ll post results when I have them.
Does AcroRd32.exe show up in the Processes tab in Task Manager, but fail to
display, or does it fail to be launched?
If the former, perhaps you could get its window handle and prod it with
I don't know yet but it's on my list of questions for the client. If AcroRd32 is running the problem could be as simple as my being sloppy with specifying the window state in baOpenFile ... it's never been a problem before, but who knows, maybe some setups are just sensitive.
OK, just got off the phone with the client. Attempting to open a PDF from our app puts AcroRd32.exe on the process list with 50% CPU usage and immediately locks our application (program not responding) … the Acro Reader window is never opened, no error displayed. Killing the AcroRd32 process restores interactivity to the projector. The same code, when used to open a Word doc works fine.
I’m going to send a diagnostic CD to the client that simply opens a test PDF but right now the only thing different I can think of is to explicitly set the window state. I’ll also try several versions of PDF documents although I think that’s a little far fetched. I'll try displaying the window title and handle list and maybe I can see how far Acrobat is getting in its launch. I’m open to suggestions on what else I might include.
I just received a call this morning regarding CD's I made with the Acrobat BuddyAPI which is no longer working on Windows machines that have been upgraded to Acrobat 8. This is a HUGE problem for us now. Has anyone else learned of any answers on how to correct this problem? Mac side seems unaffected so far. Oldp projects are being returned to me now to reconstruct so they open pdf's again. It's the same problem as described above, Acrobat won't launch from my Director menu anymore (in Acrobat 8), nothing at all happens. No error, nothing. The pdf can be opened from the CD when the file is clicked on separately.
This is a costly error for us now. Any help is appreciated.
I just posted this in anotehr thread dealing with the same issue.
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.
str = baReadRegString( "Applications\AcroRD32.exe\shell\Read\command",
"", "", "HKEY_CLASSES_ROOT" )
if length( str ) > 0 then
"", str, "HKEY_CLASSES_ROOT" )
Hope that helps.
Director Lecturer / Consultant / Director Enthusiast