Differences between the findfile command in AutoCAD and BricsCAD
Hello, everyone.
I am trying to migrate a Lisp program written in AutoCAD to BircsCAD. This program deals with dialogs. I am troubled by the difference in the behavior of the findfile command between AutoCAD and BricsCAD.
In AutoCAD, if I put the DCL file in the same folder as the Lisp file, I should be able to read it with the following program: I made the program a long time ago, so I have a vague memory.
(setq Dcl_file (findfile "Select.dcl"))
(setq Dlg_id (load_dialog Dcl_file))
or
(setq Dlg_id (load_dialog "Select.dcl"))
Dlg_id = nil when running VLIDE with Lisp and DCL loaded at the same time.
What should I do?
Comments
-
What does (findfile "Select.dcl") return at the command line?
0 -
It simply returns nil.
Thank you .
0 -
This may be a way around the problem I use it a lot, big thanks to RLX it converts your dcl to lisp code so no need for an external dcl file. Just takes a little bit of thought when copying and pasting into the LISP.
Just a comment I never use findfile rather make sure all dcl's and lisps etc are in a support folder so CAD will auto find. I have like 8 custom support folders added and move them to the top.
0 -
Wow.
I didn't know there was a way to do this.
This is fantastic.
Thank you very much!
I guess the easiest way is to register the development Lisp folder in the file search path while debugging, since this problem will be solved if it is eventually integrated into the DES file.0 -
If your distributing your code to others you can use a Install.lsp, mine use a zip and a lisp, the zip has everything in it, lisp mnu image, icons etc. You can make a directory, unzip all files this task being done via lisp, to that directory, add support path, add menu and so on.
0 -
Just wondering, can you set the current working directory via lisp?
0 -
I noticed different behavior, BricsCAD changes the working directory to the install folder.
AutoCAD sets it to my documents.
I was getting weird behavior with my python wrappers importing modules, so I temporarily set the working directory to the path of the python module
If you can set the working directory, you might not need to go through the trouble of setting up a path
std::error_code _Ec std::filesystem::path cwd = std::filesystem::current_path(_Ec) acutPrintf(cwd.c_str())
BRX = C:\Program Files\Bricsys\BricsCAD V25 en_US
ARX = C:\Users\Dan\Documents
0 -
The initial working directory is controlled by Windows, typically by what is set in the shortcut used to start the app. It is safest (and recommended) to always specify a full absolute path to dependent files rather than using slow and insecure file search, e.g. by keeping track somewhere the full path to the folder where the needed files are installed, then computing the full absolute path to individual files.
-1 -
from project loading context. It’s nice to have “./” to be the module folder.
something like
(setq old_path (acet-file-cwd))
(acet-file-chdir modulepath)
Load
(acet-file-chdir old_path)0