FindExecutable API call fails for ACCDB file extensions

[Tony Toews [MVP]]

Folks

The API call "FindExecutable: Find Exe Associated with a Registered
Extension"
http://vbnet.mvps.org/index.html?code/system/findexecutable.htm fails
on a file with the ACCDB extension. The API call does work fine with
the MDB extension. Clicking on an ACCDB file in Windows Explorer
does work.

This is a on a new, fresh Win XP/Access 2007 install with nothing else
on the system and no uninstalls, etc.

This behavior puzzles me greatly.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Granite Fleet Manager http://www.granitefleet.com/

[mayayana]

>
> The API call "FindExecutable: Find Exe Associated with a Registered
> Extension"
> http://vbnet.mvps.org/index.html?code/system/findexecutable.htm fails
> on a file with the ACCDB extension. The API call does work fine with
> the MDB extension. Clicking on an ACCDB file in Windows Explorer
> does work.

Interesting. A look under HKEY_CLASSES_ROOT
should tell something. I wonder if it has to do
with the 5-character extension. It's always been
the MS standard to use 3. It seems odd that they've
broken with that. Maybe FindExecutable is limited
to 3 characters and either finds no match or finds
two (if there's a .acc key)?

[Mike Williams]

"mayayana" <mayaX...@rcXXn.com> wrote in message
news:eSxNCcHN...@TK2MSFTNGP05.phx.gbl...

>> [Tony Toews said] The API call FindExecutable fails on

>> a file with the ACCDB extension. The API call does work
>> fine with the MDB extension. Clicking on an ACCDB file
>> in Windows Explorer does work.
>

> [Mayayana said] Interesting. A look under HKEY_CLASSES_ROOT

> should tell something. I wonder if it has to do with the
> 5-character extension. It's always been the MS standard to use 3.
> It seems odd that they've broken with that.

They can't have done, because long file extensions have been permitted for a
long time now and they use four or more characters a lot themselves these
days in their own extensions (docx, pptx, etc).

> Maybe FindExecutable is limited to 3 characters and either
> finds no match or finds two (if there's a .acc key)?

Actually I've just been trying a dozen or so different extensions (including
the OP's .accdb extension) by registering them with Windows in the normal
way so that they open by default with a specific program and all of them
work fine as far as Windows Explorer is concerned. However, the
FindExecutable function seems to have trouble with many of them. For
example, the following registered extensions produced the following result
when using the FindExecutable function:

.accdb FAILED
.abcde FAILED
.bcdef FAILED
.pqrst SUCCEEDED

There were all sorts of strange anomilies where certain file extensions were
found by FindExecutable and other file extensions were not, with (up to now)
no apparent ryhme or reason behind it. For example neither abcde nor pqrst
had any other extension registered with similar preceeding characters on my
machine, and in both cases the registry entry in HKCU after manually
registering them appeared identical, and yet one failed with FindExecutable
whereas the other succeeded. In all cases the file extension was found
properly by Windows Explorer and the file opened with the registered default
program when double clicked.

Unless I've missed something obvious I think this needs a little more
investigation.

Mike

[Nobody]

"Mike Williams" <Mi...@WhiskyAndCoke.com> wrote in message
news:eshjXHJ...@TK2MSFTNGP06.phx.gbl...

>
> .accdb FAILED
> .abcde FAILED
> .bcdef FAILED
> .pqrst SUCCEEDED

I tested ".accdb" on Windows 98 and XP Pro. In Windows 98, it succeeded, in
XP Pro, it failed. I tried to restart XP just in case there is some caching
going on, but got the same result. I used all lower case letters, but I
tried renaming the file with all upper case, and using upper case in the
call, with the same failed result, so it's not a case issue. I guess we need
to upgrade to Windows 98. Here is my code:

Option Explicit

Private Const MAX_PATH = 260

Private Const SE_ERR_NOASSOC = 31
Private Const SE_ERR_FNF = 2 ' file not found
Private Const SE_ERR_PNF = 3 ' path not found
Private Const SE_ERR_OOM = 8 ' out of memory

Private Declare Function FindExecutable Lib "shell32.dll" Alias _
"FindExecutableA" (ByVal lpFile As String, ByVal lpDirectory As String,
_
ByVal lpResult As String) As Long

Private Sub Form_Click()
Dim ret As Long
Dim sResult As String

sResult = String(100, 0)

ret = FindExecutable("C:\x.accdb", vbNullString, sResult)
Print "FindExecutable returned " & ret & ", LastDllError: " & _
Err.LastDllError
sResult = TrimNull(sResult)
Print "sResult: '" & sResult & "'"
End Sub

Private Function TrimNull(s As String) As String
Dim pos As Long

pos = InStr(s, Chr(0))

If pos <> 0 Then
TrimNull = Trim(Left(s, pos - 1))
Else
TrimNull = Trim(s)
End If

End Function

[Tony Toews [MVP]]

"Mike Williams" <Mi...@WhiskyAndCoke.com> wrote:

>Actually I've just been trying a dozen or so different extensions (including
>the OP's .accdb extension) by registering them with Windows in the normal
>way so that they open by default with a specific program and all of them
>work fine as far as Windows Explorer is concerned. However, the
>FindExecutable function seems to have trouble with many of them.

Thanks for testing this. Glad it's not just me. <smile>

[Nobody]

It seems that FindExecutable() is unreliable for extensions with more than 3
letters. Here is a version based on AssocQueryString(), this function
doesn't require an existing file:

Option Explicit

Private Const MAX_PATH = 260

' AssocQueryString
Enum ASSOCF
ASSOCF_INIT_NOREMAPCLSID = &H1
ASSOCF_INIT_BYEXENAME = &H2
ASSOCF_OPEN_BYEXENAME = &H2
ASSOCF_INIT_DEFAULTTOSTAR = &H4
ASSOCF_INIT_DEFAULTTOFOLDER = &H8
ASSOCF_NOUSERSETTINGS = &H10
ASSOCF_NOTRUNCATE = &H20
ASSOCF_VERIFY = &H40
ASSOCF_REMAPRUNDLL = &H80
ASSOCF_NOFIXUPS = &H100
ASSOCF_IGNOREBASECLASS = &H200
End Enum
Enum ASSOCSTR
ASSOCSTR_COMMAND = 1
ASSOCSTR_EXECUTABLE
ASSOCSTR_FRIENDLYDOCNAME
ASSOCSTR_FRIENDLYAPPNAME
ASSOCSTR_NOOPEN
ASSOCSTR_SHELLNEWVALUE
ASSOCSTR_DDECOMMAND
ASSOCSTR_DDEIFEXEC
ASSOCSTR_DDEAPPLICATION
ASSOCSTR_DDETOPIC
ASSOCSTR_INFOTIP
ASSOCSTR_QUICKTIP
ASSOCSTR_TILEINFO
ASSOCSTR_CONTENTTYPE
ASSOCSTR_DEFAULTICON
ASSOCSTR_SHELLEXTENSION
ASSOCSTR_MAX
End Enum
Private Declare Function AssocQueryString Lib "shlwapi.dll" Alias _
"AssocQueryStringA" (ByVal flags As ASSOCF, ByVal str As ASSOCSTR, _
ByVal pszAssoc As String, ByVal pszExtra As String, _
ByVal pszOut As String, ByRef pcchOut As Long) As Long

Private Sub Form_Load()
Debug.Print "GetAssociatedEXE: '" & GetAssociatedEXE(".accdb") & "'"
End Sub

Private Function GetAssociatedEXE(sExtension As String) As String

Dim ret As Long
Dim sResult As String

Dim pcchOut As Long

sResult = String(MAX_PATH, 0)
pcchOut = Len(sResult)

ret = AssocQueryString(0, ASSOCSTR_EXECUTABLE, sExtension, "open", _
sResult, pcchOut)
Debug.Print "AssocQueryString returned " & ret & ", LastDllError: " & _
Err.LastDllError
If ret = 0 Then
' AssocQueryString succeeded
sResult = TrimNull(sResult)
GetAssociatedEXE = sResult
End If
End Function

[Mike Williams]

"Nobody" <nob...@nobody.com> wrote in message
news:OMU2RuK...@TK2MSFTNGP06.phx.gbl...

> It seems that FindExecutable() is unreliable for extensions with more than
> 3 letters. Here is a version based on
> AssocQueryString(), this function doesn't require an
> existing file:

Thanks. That works fine. I did actually notice the reference to
AssocQueryString when I was checking the details for FindExecutable on:

http://msdn.microsoft.com/en-us/library/bb776419(VS.85).aspx

According to that page you should use FindExecutable if you want to retrieve
the executable associated with a document file and AssocQueryString if you
want to find the path of an executable. Since FindExecutable (when it
works!) actually does return the path and filename of the executable
associated with a document then I assumed AssocQueryString was designed to
be used to return the full path of a registered executable when you passed
it only the name of the executable, and so I never gave it a try. Thanks for
the clarification and the code.

I really do wish that Micro$oft would learn to write help files in such a
way that they do actually help people!

Mike

[Karl E. Peterson]

Nobody wrote:
> It seems that FindExecutable() is unreliable for extensions with more than 3
> letters. Here is a version based on AssocQueryString(),

Have you found it unreliable in any manner other than not returning an answer? (I'm
assuming it's not returning a *wrong* answer, is it?) I'm thinking, maybe call the
routine with FindExecutable first, then fall back to AssocQueryString if that first
one doesn't work. Reason being, AssocQueryString requires IE5 on older systems
(NT4/9x) and you resported (in another post) that FindExecutable seems to work okay
at 98?
--
.NET: It's About Trust!
http://vfred.mvps.org

[Nobody]

"Karl E. Peterson" <ka...@exmvps.org> wrote in message
news:%23J71P$wNKH...@TK2MSFTNGP02.phx.gbl...

I don't know if AssocQueryString is always reliable, I don't use it often,
but FindExecutable works with 4 letters extensions(ACCDB) on Windows 98, but
not on XP.

[Tony Toews [MVP]]

"Nobody" <nob...@nobody.com> wrote:

>It seems that FindExecutable() is unreliable for extensions with more than 3
>letters.

So Karl wrote an article on this topic. Classic VB Corner
Finding an Associated Executable

After using a given API for a decade or more, you tend to just take it
for granted that it works. Karl Peterson shows how he worked around a
challenge when it didn't.

http://visualstudiomagazine.com/articles/2009/10/13/finding-an-associated-executable.aspx

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

[Karl E. Peterson]

Tony Toews [MVP] wrote:
> "Nobody" <nob...@nobody.com> wrote:
>
>>It seems that FindExecutable() is unreliable for extensions with more than 3
>>letters.
>
> So Karl wrote an article on this topic. Classic VB Corner
> Finding an Associated Executable
>
> After using a given API for a decade or more, you tend to just take it
> for granted that it works. Karl Peterson shows how he worked around a
> challenge when it didn't.
>
> http://visualstudiomagazine.com/articles/2009/10/13/finding-an-associated-executable.aspx

Yes, Tony beat me back here... Thanks to all in this thread for the inspiration on
that one! What a weird twisted little error that was, huh?

[Tony Toews [MVP]]

"Karl E. Peterson" <ka...@exmvps.org> wrote:

>Yes, Tony beat me back here... Thanks to all in this thread for the inspiration on
>that one! What a weird twisted little error that was, huh?

Sure would be nice to know why it was so inconsistent.