Topic: Search path...

[MeasureUp]

To irneb and andrew_nao:
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.
Thanks for your time and help.

[irneb]

To irneb and andrew_nao:
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.

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.

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.

[Kerry]

To Kerry:
your code works but it is slow when searching in entire disk or in network server, as irneb points out. Thanks.

<..>

Yes, I know it's slow ... that is to be expected considering the amount of work the recursion is doing.
One version I had returned a list of matches and presented them in a dialog for selection.

//--------------

Regarding the other matter : I'm not angry, just dissapointed.

I attribute code where I can.  In this case attribution is not necessary.
I have thousands of lines of code here and I don't intend 'publishing' it just to proove a point.
I have no control over what others think and frankly I don't care too much. I don't need to be validated : I have my integrity and I sleep at night.

I'm sorry that your thread copped a thrashing

Regards.

[andrew_nao]

To irneb and andrew_nao:
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.

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.

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.

one piece of programing i have, well this function was made by Lee, so i cant take to much credit for but this function i use to find the file in a directory that is not in my SFSP

Code: [Select]


(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.
as you can see, i have the network drive hardcoded in and thats because the file im looking for with this code will ALWAYS be in that drive and no other drive.
the file name changes slightly however "follow-up" will always be in the file name

maybe this could help