This method is not in Reader.
It is an Acrobat method and as I have written, Acrobat is installed and this was posted in the Acrobat SDK-Forum. This should actually make it sufficiently clear. The only thing, which has changed vs. the previously running macro, is that our Company has installed Adobe Reader DC in addtion to Acrobat. This seems to cause reference pointing to missing filesacrord32.dll-files after they were implemented with existing Acrobat.tlb
Having the free Adobe Reader on the same system as a version of Acrobat that is different than the Reader version is not supported. Also, having more than one version of Acrobat on the same system is not supported either. The fact that it stopped to work after you installed Reader suggests that Reader is causing this problem. You need to uninstall Reader, and one of the Acrobat versions and then repair the remaining Acrobat installation via the "Repair" item in Acrobat's Help menu.
I work since years with Reader and Acrobat on the same system and most scripts are VBS. So far without problems.
I would reinstall Acrobat and new install (after Reader installation)
what indeed helped was simply uninstalling Adobe Reader DC on a combined installation of Acrobat and Adobe Reader. No Need to repair...
Obviously Reader spoils the reference, which then does not refer to Acrobat.tlb, but ..reader10\Acrord32.dll, i.e. a subfolder not existing with the new DC Installation (but file and Folder existed before and everything was o.k.). The newAcrord32.dll in the "\Acrobat Reader DC\Reader"-folder on the other Hand cannot be referenced from VBA. Reader removed--> no reference issue any more.
But: this does unfortunately solve the problem only for a minor part. If I give the addins to users I have no control on their Adobe/Acrobat set-up, i.e. if they have Reader installed or Acrobat or both.
It must work in all cases and only the specific pdf-functionality should not be accessible without Acrobat installed.
I work with VBS and some years ago also with VBA. I wonder about your writing of reference problems. I think you mean something like this (Do I have the wrong Acrobat.tlb file?). So far as I know there is no need to reference anything ( ...dll, ...tlb) to work with vbs/vba code and Acrobat. I never have had to take car of used ...dll/...tbl. Perhaps this "referencing" fix only your system to the wrong dll.
For testing you could write some simple (Acrobat IAC) VBS code and test if that works on your systems.
Thanks. The Forum Topic you linked to is definitely a similar related topic. I had already upvoted it as having the same question.
I HAVE to reference the Adobe library as otherwise the System throws errors because of the Adobe objects used in the code (e.g. dim .. as Acrobat,CAcroPDDoc). These are otherwise unknown to VBA and I cannot work by simply defining generic objects as soon as I am using specific pdf-methods.
As said the problems are:
a) a correctly set Acrobat.tlb-reference is converted to a wrong Acrord32.dll on saving/reopening...(unless Reader DC is removed from the System, which I can only do for my personal PC, but not for others)
b) it is not possible any more to use Acrord32.dll from Reader DC as a reference to a VBA project