New FINDFILE and LOAD Behavior (R2015+)?

[scot-65]

Have a look at the following and observe the new behavior of FINDFILE and LOAD.

The current directory is still searched, as finding a DWG file was successful, however not for a LSP file.

I have not the opportunity to test other file types as to what could and what could not searched.

Command: (getvar "dwgprefix")
"C:\\Users\\xxxx\\AppData\\Roaming\\yyyy\\Menu\\"

Command: (getvar "dwgname")
"0-Drawing1.dwg"

Command: (getvar "trustedpaths")
"C:\\Users\\xxxx\\appdata\\roaming\\yyyy\\..."


Command: (findfile "0-atl.dwg")
"C:\\Users\\xxxx\\AppData\\Roaming\\yyyy\\Menu\\0-atl.dwg"


Command: (findfile "0-ads.lsp")
nil

Command: (findfile (strcat (getvar "dwgprefix") "0-ads.lsp"))
"C:\\Users\\xxxx\\AppData\\Roaming\\yyyy\\Menu\\0-ads.lsp"


Command: (findtrustedfile "0-ads.lsp")
nil

Command: (findtrustedfile (strcat (getvar "dwgprefix") "0-ads.lsp"))
"C:\\Users\\xxxx\\AppData\\Roaming\\yyyy\\Menu\\0-ads.lsp"


Command: (findfile "test.lsp")
nil

Command: (findfile (strcat (getvar "dwgprefix") "test.lsp"))
"C:\\Users\\xxxx\\AppData\\Roaming\\yyyy\\Menu\\test.lsp"

Command: (load "test")
; error: LOAD failed: "test"

Command: (load (strcat (getvar "dwgprefix") "test"))
...test loaded.

We switched to R2016 earlier this year and this week is the first time I had opportunity

to continue developing. R2014 did not behave in this manner.

Online documentation does show a revised FINDFILE function, but not in this manner.

Online documentation does not even mention this new LOAD behavior.

Has anyone else noticed this new behavior?

[dbroad]

They increased security in 2015+ to disallow loading except from trusted paths.

Read about it here:

http://help.autodesk.com/view/BLDSYS/2017/ENU/?guid=GUID-C108E81C-7A06-477C-A5F8-10AA2FDEB050

[scot-65]

Trusted paths is declared (third item in the code block).
FINDFILE is not a loading mechanism.

[dbroad]

I still think I may have answered your question.  The start-in folder in your situation is not apparently your drawing folder.  You may find your start-in folder with:  (findfile ".")

Just because something is on a trusted path doesn't mean that AutoCAD can find it.  It also needs to be on the supported paths list which is profile specific.

Not that it matters but your function return values appear to be typed or modified as capitalization varies, etc.

[scot-65]

By performing the (FINDFILE ".") test, it shows as the current directory but
without the trailing backslashes. I place a DWG in the same folder as the
LSP I am developing, and open this DWG file for testing of the LSP(s). When
the trusted paths came into play, this "working" folder is still separate from
the menu folder structure, but is included in the trusted path area. By
employing the DWG/LSP in same folder method, it was never required to
declare a support path to this folder in order for the LSP to be loaded.

The only modification I made to the lines is substitute with "xxxx" and "yyyy".
I too noticed the various capitalizations (to which remained unedited).

Strange that FINDFILE can find a DWG in the current directory but not a LSP.
Documentation mentions the current directory, but it is not (no longer) true.
This is why the post [for future searches and Kudos].

I am familiar with the trusted location dialog warning, however this exercise
never displayed such dialog.

Another function that does not behave as expected is PROMPT when used in
the startup sequence. Substituting with PRINC was the solution.
Example from inside the MNL (it could also be in the S::STARTUP):
(prompt "MyMenu Menu Functions Loaded. ")

Reworking the solution from:
(findfile (strcat (getvar "DWGPREFIX") a ".lsp"))
to
(findfile (strcat (findfile ".") "\\" a ".lsp"))
seems a bit unorthodox as other variations attempted did not work.

???

[scot-65]

12-8-2016 Update.

The function VLISP-COMPILE no longer observes the current directory as well.

To fix, use (strcat (getvar "DWGPREFIX") "filename.lsp")

If the file is in a folder that is part of a SFSP, it will work without having to add the drawing prefix.

[john.uhden]

I guess things just aren't as "trusted" as you might think.  😕

[dbroad]

These behaviors do seem curious. Thanks @scot-65 for bringing them to light.  I have found that if you add the "." directory to the search file path in the options files tab, support files folder, then findfile will find LSP files in the current folder (which is the drawing's folder if AutoCAD is launched by double clicking a DWG in the folder).  I'm not sure why this is necessary and it may just be a bug or a possibly negative side effect of the increased security.  You can also force a current folder search by using (findfile ".\\...."). Again, that folder will only be the drawing folder if AutoCAD is launched by double clicking on the dwg file to launch the APP.

[bcf]

Autodesk added more security features in 2016 which prevent searches for excutable files in both the "start-in" and "current-dwg" folders. If you set LEGACYCODESEARCH to "1" you will be able to find and load scr/lsp from the current folder again. Otherwise you will have to add the full path when calling those files.

I have many sets of scr/lsp scripts which are copied from one directory to another for different projects and are modified slightly in each place. When calling (loading) each other I don't include a path because the names never change and they all exist in the current directory. They all stopped working with 2016. Took a while to figure out why. I temporarily change the code search settings now in the originating and all is well.