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.
> 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)?
>> [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:
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.
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
"Mike Williams" <M...@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>
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
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
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
> 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:
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!
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 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?
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.
"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.
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.
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? -- .NET: It's About Trust! http://vfred.mvps.org
|
