Best strategy for loading LISPs?

[randall.temple]

I'm preparing to roll out ACA2013 in our office, and I'm trying to discover the best way to load our custom AutoLISP routines.

In our current setup, from ACA2008, I have a master LISP routine loaded and executed from Acaddoc.lsp. This demand-loads each of our custom routines via a defun statement, i.e. "(defun c:0 () (load "o.lsp") (c:0))".

In 2013, it appears that I have some more options, including loading through the CUI and using the ApplicationPlugins folder, assuming I can redirect it to the server in the file search path (though I may want to leave this local for users' customizations.) What I haven't found documented is how the CUI or ApplicationPlugins folder load the individual routines. Do they load on demand, or just dump everything into memory? I want to keep launch as light as possible, and avoid fully loading routines that a particular user may not be using.

My options, as I see them, are:

1 - Continue demand-loading routines via a master LISP executed from Acaddoc.lsp. Should I switch to using the Autoload function vs defun? Is there an advantage one way or the other?

2 - Demand load routines via a master LISP executed from the CUI.

3 - Load individual routines from the CUI.

4 - Load individual routines via the ApplicationPlugins folder.

Is there some other approach that I may be missing? Until I know the behavior of routines loaded in the CUI, I don't know which course to pursue.


Thanks,

Randall

[rkmcswain]

My vote is #1.

No changes are necessary now, it will port to AutoCAD 2014, 2015, year after year, with little to no work required.
I do not see any advantage to using any of the other methods.

The only exception I make to this rule is that I do include certain lisp commands in the "OurCompanyMenu.mnl" file (which autoloads anytime "OurCompanyMenu.cuix" is loaded). These are generally obscure lisp routines that would only be called from the menu anyway. In the grand scheme of things though, it doesn't matter because we have startup code to ensure that the company menu is loaded anyway.

[randall.temple]

Thanks for the quick reply.

We do have a couple routines defined in the Enterprise CUI already, but as you say, these are exclusive to certain menu items. Are these demand-loaded, or do they sit in memory?

Do you think I should continue executing my list from Acaddoc.lsp, or should I move it, and all the other configuration items, into the CUI, so they're not scattered in various places?


R

[Norton_cad]

Enterprise CUI's opens another can of worms here in this excellent thread:-
http://forums.augi.com/showthread.ph...enterprise+cui

[randall.temple]

Thanks, Mark.

I've been reading that one since I started this thread, and I've found answers to most of my questions there. I think I've got a good handle on the Enterprise CUI, and how all that should be structured. But I still don't know how apps in the CUI are loaded. Maybe it's discussed later in that thread.


R

[irneb]

If you add any LSP into the Lisp item in the CUI (or have a MNL file together with your CUI) ... this will be loaded in the same manner as the acaddoc.lsp is loaded (only if that CUI is loaded). It doesn't demand-load, it just loads. BTW, this is nothing new - I remember MNL's from the 90's ... and AFAICR 2008 had a Lisp Files section in its CUI as well.

The only "demand-load" I know of for lisp (note not DotNet DLL's / ARX's) is to use the autoload function, or roll your own like you've described.

My preference is to use ACadDoc.LSP for all common stuff (either having the defuns declared directly inside, or have it load other LSP's, or use autoload to demand-load other LSPs). I only add stuff that has to be loaded no matter what into my ACadDoc.LSP file (or load/autoload from it). Usually routines I'd use in scripts fall into this category, but various other cleanup stuff also, some lisp libraries and reactors.

For more specific things I add the same concept as I would have done in the ACadDoc.LSP, into mu CUI's accompanying MNL. Usually the later consists mostly of autoloads, since once the CUI is loaded the commands should be available. My rule is: If it's a command, then it needs to be defined in a menu/button - thus it needs to be tied to a CUI. Thus the MNL acts as my ACadDoc.LSP for commands.

[randall.temple]

Thanks, irneb. That answered most of my open questions.


R