Topic: Support file Search path problem

[Coder]

Hello guys .

I have a problem with the Support File Search Path that is in the Option in Autocad , I used to attach a folder of lisps and after that I can use all lisps in the selected folder as if I am running the appload command separately on each lisp , but today I have noticed that the new folder that I want to attach it would be attached but the lisp files won't work which means that it doesn't recognize the lisp files in the folder or not connected with lisps or maybe something else .

Has anyone faced or know for a solution for this problem ?

Many thanks

[rkmcswain]

Check the "Working Support File Search Path" (just below the other one).
Is your path listed there?

[Coder]

Check the "Working Support File Search Path" (just below the other one).
Is your path listed there?

Yes , it is listed in that second folder . 

[rkmcswain]

Just because a lisp "file" resides in a path that is in the Support File Seach Path, does not mean the functions in the file are loaded automatically.


You still need to load them using "acaddoc.lsp", an ".mnl" file, or some other mechanism.

Code: [Select]

; acaddoc.lsp
(load "mylisp")
(load "another_lisp")
(load "myfile")
(princ "\n acaddoc.lsp loaded   ")



[MP]

Just because a lisp "file" resides in a path that is in the Support File Seach Path, does not mean the functions in the file are loaded automagically.

Unless you pen a function do do precisely that.

[Coder]

Just because a lisp "file" resides in a path that is in the Support File Seach Path, does not mean the functions in the file are loaded automatically.

I am sorry to say no , because I used to load the folder that has the lisp files in it and without any kind of other loads I can run the
lisps within that attached folder without a load function or anything else .

I am saying that from an experience with this matter and not a guess .

Can you please try that on your machine and let me know ?

Many thanks .

[rkmcswain]

As MP said "Unless you pen a function do do precisely that"


So again, simply adding a folder to the SFSP doesn't cause lisp files in that folder to load by themselves.
You say this is a new folder of lisp files. Maybe the function that is loading the other folder isn't aware of this new folder.

[alanjt]

Just because a lisp "file" resides in a path that is in the Support File Seach Path, does not mean the functions in the file are loaded automagically.

Unless you pen a function do do precisely that.

Quick and dirty:

Code: [Select]

(defun _loadSupportPathLisps (/ str)
  (setq str (vla-get-supportpath (vla-get-files (vla-get-preferences (vlax-get-acad-object)))))
  (while (setq i (vl-string-search ";" str))
    (foreach file (vl-directory-files (substr str 1 i) nil 1)
      (if (wcmatch (strcase file) "*.FAS,*.LSP,*.VLX")
        (load file nil)
      )
    )
    (setq str (substr str (+ i 2)))
  )
  (princ)
)

[Coder]

So again, simply adding a folder to the SFSP doesn't cause lisp files in that folder to load by themselves.
You say this is a new folder of lisp files. Maybe the function that is loading the other folder isn't aware of this new folder.

That makes me wonder why the support file existed and why also the express tools included in that file .
I wonder also how the express tools lisps loaded with autocad , so what's the need of attaching their folder  in Support File !

Thank you

[rkmcswain]

That makes me wonder why the support file existed

Maybe there are other support files that some of the lisp code needs? Impossible to know without knowing something about the files, the code, and how it was designed to be used


We include our "lisp" directory in the SFSP because we do have other support files needed by some of those routines, and because I can just type in something like (load "ao") at the command line (and in menu macros, etc) and not have to worry about specifying a path.

and why also the express tools included in that file .

ET included in what file?

I wonder also how the express tools lisps loaded with autocad , so what's the need of attaching their folder  in Support File !

Because whoever set up ET to work with AutoCAD designed it that way.
I'm not sure of the exact sequence of events, but many, if not all of them, get loaded from the file acetauto.lsp.

[Coder]

and why also the express tools included in that file .

ET included in what file?

I mean , why the Express Tools Folder attached to the SFSP ?
I think to avoid loading each lisp file separately and that's why they used the SFSP , ( that's what I think )

Did you try to attach any folder that has one or two lisp files and after attaching it try to call the lisp fill as if they loaded by their attachment to the SFSP ?

Many thanks .

[irneb]

I mean , why the Express Tools Folder attached to the SFSP ?

Because ET is not just one file, it consists of lots of LSP/FAS/ARX files. And to make the rest of ET a lot simpler all these are inside a folder which is then on the SFSP. It means that when some ET command is called it only needs to load its file using something like this:

Code - Auto/Visual Lisp: [Select]

1. (load "filename")

If it wasn't on the SFSP then that simple load instruction would need to be something like the following:

Code - Auto/Visual Lisp: [Select]

1. (load (strcat (vl-filename-directory (findfile "acad.exe")) "\\Express\\" "filename"))

And that would only work if the Express Tools were installed in a subfolder of the AutoCAD installation. What if ET was installed in some other folder? Then that line would need to be altered in every single place it was written, including inside any MNL / FAS / ARX files. Which means that if anything changed the entire ET file set would need to be checked with a fine tooth comb to check where such change needs alterations.

With its path on the SFSP all that needs to happen if ET is installed in any other place is to update the SFSP and all other stuff would work as is.

I think you mis-understand what SFSP is meant for. It's not a setting which tells acad to load everything in those folders. It's a setting to make it easier for acad to find files it needs for all sorts of purposes. It's like a list of places to search when asked to find something, not a list of places to run everything that's in there.

[Coder]

Thank you irneb .

Your explanations were very clear to me to understand and now I guess I could use the findfile function to search for a specific file in any folder that attached to the SFSP with the extension
of the file of course very easily .

That helps a lot for File Searching if we intend to use findfile function anyway .

Many thanks to you and to all nice guys who tried to help 

[rkmcswain]

Did you try to attach any folder that has one or two lisp files and after attaching it try to call the lisp fill as if they loaded by their attachment to the SFSP ?

No, because I know it doesn't work.
We're going in circles here

[irneb]

@RK
I think Coder's figured that out from the previous 2 posts. It might be that he's seen stuff like ACAD.LSP load automatically if it's inside one of the SFSP folders - that might have created the misunderstanding.

@ Coder:
Note: acad has some "special" filenames it searches for. If it finds such file(s) it loads them automatically. These are much more than only special LSP files, e.g. it's also things like acad.lin (for the linetype definitions), acad.pat (for hatch patterns), acad.pgp (command shortcuts), acad.rx (listing all ARX files to be loaded), etc.

And where does it search for these files? In the folders listed on the SFSP of course. It's as if it uses the findfile on each of these special names.

Note 2: Be clear that this means only those files named according to these special names will be automatically loaded (not any other file), and only if acad can find them (i.e. if they're inside one of the SFSP folders).

[trogg]

Alan,
Do you know of a way to load files if they are in a sub folder of the folder that is defined in the support path?
This function worked fine in the folder that I defined in the support path. Thanks
~Greg

Just because a lisp "file" resides in a path that is in the Support File Seach Path, does not mean the functions in the file are loaded automagically.

Unless you pen a function do do precisely that.

Quick and dirty:

Code: [Select]

(defun _loadSupportPathLisps (/ str)
  (setq str (vla-get-supportpath (vla-get-files (vla-get-preferences (vlax-get-acad-object)))))
  (while (setq i (vl-string-search ";" str))
    (foreach file (vl-directory-files (substr str 1 i) nil 1)
      (if (wcmatch (strcase file) "*.FAS,*.LSP,*.VLX")
        (load file nil)
      )
    )
    (setq str (substr str (+ i 2)))
  )
  (princ)
)

[irneb]

Alan,
Do you know of a way to load files if they are in a sub folder of the folder that is defined in the support path?

Perhaps

Code - Auto/Visual Lisp: [Select]

1. (load ".\\SubFolder\\FileName")

Or even just

Code - Auto/Visual Lisp: [Select]

1. (load "SubFolder\\FileName")

[rkmcswain]

@ Coder:
Note: acad has some "special" filenames it searches for. If it finds such file(s) it loads them automatically. ........ things like acad.lin

Correct me if I'm wrong, but AutoCAD does not search for "acad.lin" at any time except when you run the Linetype command, Load option, and even then it's only a suggested file from which to load linetype definitions.

My point is that you can have multiple acad.lin files (or none at all) and it has no effect on the operation of AutoCAD with respect to linetypes in drawings that you open, because linetypes used by drawings are stored in the drawing file, not in external files. Having said that, complex linetypes in drawing files that reference shapes or fonts do require that those shapes or fonts reside in a path that is in the current SFSP, or possibly contain a hard-coded path to the shape/font.

I know this is a bit off-topic, but I thought it was worth mentioning. Thanks!

[irneb]

Correct me if I'm wrong, but AutoCAD does not search for "acad.lin" at any time except when you run the Linetype command, Load option, and even then it's only a suggested file from which to load linetype definitions.

You're absolutely correct. It was probably a bad example.