Hi all,

I have a bit of a quandry with regards to the registered PDF open program. Win7 64 bit is the OS with all the appropriate updates for the OS and Adobe Reader.

I can't get ShellExecute to recognize the registered application for PDF files (the API returns 31: registered app not found or verb not invokable on file). Seems straightfoward enough, but I can open PDFs from everywhere else: email, desktop etc. The registered program is there (Adobe Read X).

Here's how it happened:

1) Purchase new computer, Win7 64 bit
2) Install Adobe Reader, latest version, probably X at the time
3) Intsall Adobe Acrobat, version 7.0, office software we use a bit
4) Find Acrobat 7.0 doesn't work on 64bit, uninstall and move to XP virtual machine, no biggie
5) ShellExecute no longer opens my PDF documents
6) Go to file/folder options and reset .pdf files to open with Reader
7) Still no luck, verify Acrobat is completely removed from system
8) Uninstall reader
9) No PDF registered files anywhere
10) Reinstall reader
11) Same as before, PDFs from email/desktop, but not from ShellExecute (returns 31 still).

I'm inclined to believe that somehow this Acrobat seriously mucked up some works, though I'm not sure where to go from here. I expect there's a registry setting that can be examined and modified, but I don't know where to start.

Does UA have any ideas, or should I wander to the Adobe forums? (shuddering at the thought)

Thanks for any help,

Jack,

Greetings. I'm not an Adobe/Acrobat expert, but I've found (and resolved) some issues with Reader 9x/10x and Acrobat 9x with Win XP SP3 and MSO 2K3 here in the office.

No offence, but me thinks Acrobat 7.0 is just a tisch "old" for a 64-bit PC running Win7. I would be curious to see if the "verb not invokable" (error 31) would still appear if you installed a newer version of Acrobat.

I sometimes joke that I'm going to resign and work for Adobe, since I don't know anything about Java, but I have a feeling that a newer version of Acrobat might resolve the issue you're experiencing.


HTH,

AvgJoe

This post has been edited by AvgJoe: Aug 30 2011, 10:08 AM

I don't really care about acrobat, 7 works fine on XP for my purposes so I don't have any interest in spending money on something newer. However, with it uninstalled on Win7, I need whatever it screwed up fixed, and there's no way I'm paying additional money for that, even if installing a newer version would help.

Cheers,

Jack,

Does this help - Adobe Reader - Error 31


AvgJoe

Not sure, I've got Adobe Reader X installed, which theoretically should work, but doesn't (it's only this machine where I attempted to install Acrobat 7, other machines are fine).

I'll probably hunt around on adobe forums and ask if I can't find anything. I haven't done so yet, was hoping someone here knew of a fix.

Thanks for the suggestions,

I have to say, I'm at a complete loss here. I uninstalled all adobe products, restarted, removed all adobe registry leftovers, restarted, installed Adobe Reader X, restarted, had to manually set the associated program for .pdf files (?), and still ShellExecute says no registered file.

To check whether this might be an Access/Office leftover from when Acrobat was installed, I ran a vbscript direct from a textfile using Shell.Application's version of shellexecute, with the same error: no registered program. Apparently, even though I can open a pdf direct from the desktop or from my email program (windows live), I cannot program one to open using shellexecute from Access VBA or a vbscript.

Even Application.Hyperlink (which I don't use anyway) can't find the registered application.

(IMG:style_emoticons/default/crazy.gif)

(IMG:style_emoticons/default/shout.gif) (adobe)

I've made some progress, but not quite enough yet.

As for opening the file, let's go back to the ShellExecute, particularly the lpOperation parameter. By default my ShellEx function passed this as "open", which at the time of writing I had apparently assumed was the default anyway. Come to find out, "open" is not the default verb. Rather, the default verb is read from the reg for the associated filetype, and that is the verb that is used.

Apparently, at least one version of Adobe Reader does not employ the use of "open" as a valid verb (thanks adobe). Instead, pass "read" as the verb, and walah, the file opens. Go figure.

In earlier tests, I had suspected maybe that "open" was messing with it, and had instead passed the lpOperation parameter as 0&

Again, 0& is not the correct parameter to pass in order for shellexecute to process the default verb. When lpOperation is passed as vbNullChar instead of 0&, the vbNullChar is in fact the one which will force the API to track the default verb ("read" - go figure).

Somewhere during my testing I ran FindExecutable just to see, and it was able to find the acrord32.exe that is required, so this matches up well with the above.

So, opening the PDF is fine if I set my ShellEx function to default at vbNullChar. Done.

Now - I used to be able to Print these things by passing the lpOperation verb at "print". Not so anymore... now even right clicking on a desktop pdf file doesn't supply a Print command. In XP, you used to be able to create your own and add them... apparently not so in Win7 (actually I think they may have done away with this as far back as Vista). I read somewhere that you can go into the registry and see what action verbs are available. In some areas of the reg, there is a print, with the correct commandline to go with it, in some areas there are not. Interestingly enough, in every place I can find a pdf association, there's an "open" command as well... hmmm... well I guess I just won't go there.

I don't suppose anyone knows how to force a Print command in the registry if the correct commandline is known?

Fun fun fun


edit: for the record, a ZLS or vbNullString can be passed to lpOperation and it apparently has the same effect as passing vbNullChar