"K:\\SteelTools\\SOURCE_19\\MISC TOOLS\\KDUB_3DPlate.lsp"
I've used this successfully for a while ..Thanks so much, Kerry.Code - Auto/Visual Lisp: [Select]
;;(findFileFromRoot "D:\\" "FileName.ext") ;;(findFileFromRoot "D:\\folder\\" "FileName.ext") ) ) nil ) ) ) ) ) )Code - Auto/Visual Lisp: [Select]
(findFileFromRoot "K:\\SteelTools\\" "KDUB_3DPlate.lsp")Quote from: RETURNS"K:\\SteelTools\\SOURCE_19\\MISC TOOLS\\KDUB_3DPlate.lsp"
I've used this successfully for a while ..Code - Auto/Visual Lisp: [Select]
;;(findFileFromRoot "D:\\" "FileName.ext") ;;(findFileFromRoot "D:\\folder\\" "FileName.ext") ) ) nil ) ) ) ) ) )
< .. >Lee, I've been writing code from the time you were in nappies.
Looks familiar... (http://www.theswamp.org/index.php?topic=44025.msg492928#msg492928) :roll: :-(
< .. >Lee, I've been writing code from the time you were in nappies.
Looks familiar... (http://www.theswamp.org/index.php?topic=44025.msg492928#msg492928) :roll: :-(
There are a couple of pieces of code in the world that you didn't write (or re-write) you know, so don't roll your bloody eyes at me.
I think you should explain the discrepancy between the code on your web site and the (apparently more recent) code in your post before leveling plagiarism charges.
how do we know you didn't "roll yer own" based upon his original work and then forgot where you got the inspiration?
I simply updated the code as published on my site when posting in the thread to which I have referred...
One might infer that you updated your code after seeing Kerry's more efficient version.
I know that a specified file is existing and I want to find its location.
How do I get the path of the document (txt, doc... etc.)?
Thanks in advance.
(defun search_sub_folders (pathfile ext)
(mapcar '(lambda (sub)
(cons sub
(vl-directory-files
(strcat pathfile sub)
ext
1)))
(vl-directory-files
(vl-filename-directory
pathfile)
nil
-1)))
(defun findFileOnFolders (path name extension)
(vl-some '(lambda (f)
(findfile (strcat path (car f) "\\" name extension)))
(search_sub_folders path (strcat "*" extension))))
(FINDFILEONFOLDERS "C:\\" "attleft" ".lsp")
"C:\\My_Stuff\\attleft.lsp"
Just be warned that searching through lots of sub-folders could take some time. Even worse if searching on a network / remote folder....
Lee, you take your "online image" far too seriously. ...this is the internet, not real life. A series of 1s and 0s is isn't tangible. Go outside and give a perfect stranger a reason to laugh.I'm going to disagree.
I'm going to disagree.
Lee, you take your "online image" far too seriously. ...this is the internet, not real life. A series of 1s and 0s is isn't tangible. Go outside and give a perfect stranger a reason to laugh.
Sorry. His online image. In this day and age your online image is fast becoming who you are.I'm going to disagree.
With what?
(http://i40.tinypic.com/t983v8.jpg)
Sorry
Sorry. His online image. In this day and age your online image is fast becoming who you are.Sadly, I kind of agree but if I can get a little sappy, cliche, stupid, etc. for a moment: I've come to realize there are far more important things in life. ...I was just trying to make the observation that it may be time for him to "disconnect" a bit. Just, tossing it out there.
Apology accepted.
Glad that's settled. Wanna go get some coffee?
beer sounds more better
You buy the first round and I'll be there in a few.
Right. Drinking by myself again, fml.Nope. You're my boy Blue! A small warning though, if you're gonna roll with me you have to bring an emergency kit: [ e.g. passport, tire repair kit, pitching wedge, and a spare set of socks ]. Last time me and the friends ended up in Northern MN in a lakeside motel. The owners comp'd us to two free rooms so, all-in-all it turned out to be a pretty cool night. ...let's go.
Nope. You're my boy Blue!
Weird. Ok, So I've never seen the movie "Old School"...
Just be warned that searching through lots of sub-folders could take some time. Even worse if searching on a network / remote folder....
i tried it on a network with 1000 directories, and it locked up my acad.
im sure there is a limit on how many directories can search without causing issues.
would anyone have a good guess as to how many?
lol No, that's cool! Just a term of endearment/rally cry ...
Just be warned that searching through lots of sub-folders could take some time. Even worse if searching on a network / remote folder....
i tried it on a network with 1000 directories, and it locked up my acad.
im sure there is a limit on how many directories can search without causing issues.
would anyone have a good guess as to how many?
If you have to search through more than a handful of folders to find a support file, its time to re-evaluate the current scheme.
i tried it on a network with 1000 directories, and it locked up my acad.Nope, it's a bit like asking: "How long is a string?"
im sure there is a limit on how many directories can search without causing issues.
would anyone have a good guess as to how many?
Hardcoding paths require changes to code if the path changes. Look at the number of posters who have a LISP they inherited and need to make it work on a new computer, new network location, new AutoCAD version. To my mind changing data requires less knowledge than changing code, so I use a combination of registry values, XML files, and generic search patterns to handle changes with less work and by those who don't understand LISP (like IT :angel: ).Too true, if you constantly need to search for a file you need to find another way. Either add it to your SFSP, or have a setting which tells you where it is (Registry or some file in acad's setup folders). That's going to be exponentially faster than even limiting the depth of nested search folders.
I know that a specified file is existing and I want to find its location.This might be a bit late in this thread :? Hidden in the other matter :-(
How do I get the path of the document (txt, doc... etc.)?
Thanks in advance.
Hardcoding paths require changes to code if the path changes. Look at the number of posters who have a LISP they inherited and need to make it work on a new computer, new network location, new AutoCAD version. To my mind changing data requires less knowledge than changing code, so I use a combination of registry values, XML files, and generic search patterns to handle changes with less work and by those who don't understand LISP (like IT :angel: ).
.. i.e. add the folder into your Support Folders Search Path and use the findfile function.that sounds like it would be the best idea, use code to add the paths to the SFSP
To irneb and andrew_nao:You know that the SFSP is used to find "any" file ... not just DWG files. And if it is project specific, you might also want to try using the PFSP (Project Folder Support Path) in which case it is specific to a project. What I'm trying to explain, is that you should really try to use any other possibility to get to that particular file's path. This brute-force searching should only be used as a very last resort, i.e. there is absolutely NO other way anyone can think of. In order to tell if this is the case we need a lot more info about how those files are stored, whether there is any place which is easily findable which points to those files.
It is nothing about SFSP in this case because the target file may not be a drawing file in most of time (i.e. it may be a project note, a photo, xls and they may not be in the project drawing folder).
I am thinking that if I can grab the path of the document then I may add a file to the same directory.
As I found out the search time by using the code is amost the same when searching in the windows explorer.In general yes, though this method of searching doesn't use the Windows Search Index optimizations. So potentially it can be slower than the Explorer based search. As I hinted, it's a brute force method - and those tend to be the worst case performance wise.
To Kerry:
your code works but it is slow when searching in entire disk or in network server, as irneb points out. Thanks.
<..>
To irneb and andrew_nao:You know that the SFSP is used to find "any" file ... not just DWG files. And if it is project specific, you might also want to try using the PFSP (Project Folder Support Path) in which case it is specific to a project. What I'm trying to explain, is that you should really try to use any other possibility to get to that particular file's path. This brute-force searching should only be used as a very last resort, i.e. there is absolutely NO other way anyone can think of. In order to tell if this is the case we need a lot more info about how those files are stored, whether there is any place which is easily findable which points to those files.
It is nothing about SFSP in this case because the target file may not be a drawing file in most of time (i.e. it may be a project note, a photo, xls and they may not be in the project drawing folder).
I am thinking that if I can grab the path of the document then I may add a file to the same directory.As I found out the search time by using the code is amost the same when searching in the windows explorer.In general yes, though this method of searching doesn't use the Windows Search Index optimizations. So potentially it can be slower than the Explorer based search. As I hinted, it's a brute force method - and those tend to be the worst case performance wise.
(setq joborder "12345")
;; Lee Mac code
(defun wcmatch_first ( dlst pattern flag / result )
(setq pattern (if flag (strcase pattern) pattern))
(vl-some
'(lambda (str) (if (wcmatch str pattern) (setq result str)))
(if flag (mapcar 'strcase dlst) dlst)
)
result
)
;; -- find summary file based on order number
(SETQ dlst (VL-DIRECTORY-FILES "O:\\" nil -1))
(if (setq dir (strcat "O:\\" (wcmatch_first dlst (strcat "*" joborder "*") nil)))
(progn
(SETQ dLST (VL-DIRECTORY-FILES DIR "*.DOC"))
(if (setq ndir (wcmatch_first dlst (strcat "*" "Follow-Up" "*") nil))
(setq path (findfile (strcat dir "/" ndir)))
(alert "File Has not been created yet") ; not found
) ;if
) ;progn
(alert "No such Order exists") ; not found
) ;if
what this does its looks in my O:\ drive (a network drive) for this directory, then once it finds this directory it looks inside for the follow-up file.