Find application

Topic

New Reply

I’m working behind an Access 97 database on a network.
I’d like to be able to check the user’s computer to see if certain applications are installed. If they’re not, I will prompt them on how to get them.
Any ideas?
Please keep it simple or please spell it out, I’m pretty new to VBA.

Reply | Quote

Replies

Hi Bill,

Maybe the simplest way would be to check whether the applications’ “exe.” files exist. There are a few different ways to search for files on a computer; an easy way was described by Geoff Whitfield in a recent post on another thread (you could substitute the path for the application file):

[indent]

---

You can check if a file exists by a “Dir” command:

if Dir(“c:mydocumentssomething.dot”) “” then
msgbox “something.dot exists”
end if

---

[/indent](although I do recommend starting all keywords with capitals )

Reply | Quote

Your suggestion would be fine except that I cannot be sure that a given application was installed to its default directory. I was hoping for some way to search the hard drive or possibly the (Registry?) to locate the executable or if an executable is assigned to open a particular extension like ,.doc, .bmp, .dwg, etc.

Reply | Quote

Edited by Gary Frieder on 01/02/16 01:49.

The following example illustrates one way to search a drive for an executable, without first specifying its location (it will return the location information however):

Sub FileSearchForEXE()
Dim n As Long
Dim strFoundList As String
Dim FS As FileSearch
Set FS = Application.FileSearch
With FS
    .NewSearch
    .LookIn = "C:"
    .SearchSubFolders = True
    .FileName = "winword.exe"
    .Execute
    If .Execute > 0 Then
        For n = 1 To .FoundFiles.Count
            strFoundList = strFoundList & vbCr & .FoundFiles(n)
        Next n
        MsgBox strFoundList
    End If
End With
Set FS = Nothing
End Sub

Interestingly, although “C” drive is specified, this code searched both partitions (C and D) of my hard drive.

Also by the way, this code can take a long time to run.

[Just an added note (and to keep Chris G. happy): this sub could easily be turned into a function, where you pass it the name of the app’s .exe file – this would be a better approach particularly if you were having it do multiple searches.]

Hope this helps,
Gary

Reply | Quote

You might want to include another note–you needed an application object library reference or an Office library reference set in Office 97 apps to use FileSearch. And it wasn’t available from the Access 97 application library.

Reply | Quote

>[Just an added note (and to keep Chris G. happy): this sub

I saw that! We’ll see you in my Files.dot template, once we’ve completed Utils.dot!

Actually, I went and looked at my code there and it’s close to identical to yours! We must have pasted from the same Help file (grin!). I have similar code in my Instl.dot, one of whose functions is to sniff out potentially conflicting templates during the installation process.

Reply | Quote

I appreciate the information. But I have the fastest computer in the office and it took almost 40 seconds just to find the Word.exe. I was hoping for something that could do 3 or 4 searches in the background while the form was loading. But this code will be useful for some other things I’m working on.
I had to make an alteration to the code before it ran, the system would not accept the Dim FS As FileSearch and Set FS = Application.FileSearch, using With Application.FileSearch was OK. Was I doing something wrong?

Reply | Quote

Bill,

The length of time it takes to do the search is due to the fact that it’s searching your entire hard drive – I bet your computer is not only the fastest, but also has the largest HD, no? .

The alteration you needed to make in the code probably relates to the point Charlotte made, which is that FileSearch was not fully/inconsistently implemented in some Office 97 apps/versions. The code I posted was dashed off using Word 2000 – I vaguely remembered having to do it a little differently in Word 97 but didn’t check.

Gary

Reply | Quote

Right all around. That translates to less than a second per gig search time. Not bad when you look at it that way.

Reply | Quote

>ice and it took almost 40 seconds just to find the Word.exe.

My experience too. I have code (Fun4X) that loads fonts and loads ICOn files for GUIs. Forty seconds is about par for the course. I have two 20G drives (24 2G partitions) on a 233MHz running the original Win95.

Let me know if you find any background-file-locate process.

Reply | Quote

Got it! A friend of mine found this somewhere on the internet a while ago, but he knows less about coding than I do. And I have to admit, I know very little.
Sorry Chris if this isn’t more along the lines of what you were looking for, but it works great for me. Except one thing, if the same application is installed in two different folders an the same hard drive, this code returns a null string. Do you know how to change that so it recognizes the existence of an application no matter how many instances occur?

Private Declare Function FindExecutableA Lib “shell32.dll” (ByVal lpFile As String, ByVal lpdirectory As String, ByVal lpResult As String) As Long

Private Const MAX_FILENAME_LEN = 256

Public Function FindExecutable(s As String) As String
Dim i As Integer
Dim s2 As String

s2 = String(MAX_FILENAME_LEN, 32) & Chr$(0)

i = FindExecutableA(s & Chr$(0), vbNullString, s2)

If i > 32 Then
FindExecutable = Left$(s2, InStr(s2, Chr$(0)) – 1)
Else
FindExecutable = “”
End If

End Function

Reply | Quote

>Function FindExecutableA Lib “shell32.dll”

I get a “syntax error” with this function. Please What do I add via VBE Tools, references to get it going? Thanks.

Reply | Quote

The declaration probably should look like this:

Declare Function apiFindExecutable Lib “shell32.dll” Alias _
“FindExecutableA” (ByVal lpFile As String, ByVal lpDirectory _
As String, ByVal lpResult As String) As Long

There is a possible problem with this approach if the registry key wasn’t set up properly by the app’s installer; see KB article Q140724.

Jay

Reply | Quote

This is probably the easiest way:

Private Function GetAppPath(ByVal strExecutable As String)
‘This function retrieves the full pathname of an
‘installed application from the Windows Registry
On Error Resume Next
Dim objFSO As Object, objShell As Object
Set objFSO = CreateObject(“Scripting.FileSystemObject”)
Set objShell = CreateObject(“WScript.Shell”)
GetAppPath = objShell.RegRead(“HKLMSoftwareMicrosoftWindowsCurrentVersionApp Paths” & strExecutable & “”)
If Not objFSO.FileExists(GetAppPath) Then GetAppPath = vbNullString
Set objShell = Nothing
Set objFSO = Nothing
End Function

Usage:

Sub GetPath()
Debug.Print GetAppPath(“winword.exe”)
End Sub

Reply | Quote

Don,

Just want to confirm that this works great – much faster to retrieve info from the Registry than to scan an entire hard drive.

If we needed to find apps that might be on a hard drive, but not necessarily registered, then I guess we’d still be out in the cold – not clear from the original post which was required (i.e. how strictly was the term “installed” being used?).

Can you point to any good sources of information for learning more about using the Scripting File System Object?

Thanks,
Gary

Reply | Quote

>f we needed to find apps that might be on a hard drive, but not necessarily registered, t

Do the two-step.

Look for it in the registry. If it exists there, check the stated path on the hard drive. Found it? Good. Done in record time.

If not in the registry, then fall back to the 40-second brute force approach, which is guaranteed.

Reply | Quote

That’s nice!

It worked great for me.

Any feedback?

Reply | Quote

Don,
Very nice piece of code. The only drawback I see is that a lot of users are disabling/renaming windows script, due to the proliferation of viruses that use it (Not taking a position either way on that issue ). But, if present, that code works well.

With that in mind (and borrowing heavily from your concept), how about the following:

Function strAppExists(ByVal strAppName As String)

    strAppExists = System.PrivateProfileString("", "HKEY_LOCAL_MACHINESoftware" _
    & "MicrosoftWindowsCurrentVersionApp Paths" & strAppName, "Path")

End Function

Will return either the app path, or “” if not found. It could then be called by something similar to:

Function CheckApp()
Dim strCheckApp, strAppName
strAppName = "excel.exe"
strCheckApp = strAppExists(strAppName)

If strCheckApp = "" Then
    MsgBox UCase(strAppName) & " not found"
Else
    MsgBox UCase(strAppName) & " found installed at " & strCheckApp
End If

End Function

Reply | Quote

JamesB,
I get a variable not assigned for System in:
strAppExists = System.PrivateProfileString
how do I set that up?

I’m seeing some interesting code posted. It seems that there are several possibilities here. But one of the specific executables I wanted to locate is, for some reason, not found except in a file search. It is “voloview.exe” this is a .dwg viewer from Autodesk, the makers of AutoCAD. It is on the “Add/Remove Programs” list, doesn’t this mean its in the registry?

Reply | Quote

I’ve attached the code as a text file, to be sure it translated correctly to your machine.

Also, using a registry search is a sometimes “iffy” thing. Programs can get away with not having entries where they are supposed to.

It really depends on what program, and how it is entered in the registry. Some other keys that might have value (but should be tested thoroughly):

HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionUninstall
(add the name of the program from the Add/Remove Programs box)
in the function this would be:

strAppExists = System.PrivateProfileString(“”, “HKEY_LOCAL_MACHINE _
& SoftwareMicrosoftWindowsCurrentVersionUninstall” & strAppName, “Display Name”)
‘(where strAppName is the name of the program from the Add/Remove Programs box)

You can also try checking the program associated with the file extension.
To get the right key, look at:

HKEY_CLASSES_ROOT.dwg
on the right, it should list the Default Value as something like dwgfile

then further down the reg key, look for:

HKEY_CLASSES_ROOTdwgfileshellopencommand
(replacing dwgfile with the actual name, if different)

This will tell you what program is associated to opening this file type.
This may be some trial and error, to find where your program reference actually is.

Reply | Quote

You will need a reference set to the Office object library to use FileSystemObject , at leastwith Access, unless you have a reference set the the Microsoft Scripting runtime library. If you use late binding, as in this example, you don’t need the scripting library reference.

Reply | Quote

Wrong!

I need to learn to leave well alone.

In my infinite wisdom I decided to place a “str” prefix in front of all the functions that return string results, except, of course, where the alias is quoted. I’m not THAT smart!

Once I threw out my modified version and pasted in the code as presented on this forum, it worked just fine!

permission hereby granted to bug me about it all (grin!)

Reply | Quote