Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Can ShellExecute do a find file? 2

Status
Not open for further replies.

dkean4

Programmer
Feb 15, 2015
282
US
I found this code somewhere on the web... and wonder if it makes any sense.


Code:
DECLARE INTEGER ShellExecute IN shell32.dll ; 
  INTEGER hndWin, ; 
  STRING cAction, ; 
  STRING cFileName, ; 
  STRING cParams, ;  
  STRING cDir, ; 
  INTEGER nShowWin

ShellExecute (0, "find", <File name>, "", <Directory>,1)
* Example:  ShellExecute (0, "find", "Mira.jpg", "", "D:\",1)

When I run it with a file name I get no errors and of course nothing comes up. How can I harvest the results of this ShellExecute call? Zit possible or am I dreaming...


Many thanks...

Dennis
 
Yes, it makes perfect sense.

But you have omitted a vital step. Instead of this:

Code:
ShellExecute (0, "find", "Mira.jpg", "", "D:\",1)

Do this:

Code:
[b]lnReply =[/b] ShellExecute (0, "find", "Mira.jpg", "", "D:\",1)

Then look at the value in lnReply. If it is 32 or less, that that indicates an error.

In this case, I would guess that the reply would be 31, which means "no registered action for this file". In other words, "find" is not recognised as an action that you would normally perform on a file.

So the question is: What are you hoping to achieve? You say you found the code "somewhere on the web". If nothing else, that points to the danger of copying and pasting someone else's code without understanding what it does (or what you are trying to achieve).

If you are not familiar with ShellExecute(), I suggest you read this article:

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Just looking at your code in a bit more detail ....

Although "find" does not make sense for a file, it does work for a folder. So this code:

Code:
lnReply = ShellExecute (0, "find", "D:\", "", "",1)

would open the Windows "Find" dialogue, with D:\ already entered in the "Look in" field. The user can then enter other parameters into the dialogue, and click Search to begin the search.

Presumably that's not what you want. If your goal is to search for a file programmatically, then you don't want ShellExecute(). You would probably need to write some code using something like ADIR().

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
To launch the Shell's Find utility for a directory, use the following call.

ShellExecute(handle, "find", <fully_qualified_path_to_folder>, NULL, NULL, 0);

Which means your try to use it may be according to what could be expected from parameter meanings, but doesn't work. According to the find operation usage example you can only specify the start folder of a search, nothing more. I've tried things, and I can cause a Windows Explorer to show up, but no search criterion being entered.

If you want to make use of the Windows Indexing system, there should be other ways. I once posted how to use an OLE DB Provider for the search index, but that's not worth looking for anymore, as that deprecated with Windows 8.

Bye, Olaf.
 
I'd prefer Getfile() over Locfile() because the latter can alter your VFP search path.
 
Olaf said:
LOCFILE() is an approach, too

Dan said:
I'd prefer Getfile() over Locfile()

I agree with both - but only if you want to find the file interactively. I still think Dennis might be wanting to search programmatically.

Regarding LOCFILE(), as well as the problem with changing the default directory, it will generate an error if the user cancels the dialogue in any way. This strikes me as very bad behaviour: you give the user a button labeled Cancel, but you produce an error if the user clicks it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Mike,

Thank you for the good info. I always imagined ShellExecute to be some MSOS Command prompt command execution only and I have used it frequently. But using it as a VFP function which returns values is new to me.

Unlike you I do not get the (Manual access) feature doing either of these:

Code:
ShellExecute(0,"find","Mira.jpg","","d:\",1)
ShellExecute(0,"open","Mira.jpg","","d:\",1)

For a moment I thought it would be for manual file access through the Explorer windows, but It does not work for me, so my imagination went flying with hope hat it might save me time from doing a fully non-visual class for finding files on the entire drive. The visual Find File utility was great, but though it is faster than the Explorer find file mechanist it is still too slow.

So, thanks to you, I am plunging into caching my entire file system in a DB so I can do searches at breakneck speeds.

By the way, I regularly go to your site and I did read your comments before posting on the "find" action too. I am grateful for your web site examples/explanations and help, Mike. With your site, you have been a help to me on many occasions.

Best Regards my friend,

Dennis
 
Olaf,

You read my mind. MS OS index access sounds great.

Olaf said:
If you want to make use of the Windows Indexing system, there should be other ways. I once posted how to use an OLE DB Provider for the search index, but that's not worth looking for anymore, as that deprecated with Windows 8.

You hit the nexus. I need a rapid turn around in accessing files. I cannot wait 3 minutes until MS find turtles sit around and digest their previous meal to get services. At this junction I am thinking of a recursion through the drives/subdirectories with an ADIR(<dir>) to harvest the entire directory structure, so I can index the mess with VFP index and get rapid response.

Too bad about Win 8 deprecating the search index (or maybe it is better since win 7 and XP index is a dog.), because I bought a Win 10 laptop to run the app on. Of course I will have to figure out a way to update the directory on the fly. It would be dandy is I could code some command in VFP to list all new files in the last in the last 10 minutes on a particular drive, every 10 minutes and update my tables.

If you have any ideas on that being done in VFP on any particular drive, that could solve my dilemma. Otherwise, night time will have to do.

Thank you for your help, Olaf...

Dennis
 
Check for Filer in VFP Help.

Filer.DLL is included in VFP Tools folder, and exposes a class that you can instantiate.

To get the files in a folder created in the last 10 minutes:
Code:
CLEAR

LOCAL Filer
LOCAL FileFound
LOCAL LastTenMinutes AS Datetime

m.LastTenMinutes = DATETIME() - 600

m.Filer = CREATEOBJECT("Filer.FileUtil")
m.Filer.SearchPath = GETDIR()
m.Filer.FileExpression = "*.*"
m.Filer.Find(0)
FOR EACH m.FileFound IN m.Filer.Files
   IF CAST(m.FileFound.DateTime + {^1899-12-30} AS T) >= m.LastTenMinutes
   	? m.FileFound.Path + m.FileFound.Name
   ENDIF
ENDFOR
 
From what I know filer is "live searching" files, it doesn't make use of any index. On the other side, Dennis, if you process all files, you also only have a snapshot, it's not easy to keep this data about all files in sync with the real file system. Fast finding files without asking the user to use predefined directories for what your application processes is a hard problem. It's still in the sense of convention over configuration, if you let your application only look into users documents or pictures etc. and sub directories.

Bye, Olaf.
 
It's true that performance can be a big issue here. Even if you code the whole thing from scratch, it could take a very long time to search an entire disk. This is mainly because you will be doing recursive calls to ADIR() - or whatever other method you use for identifying files and directories - and recursion often carries a big overhead.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
LOCFILE has some preconditions for a nice experience with it, that's true. It generates an error with cancel, as it's trying to guarantee finding a certain file, eg DLL you need for DECLAREs. So it's mainly for cases you're at least sure you find a file in some directory in your SET("PATH") list of directory paths. If that's the case it's also running totally silent. It was meant from me as a silent programmatically search of a file. It's return value is the path of the file searched, but the preconditions make it less proper for full drive search. Even if you SET PATH TO C:\ and then doa locfile it only looks in C:\ root, not recursing.

If the Locfile dialog comes up the file wasn't found automatically, now you're (the user is) asked to provide the file. Afterwards, yes, PATH is extended and so the next Locfile for the same file name is finding it.

Bye, Olaf.
 
After some testing and tuning, the filer.scx turned out to be nearly as fast as the CMD prompt DIR <finename> /s command. I do not quite understand why it was giving me the abysmally slow results before.

So, at this new speed, I'm going to be happy with that for a little while.

Mike, Olaf, Atlopes and Danfreeman, thank you so much for your input. Great thing to have you guys around.

A special thanks to Atlopes for that last 10 minutes files script. It is exactly what I wanted. Thanks so much.

Regards to all,


Dennis
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top