Search for a EXE file and launch?

[Diana (Cda)]

I've been given the advice before on a couple of other scripts to follow the procedure of searching for a file/document and then launching it. In all cases, found something much more direct but now I find I need to know the process on doing the above.

Outlook at my current contract resides here:

C:\Office2000\Office\OUTLOOK.EXE

But I know that I've seen the install folder called something else in other jobs. How would one ask AI to search the C drive for "Outlook.exe" and then launch it, pls?

All the many search messages in the forum I pulled up dealt with some form of global searching, i.e., to replace Windows search. Here it's just to find on app and launch it.

Thanks much!

[weaponx]

The path to the Outlook folder should be in the registry @:

HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\OUTLOOK.EXE\Path

Use RegRead to get the path and append outlook.exe to it for Run()

[Diana (Cda)]

The path to the Outlook folder should be in the registry @:

HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\OUTLOOK.EXE\Path

Use RegRead to get the path and append outlook.exe to it for Run()

Great, thanks. Will give this a try. I don't know the first thing about this new term, "RegRead", but hopefully this will narrow down a search on the forum that will bring up something I can use. Super.

Will report back.

Thanks!

[Diana (Cda)]

<sigh> Well, no luck. I did a search and, quite frankly, didn't know how to work with what I found as the uses for RegRead are so very different from what I need (find, then apply, then launch ...).

Is there any other, easier, approach to take that a scripting dodo-brain like me might figure out?!? <g> I'm not good at figuring new scripts; but I'm great at modifying working script, so perhaps someone can suggest something easier to use that I can pull up working examples of from the forums and modify to my use.

Thanks!

[weaponx]

;With Office 2003 this will return C:\Program Files\Microsoft Office\OFFICE11\ (assuming default installation)
$path = RegRead("HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\OUTLOOK.EXE", "Path")

Run($path & "outlook.exe")oÝ÷ Ù.(!·§¶Úç$¶­¶´ßªZ¶Ú®&èZ±«kj)b%jÈm¢®¶­scµvFöff6R#2F2vÆÂ&WGW&â3¢b3#µ&öw&ÒfÆW2b3#´Ö7&÷6ögBöff6Rb3#´ôdd4Sb3#²77VÖærFVfVÇBç7FÆÆFöâ¢b33c·FÒ&Vu&VBgV÷C´´ÄÒb3#µ6ögGv&Rb3#´Ö7&÷6ögBb3#µvæF÷w2b3#´7W'&VçEfW'6öâb3#´F2b3#´õUDÄôô²äURgV÷C²ÂgV÷CµFgV÷C²¤b7G&æu&vBb33c·FÂfÇC²fwC²gV÷C²b3#²gV÷C²FVâb33c·Ff׳ÒgV÷C²b3#²gV÷C°¥'Vâb33c·FfײgV÷C¶÷WFÆöö²æWRgV÷C²

Edited November 28, 2007 by weaponx

[Diana (Cda)]

Well, I don't get it <lol>. This works. The right Outlook.exe seems to be launched (there are issues here at this place of work between 2 different versions. A "standalone" type of Outlook installation vs. a Citrix-based -- or server-based -- one, which is a joke.) But despite any difficulties that I could have foreseen because of the weird state of affairs here, this did launch and did bring up the right Outlook. I know because when I launched the Citrix-based Outlook at the beginning before they allowed me access to the local one, it wouldn't take my toolbars file (outcmd.dat), etc., whereas the local install works perfectly and as I'm used to.

Big test will be if this works on various computers <crossing fingers>.

Thanks!

p.s., dealing with Outlook 2000 here so despite the references to 2003, seems to work with 2000.

[Diana (Cda)]

Rats, I'm sorry. Small, small hitch. How could we compensate for a process already running. Here's what I mean, to avoid having multiple instances of something, here's what I've learned to use (see example here below):

If Not ProcessExists("PrintKey 2000 v5.05.exe") Then Run(@UserProfileDir & "\Application Data\Microsoft\Internet Explorer\Quick Launch\WXP\APP- PrintKey 2000 v5.05\PrintKey 2000 v5.05.exe", @TempDir, @SW_SHOW)oÝ÷ Øz0r¥w¦rjz®¢Ò6O®²Á1Ëlªê-¶aÆ®¶­scµvFöff6R#2F2vÆÂ&WGW&â3¢b3#µ&öw&ÒfÆW2b3#´Ö7&÷6ögBöff6Rb3#´ôdd4Sb3#²77VÖærFVfVÇBç7FÆÆFöâ¢b33c·FÒ&Vu&VBgV÷C´´ÄÒb3#µ6ögGv&Rb3#´Ö7&÷6ögBb3#µvæF÷w2b3#´7W'&VçEfW'6öâb3#´F2b3#´õUDÄôô²äURgV÷C²ÂgV÷CµFgV÷C²¤b7G&æu&vBb33c·FÂfÇC²fwC²gV÷C²b3#²gV÷C²FVâb33c·Ff׳ÒgV÷C²b3#²gV÷C°¥'Vâb33c·FfײgV÷C¶÷WFÆöö²æWRgV÷C²

My usu. trials just muddled everything <sigh>. <g>

[weaponx]

;With Office 2003 this will return C:\Program Files\Microsoft Office\OFFICE11\ (assuming default installation)
$path = RegRead("HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\OUTLOOK.EXE", "Path")
If StringRight($path, 1) <> "\" Then $path &= "\"
If NOT ProcessExists("outlook.exe") Then
Run($path & "outlook.exe")
EndIf

[Diana (Cda)]

;With Office 2003 this will return C:\Program Files\Microsoft Office\OFFICE11\ (assuming default installation)
$path = RegRead("HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\OUTLOOK.EXE", "Path")
If StringRight($path, 1) <> "\" Then $path &= "\"
If NOT ProcessExists("outlook.exe") Then
Run($path & "outlook.exe")
EndIf

Thank you for this! It works like a charm, as always! <g>

[Diana (Cda)]

;With Office 2003 this will return C:\Program Files\Microsoft Office\OFFICE11\ (assuming default installation)
$path = RegRead("HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\OUTLOOK.EXE", "Path")
If StringRight($path, 1) <> "\" Then $path &= "\"
Run($path & "outlook.exe")

I've been playing around with the script right here above this morning to see how else I can use this.

The 2nd line:

$path = RegRead("HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\OUTLOOK.EXE", "Path")

references an actual key to be used in the search (or whatever it's called). Is there a way to look for just something like "Outlook.exe" _without_ specifying a "key" or path like this?

The reason for this is, I make as many apps that I find can work by themselves into standalones. What I mean by this is that I always install apps to the desktop, copy the folder, then uninstall then see if the copied app works. If it does, I move it over to a different drive. So very few of my programs are actually installed and on the C drive. (An instinctive response to computer crash I had a few years back. Now everything is off C, feel safer; and I back up periodically, too.)

I create associations to make them behave pretty much as if they were installed. However, that's why specifying a registry path such as this seems like it might not work on most of my programs (?). Yet it would be nice to use this feature of AI.

Here is a case in point, I have a freeware MP3 player I really like called CoolPlayer. I "install" it on every friend and family's computer if they ask me to in response to a need for a good and safe player.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Mp3file\shell\play\command]
@="\"M:\\MP3\\mp3Player, CoolPlayer build 216\\APP- CoolPlayer build 215\\coolplayer.exe\" \"%1\""

"Coolplayer.exe" shows up via regedit in various other spots, and many give the full path to the exe, like this but many don't.

Rather than telling AI to search specifically in "HKEY_CLASSES_ROOT\Mp3file\shell\play\command", is there a way to just get it to search for coolplayer.exe where it appears as a full path somehow? I know that this might be a real longshot, but just curious as to how flexible one can make this type of script. I'm guessing that if I always associate it exactly the same way that it may always appear in "HKEY_CLASSES_ROOT\Mp3file\shell\play\command", but would hope to get a script to find it no matter what the case may be.

But coming to the experts here who know much more about these things. Thanks!

[weaponx]

No. The registry is already providing you with a static shortcut to a dynamic path. You need to find these regkeys ahead of time. Any software that gets installed should have a valid path somewhere in the registry, you need to gather this ahead of time. Once you have the registry path for a piece of software it will be the best form of locating the install path.

[GEOSoft]

;With Office 2003 this will return C:\Program Files\Microsoft Office\OFFICE11\ (assuming default installation)
$path = RegRead("HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\OUTLOOK.EXE", "Path")
If StringRight($path, 1) <> "\" Then $path &= "\"
Run($path & "outlook.exe")

I've been playing around with the script right here above this morning to see how else I can use this.

The 2nd line:

$path = RegRead("HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\OUTLOOK.EXE", "Path")

references an actual key to be used in the search (or whatever it's called). Is there a way to look for just something like "Outlook.exe" _without_ specifying a "key" or path like this?

The reason for this is, I make as many apps that I find can work by themselves into standalones. What I mean by this is that I always install apps to the desktop, copy the folder, then uninstall then see if the copied app works. If it does, I move it over to a different drive. So very few of my programs are actually installed and on the C drive. (An instinctive response to computer crash I had a few years back. Now everything is off C, feel safer; and I back up periodically, too.)

I create associations to make them behave pretty much as if they were installed. However, that's why specifying a registry path such as this seems like it might not work on most of my programs (?). Yet it would be nice to use this feature of AI.

Here is a case in point, I have a freeware MP3 player I really like called CoolPlayer. I "install" it on every friend and family's computer if they ask me to in response to a need for a good and safe player.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Mp3file\shell\play\command]
@="\"M:\\MP3\\mp3Player, CoolPlayer build 216\\APP- CoolPlayer build 215\\coolplayer.exe\" \"%1\""

"Coolplayer.exe" shows up via regedit in various other spots, and many give the full path to the exe, like this but many don't.

Rather than telling AI to search specifically in "HKEY_CLASSES_ROOT\Mp3file\shell\play\command", is there a way to just get it to search for coolplayer.exe where it appears as a full path somehow? I know that this might be a real longshot, but just curious as to how flexible one can make this type of script. I'm guessing that if I always associate it exactly the same way that it may always appear in "HKEY_CLASSES_ROOT\Mp3file\shell\play\command", but would hope to get a script to find it no matter what the case may be.

But coming to the experts here who know much more about these things. Thanks!

It's possible but the way you are doing your "Installs" may make it a bit hit and miss.

There are 2 primary registry keys to check using RegEnumKey();

HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\

and

HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\

(I suggest checking in the order I gave)

In App Paths, Check first for the existence of the "Path" value and if it doesn't exist read the default value.

In Uninstall you are looking for the "UninstallString" value. You will have to parse that to get the app path.

The other method is to do a drive search of all "Fixed" drives. This method will find them all. The problem is it's extremely slow. I have some code for doing this. You could make it faster IF you are using a standard folder structure on all drives and on all systems. <drive>\Program Files\<app>

Edited December 1, 2007 by GEOSoft

[Diana (Cda)]

Hmmmm, it's still a rather specific registry solution, though ... Is this the only possible way? There won't be an uninstall option in most of these, btw, so that option will not be available in most cases. After installing an app and making a copy of the install folder, I uninstall and if the app works by itself, I never install ever again. It's surprising just how many programs will work as standalones. Another good chunk that don't work come up with missing dll entries either by error messages or, if I'm determined enough to keep the freeware, will do an install monitor. I'll then try a re-install and then will grab the dll files and keep to dump into the install folder copy to see if it'll run then after uninstalling. After these 2 tricks, there are only a very few handful of apps that still won't work (and my knowledge isn't enough at this point to know what to do further). But I'd say that a good, oh, 95-98% of installed programs, in my experience, work perfectly fine when copied and moved to other computers without installing again (even moving to another partition or computer and they still work! <g>).

The above gives me great flexibility esp. now that I work at the office almost exclusively off my thumb drive. This became even more important when I was floated around last summer and worked on 4 different computers over a period of 3 weeks! But even before, the reason that standalone apps were important to me was that I use so many programs that I got fed up of having to re-install so many after a C drive wipe and OS re-install (I could run my computer into the ground in as little as 6 months due to periods where I'm trying so many apps, system becomes corrupted quite quickly). Even my usual year and a half till crashing hassle was greatly reduced by running most of these standalones off of a partition. Something I appreciated once again when I moved to this new computer last year and all I had to do was dump my F programs partition contents into my current M one. Up and running in literally minutes.

So I'm just curious since I'd like to become as independent as possible of the usu. Windows limitations re drive letters and such. Also, if I can get a more efficient and less limited EXE search and launch, the script will become one that can be used on any host computer, so again, making working off the flash drive more independent. I know it might not be possible, but what I've found is that the registry seems to not always put things exactly where you might expect each time depending on how one "registers" the program. Sometimes Coolplayer, for example, has come under the obvious MP3 registry entry but other times I've found it in weird places (esp. since I have to do so much more in the registry with this stupid XP that constantly disobeys me! <g>) If I limit the script to a specific entry in the registry (a "key" or whatever), it might not always work. I may be wrong since my registry knowledge is still limited, but hope you get my drift. So hoping that someone might know of an alternative to searching the registry for the EXE location and launching. Thx much.

Edited December 9, 2007 by Diana (Cda)

[GEOSoft]

I have a recursive file search function and another to check if a drive is USB. I'll dig them out and PM them to you but that won't likely be until tomorrow.

Also You might want to take a look at using Portable Apps or if this is a known list of software then build a loader/launcher into the thumb drive.

[Diana (Cda)]

I have a recursive file search function and another to check if a drive is USB. I'll dig them out and PM them to you but that won't likely be until tomorrow.

Also You might want to take a look at using Portable Apps or if this is a known list of software then build a loader/launcher into the thumb drive.

Thanks! That's very kind of you.

Portable apps don't have anything that I can use for this one situation. I've tried many items but for this particular thing, it's something that's a bit more customized or flexible that's required. I'm thinking of something I can deploy to any family member that needs it. I have a couple of different items that I can use this type of script with _but_ would prefer to make it as generic a script as possible. One that finds the exe since that is about the only thing that won't change whereas everything else may (path and drive letter, etc.).

I use the great freeware launcher PStart myself for the USB flash drive and it's great. But that's strictly for the flash drive. Hope to have a script that will work on anything, flash drive _or_ hard drive. Again, if it isn't do-able, I can live with that. I'm just experimenting/researching trying to find a solution to this that will cover as broad a set of conditions as possible.

Despite PStart and how great an app it is, don't want to start messing with having it launch things from the host computer. That will make things confusing <g>.

Thanks!

Edited December 10, 2007 by Diana (Cda)