[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Anton

6/13/2011 11:23:00 PM

I am trying to do a File Exists function.

I don't know where the file is so I am searching the registry for

"Applications\*\shell\open\command"

Where * gets replaced by the file name e.g. WinZip32.exe

I then parse the registry returned value.
Sometimes I get a short path so I convert that to a long path.

Then with the parsed Drive:\Path\AppName.Ext

I do a normal FileExists() just to make sure it is still there using
the fill Drive:\Path\FileName.Ext.
This all works fine.

So my questions are:
(1) isn't there a simpler way?
(2) does the ambiguous registry search string value always work for
doing what I want?
"Applications\*\shell\open\command"
Or are there other incarnations that I need to also use?


9 Answers

Karl E. Peterson

6/14/2011

0

BeeJ wrote on 6/13/2011 :
> I am trying to do a File Exists function.

No, you're not.

--
..NET: It's About Trust!
http://vfre...


Dee Earley

6/14/2011 12:36:00 PM

0

On 14/06/2011 00:22, BeeJ wrote:
> I am trying to do a File Exists function.
>
> I don't know where the file is so I am searching the registry for
>
> "Applications\*\shell\open\command"
>
> Where * gets replaced by the file name e.g. WinZip32.exe
>
<SNIP>
>
> So my questions are:
> (1) isn't there a simpler way?

There is, ask the author if there is an official way to determin
if/where their app is installed.

> (2) does the ambiguous registry search string value always work for
> doing what I want?

No, it just happens to work on a tiny fraction of apps that use their
exe name for the progID for file registration.
If they 1) use a normal progid, 2) don't have a file regsitration, then
this won't work.

--
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team
http://www.icode.co.uk...

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)

Anton

6/14/2011 10:08:00 PM

0

so how does windows find an executable if all it has is the app.exe or
app.com name the way that Run or whatever does? If indexing is off on
a drive it can't use that. I have tried doing a Run on a drive that is
not indexed and it finds it very quickly for "installed" apps. What
method is it using? for apps that are copied and "registered" it finds
those too.


ralph

6/14/2011 10:53:00 PM

0

On Tue, 14 Jun 2011 15:07:30 -0700, BeeJ <nospam@spamfree.com> wrote:

>so how does windows find an executable if all it has is the app.exe or
>app.com name the way that Run or whatever does? If indexing is off on
>a drive it can't use that. I have tried doing a Run on a drive that is
>not indexed and it finds it very quickly for "installed" apps. What
>method is it using? for apps that are copied and "registered" it finds
>those too.
>

Look up the "Path evnvironmental variable" online, or Windows help.

-ralph

Darksaint

6/14/2011 11:15:00 PM

0

ralph wrote:

> On Tue, 14 Jun 2011 15:07:30 -0700, BeeJ <nospam@spamfree.com> wrote:
>
>
>>so how does windows find an executable if all it has is the app.exe or
>>app.com name the way that Run or whatever does? If indexing is off on
>>a drive it can't use that. I have tried doing a Run on a drive that is
>>not indexed and it finds it very quickly for "installed" apps. What
>>method is it using? for apps that are copied and "registered" it finds
>>those too.
>>
>>
>
> Look up the "Path evnvironmental variable" online, or Windows help.



My thunder stole... :)

AFAIK that's it for "Run" if try to start a program that way manually or
from a command line.

If from a shortcut, the location is included there so can get away w/o
installing the directory in the path but won't work from RUN unless
explicitly enter subdir or use Browse to locate the .exe or similar.

--



(nobody)

6/15/2011 1:25:00 AM

0

ralph wrote:
> On Tue, 14 Jun 2011 15:07:30 -0700, BeeJ <nospam@spamfree.com> wrote:
>
>> so how does windows find an executable if all it has is the app.exe
>> or app.com name the way that Run or whatever does? If indexing is
>> off on a drive it can't use that. I have tried doing a Run on a
>> drive that is not indexed and it finds it very quickly for
>> "installed" apps. What method is it using? for apps that are copied
>> and "registered" it finds those too.
>>
>
> Look up the "Path evnvironmental variable" online, or Windows help.

Actually there is a simple API function for this, SearchPath().


ralph

6/15/2011 2:34:00 AM

0

On Tue, 14 Jun 2011 21:24:36 -0400, "Nobody" <nobody@nobody.com>
wrote:

>ralph wrote:
>> On Tue, 14 Jun 2011 15:07:30 -0700, BeeJ <nospam@spamfree.com> wrote:
>>
>>> so how does windows find an executable if all it has is the app.exe
>>> or app.com name the way that Run or whatever does? If indexing is
>>> off on a drive it can't use that. I have tried doing a Run on a
>>> drive that is not indexed and it finds it very quickly for
>>> "installed" apps. What method is it using? for apps that are copied
>>> and "registered" it finds those too.
>>>
>>
>> Look up the "Path evnvironmental variable" online, or Windows help.
>
>Actually there is a simple API function for this, SearchPath().
>

As SearchPath() uses either a given path, or the default Path as given
in the Registry as a reflection of the Path Environment variable, and
the OP was asking for the "method" used, I felt it would be better to
go direct to the "source" and hopefully skip subsequent questions.

We'll know soon enough. <g>

-ralph

Karl E. Peterson

6/15/2011 7:44:00 PM

0

Nobody wrote :
> ralph wrote:
>> On Tue, 14 Jun 2011 15:07:30 -0700, BeeJ <nospam@spamfree.com> wrote:
>>
>>> so how does windows find an executable if all it has is the app.exe
>>> or app.com name the way that Run or whatever does? If indexing is
>>> off on a drive it can't use that. I have tried doing a Run on a
>>> drive that is not indexed and it finds it very quickly for
>>> "installed" apps. What method is it using? for apps that are copied
>>> and "registered" it finds those too.
>>>
>>
>> Look up the "Path evnvironmental variable" online, or Windows help.
>
> Actually there is a simple API function for this, SearchPath().

There's really a bit more to it than that. And the behavior of
SearchPath itself can be unpredictable, or need to be controlled
(SetSearchPathMode) to attain behavior similiar to the Run dialog. And
that's just when a full filename is entered!

If you really want to find an executable, with the same strategy as Run
(which, as it happens, is the same strategy used by most command
prompts, it requires some hand-rolled code.

http://vb.mvps.org/samp...

--
..NET: It's About Trust!
http://vfre...


Anton

6/16/2011 12:37:00 AM

0

Karl E. Peterson brought next idea :
> Nobody wrote :
>> ralph wrote:
>>> On Tue, 14 Jun 2011 15:07:30 -0700, BeeJ <nospam@spamfree.com> wrote:
>>>
>>>> so how does windows find an executable if all it has is the app.exe
>>>> or app.com name the way that Run or whatever does? If indexing is
>>>> off on a drive it can't use that. I have tried doing a Run on a
>>>> drive that is not indexed and it finds it very quickly for
>>>> "installed" apps. What method is it using? for apps that are copied
>>>> and "registered" it finds those too.
>>>>
>>>
>>> Look up the "Path evnvironmental variable" online, or Windows help.
>>
>> Actually there is a simple API function for this, SearchPath().

> There's really a bit more to it than that. And the behavior of SearchPath
> itself can be unpredictable, or need to be controlled (SetSearchPathMode) to
> attain behavior similiar to the Run dialog. And that's just when a full
> filename is entered!

> If you really want to find an executable, with the same strategy as Run
> (which, as it happens, is the same strategy used by most command prompts, it
> requires some hand-rolled code.

> http://vb.mvps.org/samp...

Yes, working with only a full app.exe or app.com name. No ambiguous
names.
I want to find the path to the executable that Windows will run.
I will take a look at the link you provided.
Thanks!