Ask the name of running program!

[Ahankhah]

Hi CADTutormates,

is it possible to know the name and location of current code by itself? If yes, how?

For example, if the loaded program is: "c:/MyFolder/Myprogram.fas", needed to find strings: "c:/MyFolder/" and "Myprogram.fas"?

[pBe]

You can pass the filename arguments using this

 

http://www.cadtutor.net/forum/showthread.php?58069-How-to-find-a-drawing-in-my-Coumputer-drives

[Ahankhah]

You can pass the filename arguments using this

 

http://www.cadtutor.net/forum/showthread.php?58069-How-to-find-a-drawing-in-my-Coumputer-drives

A good thread to study pBe,

but I didn't find any solution to my problem:P.

[LibertyOne]

If you run the command "_APPLOAD" the dialog shows a list of all loaded *.lsp, *.arx, *.fas, etc. files. Getting that information in the form that you need my be a bit difficult.

[MSasu]

The list of currently loaded AutoLISP files can be retrieved using the dos_lisplist function from DOSLib pack. Also the CMDACTIVE system variable will tell you the active action (however if an AutoLISP routine is the active one this is visible only from an ARX tool). Not sure if those may help you.

 

Regards,

Mircea

[Ahankhah]

If you run the command "_APPLOAD" the dialog shows a list of all loaded *.lsp, *.arx, *.fas, etc. files. Getting that information in the form that you need my be a bit difficult.

LibertyOne,

Maybe the way "_.APPLOAD" gets and keeps in mind the name and path of applications (programs) is good to achieve the goal:), but how to do that by coding in AutoLISP:huh:?

[Ahankhah]

The list of currently loaded AutoLISP files can be retrieved using the dos_lisplist function from DOSLib pack.

Mircea, when I want to find "DOSLib18.arx" in the directory of my code, the paradox happens. First step is finding the program like one mentioned to load it via my code. How this step should be done:unsure:?

[Lee Mac]

findfile?

 

..

[Ahankhah]

findfile?

 

..

Of course Lee,

when the file is in the sme folder of current code, but the folder isn't in the search path of (findfile).

[alanjt]

Maybe you need to start organizing things a little better.

[BlackBox]

Of course Lee,

when the file is in the sme folder of current code, but the folder isn't in the search path of (findfile).

 

Ahankhah, consider how much less typing you'd do, if you no longer needed (most?) hard-coded file paths in your code, which would also make your code easier to maintain if / when paths change... PLUS the added benefit of using findfile... sounds like a win-win-win to me.

[alanjt]

Ahankhah, consider how much less typing you'd do, if you no longer needed (most?) hard-coded file paths in your code, which would also make your code easier to maintain if / when paths change... PLUS the added benefit of using findfile... sounds like a win-win-win to me.

Agreed.

(load "file" nil) is a lot less work than (load "c:\\folder\\folder\\folder\\folder\\folder\\folder\\folder\\file" nil)

[Ahankhah]

It shows I am not so clear, perhaps for my bad explanation.

Assume that you have a code (I name it "main program"). The "main program" needs to load another program ("reference program"). Both "main program" and "reference program" are located in the same folder, regardless of folder's name and location. The problem is I want to find "reference program" while (findfile) can't find it as well refering it without clarifying the path does nothing.

I hope this time I am clear enough.

[LibertyOne]

Hi CADTutormates,

is it possible to know the name and location of current code by itself? If yes, how?

For example, if the loaded program is: "c:/MyFolder/Myprogram.fas", needed to find strings: "c:/MyFolder/" and "Myprogram.fas"?

 

I'm curious, what would be the advantage of knowing this? I mean, knowing what apps are loaded is one thing. But asking the location from where the app is loaded may not be relevant. It's like waving down a taxicab and after getting in, asking the driver from where he just arrived.

[LibertyOne]

It shows I am not so clear, perhaps for my bad explanation.

Assume that you have a code (I name it "main program"). The "main program" needs to load another program ("reference program"). Both "main program" and "reference program" are located in the same folder, regardless of folder's name and location. The problem is I want to find "reference program" while (findfile) can't find it as well refering it without clarifying the path does nothing.

I hope this time I am clear enough.

 

ok, I would go about doing this a completely different way. I would first check if the "reference_program" was loaded or not.

(atoms-family 1 "reference_program")

If it's not loaded then I would load it knowing where the reference program is saved.

[Ahankhah]

ok, I would go about doing this a completely different way. I would first check if the "reference_program" was loaded or not.

(atoms-family 1 "reference_program")

If it's not loaded then I would load it knowing where the reference program is saved.

In this code:

(atoms-family 1 '("reference-program"))

"reference-program" refers to a function/command/variable and not a file.

[BlackBox]

In this code:

(atoms-family 1 '("reference-program"))

"reference-program" refers to a function/command/variable and not a file.

 

If you want to (I'll use a different word) *identify* the name of a sub-function called from a primary function, then in a new / blank file in VLIDE:

 

(defun c:FOO ()
 [color=red][b]([/b][/color]<PrimaryFunction>)) [color=red]; <- Red paren represents breakpoint[/color]
(c:FOO)

 

... and load the above code. When the VLIDE breaks at the leading paren notated above, simply step through the code using F8, one line at a time. This *should* open the resultant / dependent routines (assuming they're .LSP?), and subsequent steps (pressing F8 ) *should* allow you to step through the newly opened / dependent sub-functions being called.

 

I'm still completely perplexed why you are pursuing this, given that you already know that the sub-function ("reference program") resides within the same directory. Furthermore, unless the "main program" is hard-coded to load the "reference program", the latter is being loaded by another routine, perhaps by ACADDOC.lsp? I see you're using 2012; perhaps this is the result of your using the *autoload* folder?

[Lee Mac]

When a file is loaded into memory, you only have access to the defined symbols in the document namespace, not the file from which they were loaded.

[alanjt]

When a file is loaded into memory, you only have access to the defined symbols in the document namespace, not the file from which they were loaded.

Precisely. Hell, you can copy a LISP routine and paste it directly into the command line.

[BlackBox]