API code to obtain Acrobat Reader Shell Path from the registry

[CDMAPoster]

I have changed how I get the shell path for Acrobat Reader based on
code posted by John deKrafft. Does anyone see any problems with this
code running on various Windows OS's?

'--Begin Module Code
'Support functions and constants for reading a string from the
registry
'I have modified the code posted by John deKrafft slightly
'----
Declare Function RegQueryValueEx Lib "advapi32.dll" Alias
"RegQueryValueExA" (ByVal hKey As Long, ByVal lpValueName As String,
ByVal lpReserved As Long, lpType As Long, lpData As Any, lpcbData As
Long) As Long
Declare Function RegOpenKeyEx Lib "advapi32.dll" Alias
"RegOpenKeyExA" (ByVal hKey As Long, ByVal lpSubKey As String, ByVal
ulOptions As Long, ByVal samDesired As Long, phkResult As Long) As
Long
Declare Function RegCloseKey Lib "advapi32.dll" (ByVal hKey As Long)
As Long

Public Const SYNCHRONIZE As Long = &H100000
Public Const STANDARD_RIGHTS_ALL As Long = &H1F0000
Public Const KEY_QUERY_VALUE As Long = &H1
Public Const KEY_SET_VALUE As Long = &H2
Public Const KEY_CREATE_SUB_KEY As Long = &H4
Public Const KEY_ENUMERATE_SUB_KEYS As Long = &H8
Public Const KEY_NOTIFY As Long = &H10
Public Const KEY_CREATE_LINK As Long = &H20
Public Const KEY_ALL_ACCESS As Long = ((STANDARD_RIGHTS_ALL Or _
KEY_QUERY_VALUE Or KEY_SET_VALUE Or KEY_CREATE_SUB_KEY Or _
KEY_ENUMERATE_SUB_KEYS Or KEY_NOTIFY Or KEY_CREATE_LINK) And (Not
SYNCHRONIZE))
Public Const ERROR_SUCCESS As Long = 0
Public Const HKEY_LOCAL_MACHINE As Long = &H80000002
Public Const HKEY_CLASSES_ROOT As Long = &H80000000 'Added

Public Function GetRegistryString(lngKey As Long, strSubKey As String,
strValue As String) As String
Dim lngDataType As Long
Dim lngDataLength As Long
Dim strDataString As String
Dim lngResult As Long
Dim lngHandle As Long
Const StringLength = 150

strDataString = Space(StringLength)
lngDataType = 0
lngDataLength = CLng(StringLength)
lngResult = RegOpenKeyEx(lngKey, strSubKey, 0, KEY_ALL_ACCESS,
lngHandle)
If lngResult <> ERROR_SUCCESS Then
GetRegistryString = "Error"
Exit Function
End If
lngResult = RegQueryValueEx(lngHandle, strValue, 0, lngDataType, ByVal
strDataString, lngDataLength)
If lngResult <> ERROR_SUCCESS Then
GetRegistryString = "Error"
lngResult = RegCloseKey(lngHandle)
Exit Function
End If
strDataString = Left(strDataString, lngDataLength)
'Clean the string in a way that works for either registry key option
used in GetAcrobatReaderShellPath()
'Remove a doublequote from the beginning of the string, if present
If Len(strDataString) > 0 Then
If Left(strDataString, 1) = Chr(34) Then strDataString =
Right(strDataString, Len(strDataString) - 1)
End If
'Delete an extra character if present
If Right(strDataString, 3) <> "exe" And Len(strDataString) > 0 Then
strDataString = Left(strDataString, Len(strDataString) - 1)
'Remove a doublequote from the end of the string, if present
If Len(strDataString) > 0 Then
If Right(strDataString, 1) = Chr(34) Then strDataString =
Left(strDataString, Len(strDataString) - 1)
End If
'Make sure the string ends with "exe"
If Right(strDataString, 3) = "exe" Then
GetRegistryString = Left(strDataString, lngDataLength)
Else
GetRegistryString = "Error"
End If
lngResult = RegCloseKey(lngHandle)
End Function
'----

Public Function GetAcrobatReaderShellPath() As String
'Note: The better key to use may be HKEY_CLASSES_ROOT\Software\Adobe
\Acrobat\Exe
'since a user might have Acrobat installed and uses it instead of
Acrobat Reader
'If Acrobat is not installed it seems to get set to the Acrobat Reader
path
'GetAcrobatReaderShellPath = GetRegistryString(HKEY_LOCAL_MACHINE,
"SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\AcroRd32.exe",
"")
GetAcrobatReaderShellPath = GetRegistryString(HKEY_CLASSES_ROOT,
"Software\Adobe\Acrobat\Exe", "")
End Function
'--End Module Code

Also, is there an even better registry key to use?

Thanks,

James A. Fortune
(e-mail address removed)
(e-mail address removed)

 

[Douglas J. Steele]

Do you really need to know the path? Can't you simply use ShellExecute
(http://www.mvps.org/access/api/api0018.htm at "The Access Web") or
Application.FollowHyperlink to open the PDF file?

Assuming you have an actual PDF file to which you can point, you can use the
code in http://www.mvps.org/access/api/api0023.htm or what Randy Birch has
at http://vbnet.mvps.org/code/system/findexecutable.htm (they both use the
same FindExecutable API call)

 

[CDMAPoster]

Do you really need to know the path? Can't you simply use ShellExecute
(http://www.mvps.org/access/api/api0018.htmat "The Access Web") or
Application.FollowHyperlink to open the PDF file?

Assuming you have an actual PDF file to which you can point, you can use the
code inhttp://www.mvps.org/access/api/api0023.htmor what Randy Birch has
athttp://vbnet.mvps.org/code/system/findexecutable.htm(they both use the
same FindExecutable API call)

Besides the drawback of having a copyright notice for even some really
simple API functions at mvps.org, I can't imagine that the
FindExecutable API is any more reliable than having the actual path in
hand. I try not to look at or use much mvps.org code but that's
basically to prompt me to find different ways of doing things rather
than from any philosophical differences. Using FollowHyperlink is a
good idea, but it's not one that I expect to use anytime soon. I
think I'll use more mvps.org code in the future due to the contents of
a fortune cookie I read recently, but I'll not be using much, and not
soon. Thanks for pointing out some alternate methods. I'll just test
what I wrote on the OS's here.

James A. Fortune
(e-mail address removed)

 

[Douglas J. Steele]

Besides the drawback of having a copyright notice for even some really
simple API functions at mvps.org,

That strikes me as a petty complaint. You're free, of course, to go to MSDN,
read the specs for the API and write your own code.

I can't imagine that the
FindExecutable API is any more reliable than having the actual path in
hand.

FindExecutable gives you the actual path, and it's a heck of a lot simpler
code than speleunking through the registry. YMMV.

 

[CDMAPoster]

That strikes me as a petty complaint. You're free, of course, to go to MSDN,
read the specs for the API and write your own code.

I'll do that. I think it's petty to put the copyright notice on any
of the code, except that it's "especially" petty to put it on simple
code, but I believe the authors have the right to do so. I have the
right not to use code with such restrictions. Maybe I'm being petty.

FindExecutable gives you the actual path, and it's a heck of a lot simpler
code than speleunking through the registry. YMMV.

The speleunking only has to be done once. It just works after that.
I wouldn't be surprised if the FindExecutable API uses the same kind
of key path to get its results although I haven't checked the docs.
You suggest that the mvps.org code is more reliable. That might be
true. I don't write error-free code, but I've also seen silly errors
posted in newsgroups by some of the regulars at mvps.org. I would
never use mvps.org code in an application blindly without checking it
out first. I advise the same for others who use code I post. I think
the way we avoid using each other's code has been a positive thing so
far. I respect your ability and willingness to answer newsgroup
posts. I like to work things out for myself. That should be apparent
to everyone by now. My guess is that others who read what we post
understand the dynamics of what is happening better than we do. We're
too busy concentrating on answers. I'm suggesting that for some
problems in the future we work together to obtain the best possible
combination of ideas to solve them.

James A. Fortune
(e-mail address removed)

P.S., the part about the fortune cookie was sincere. I don't let
fortune cookies tell me how to live, but sometimes they shed light on
hidden truth.

 

[Tony Toews [MVP]]

I don't let
fortune cookies tell me how to live, but sometimes they shed light on
hidden truth.

I read of an interesting problem involving fortune cookies a while
back. Turns out many more people than usual chose the winning numbers
in a lottery, possibly in New Jersey. The lottery folks were highly
suspicious of this thinking that somehow "a fix was in." Turns out
that almost all of those people chose their numbers from the back of
the slip of paper of fortune cookies. That in turn was followed up to
the one fortune cookie vendor who shrugged and said he prints
thousands of slips with the same number on the back.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm