Visual LISP, AutoLISP and General Customization
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Approach to lisp-routines combinations.

4 REPLIES 4
Reply
Message 1 of 5
Kycau
390 Views, 4 Replies

Approach to lisp-routines combinations.

I make drawings for several engineering companies.

The tasks for every company is pretty much the same, but of course they all differ by text style... layers... plot style... etc.

 

I'm pretty sure that many of autocad-user have the same issue )

 

I want to make a number of lisp-routines, for every company, and combine them this way:

 

Company1.lsp:

(defun c:command1
[...]
)
(defun c:command2
[...]
)
etc.

 

 

Company2.lsp:

(defun c:command1
[...]
)
(defun c:command2
[...]
)
etc.

 

Is it a good aproach ?)

4 REPLIES 4
Message 2 of 5
Kent1Cooper
in reply to: Kycau

 


@Kycau wrote:

I make drawings for several engineering companies.

The tasks for every company is pretty much the same, but of course they all differ by text style... layers... plot style... etc.

.... 

I want to make a number of lisp-routines, for every company, and combine them this way:

 

Company1.lsp:

(defun c:command1
[...]
)
(defun c:command2
[...]
)
etc.

 ....


You can certainly do it that way.  You would then use APPLOAD or (load) to have the particular company's versions of the commands loaded in.  But if the differences are all in terms of settings, and not operational differences [e.g. Dimensioning works the same way, just with a different standard Style for each company], then I would suggest setting up drawing template files with each company's standards of Layering, Text and Dimension and Plot styles, etc., and then for every new drawing, just base it on the appropriate company's template.

Kent Cooper, AIA
Message 3 of 5
dgorsman
in reply to: Kent1Cooper

Templates aren't always a good solution.  Many drawings already exist, and drawing information can be purged out (a lot of users just PURGE ALL without thinking about it).

 

I would suggest something similar, but instead separate code and data.  The process is the same, but the data changes.  So the code (process) is the same, it just points to different files/databases/whatever (data) based on the client.  That way the clients can maintain their own settings, since updating data files is easier and less intimidating than updating code.

----------------------------------
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.


Message 4 of 5
scot-65
in reply to: Kycau

As others here have stated this is a good approach to the issue at hand.

 

By modularizing the routines you create a "Framework".

 

I would suggest creating stand-alone Command routine files in lieu of dumping

everything into one LSP or MNL file. Place these stand-alone routines in a folder

and declare a support path to this folder. This is your library. It is expandable and

is easier to edit down the road. End of step one.

 

Step two:

If you have common functions, I.E.: (defun ABC (/)..., place these non-command

functions inside a MNL file and name this MNL file the same as the main or

enterprise CUI you are using - "MyMenu.MNL". This is your menu functions. This

MNL file is located in the same folder as the "MyMenu.CUI" file you are using.

 

Step three - initializing the stand-alone command routines:

Look into APPLOAD, or write one line for each stand-alone you have in your library

inside either the ACAD.lsp, ACADDOC.lsp or  MyMenu.MNL file described in step two.

Again, this is expandable and easy to edit.

 

  (defun c:ABC () (load "ABC") (c:ABC) (princ) ) ;comment what this routine does.

 

 

My approach includes using a "Util.lsp" file for step three which is loaded via the

MNL file shown in step two. This makes editing if the library easy to do and with

a little less work otherwise, can be converted to a HTML handout.

 

Portability? You bet!

Have a look at this tree and one can guess how many support paths are required.

 

Suppath1.gif

 

The Support folder shown here MUST be placed at the top of the support path list.

All other paths can be placed at the end of the support path list.

Redirect the three printer support paths to this folder structure and you are good to go.

No need to dig down into AutoCAD's enu/support, etc. area(s) to place all your files.

 

Hope this helps.

 


Scot-65
A gift of extraordinary Common Sense does not require an Acronym Suffix to be added to my given name.


Message 5 of 5
stevor
in reply to: Kycau

If you use the methods suggested by dgorsman,

and the code of these routines stays the same

except for constants,

you could use globalsfor all those constants;

and reset the values of the globals for different jobs.

S

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

Post to forums  

Autodesk Design & Make Report

”Boost