AutoCAD Electrical Forum
Welcome to Autodesk’s AutoCAD Electrical Forums. Share your knowledge, ask questions, and explore popular AutoCAD Electrical topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

custom Project-Wide-Execution from LISP

2 REPLIES 2
SOLVED
Reply
Message 1 of 3
cpetzol2
737 Views, 2 Replies

custom Project-Wide-Execution from LISP

This is two parts (P1 and P2). The first part, I think I know the answer to, and the second part is in regards to my workaround and the issues I am having with that.

 

P1: Is there a way to issue project-wide-execution purely from lisp (an api call?); not with the project utilities? (I think not, but lets just get that out of the way)

 

P2: To achieve project-wide-execution in LISP, I have built an application that manages this for me. My approach does not use SCRIPTS (I thought it would be nicer if it could be done all in LISP). My version 1.0 seemed to work great, but more complicated uses of my PWE app have yielded some problems. I think I have a good idea of where the problems are coming from, so I'll ask a few direct questions, and then fill in a little more background info...

 

Q1: Is it safe to start issuing graphical commands from within the acaddoc.lsp? My understanding from the man pages, was that the acaddoc was more for initialization, and including the function S::STARTUP was the *safe* place to start issuing graphical commands. So, from that, the bulk of my PWE scripts are kicked off from within S::STARTUP.

 

Q2: Can I move through drawings using the API call (c:wd_proj_getdwgnam nil indexnum 1) and still expect the S::STARTUP function to still be called as anticipated? (assuming I was correct about Q1)

 

------Some quick background...

I was assuming, that after I issue a call to c:wd_proj_getdwgnam (and the internal SCRIPTing then does its job), that S::STARTUP would be invoked when the new drawing had been properly initialized. Given that assumption, my scripts get called from S::STARTUP, they check the Bulletin-Board for some flags, and then carry on with PWE if they conclude we are in the middle of my custom PWE session.

 

The obvious *problem* is in the form of interruptions of the drawing iteration and execution. Depending on where I initiate my PWE session, it will make it most of the way through (near success, last drawing opens, but no execution occurs even though there are still some calls left on my call-stack), or it will halt on the first drawing, and only after I manually open the next file does the PWE session continue un-interrupted.

 

On these interruptions, the command prompt is reading some very interesting information. After lacing my scripts with some debugging messages, I noticed that the (princ)'s in S::STARTUP were among the first commands issued to the drawing, that the SCRIPT (from wd_proj_getdwgnam) followed, and very last were messages issued in the acaddoc.lsp (non-S::STARTUP); all of this followed by blinking prompt.

 

The order of commands just described seems almost completely reverse of what I would have expected. Its almost as if the S::STARTUP I am seeing is from the previous drawing, then the SCRIPT switched drawings, and finally acaddoc.lsp was loaded (but no subsequent call to S::STARTUP).

 

Any other thoughts would be appreciated.

 

P.S. - I know we could make little SCRIPT generator, but the main appeal was a pure LISP application, and it has actually turned out quite nice (other than not working right Smiley Wink)

2 REPLIES 2
Message 2 of 3
cpetzol2
in reply to: cpetzol2

Ok. I was on the right track, and the fix was a little obvious. Also note, the problems I was having were not really related to my custom application, but rather more to my general application of LISP. So, this should be helpful to anyone trying to automate work over multiple drawings.

 

Solution:  Instead of using either the acaddoc.lsp or the S::STARTUP function, you should use the entry provided in the wd.env, "WD_OPEN_DWG". It seems that neither acaddoc.lsp or S::STARTUP are *electrical* safe; that probably being the very reason the wd.env option was made available.

 

After invoking my Project-Wide-Execution kickoff scripts through the wd.env, all the issues described in my last post have been completely resolved, with few additional changes required in my application code.

 

Message 3 of 3
sig.johnson
in reply to: cpetzol2

P1: There is a way to do this. 

c:ace_projwide_script

Is equivalent to the "run command script file" options under Project > Utilities.

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report

”Boost