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 ?)
@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.
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.
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.
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.
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.