Autodesk Technology Managers Forum
Share your knowledge, ask questions, and engage with fellow CAD/BIM Managers.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Cleanup before migration to 2007...Your thoughts?

38 REPLIES 38
Reply
Message 1 of 39
Anonymous
302 Views, 38 Replies

Cleanup before migration to 2007...Your thoughts?

I am just starting to get us ready to migrate from AutoCAD 2005 to AutoCAD
2007 and I'm trying to fine tune a menu system that has not really been
touched since 2002. We basically have 4 menus (MNU's) - one for "the
company" and one for each discipline (Electrical , HVAC, Plumbing). Each of
these menus has an MNL associated that loads a TON of lisp routines and
variables. Most of the LISP routines I have converted to "autoloading", but
the load time for these menus is significant and they of course load with
every drawing. Some of the routines are external files, some are codes right
in the MNL.

What I'm hoping for is that someone(s) can point me in a direction(s) that
allows me to load these routines once and minimize the time it takes to load
them. I'm thinking it will involve some combination of partial CUIs,
workspaces, acad.lsp and acaddoc.lsp...

I'm starting this installation with a clean slate if it kills me (as long as
it doesn't kill production)...

Thanks for any help!
38 REPLIES 38
Message 2 of 39
Anonymous
in reply to: Anonymous

When you say "autoloading" do you mean you are using this type of code in
your MNL?:

(autoload "filename" '("command"))

This code example will define a short command that will load quickly and
prevent the full lisp from loading until it is called for.



"pkirill" wrote in message
news:5197024@discussion.autodesk.com...
I am just starting to get us ready to migrate from AutoCAD 2005 to AutoCAD
2007 and I'm trying to fine tune a menu system that has not really been
touched since 2002. We basically have 4 menus (MNU's) - one for "the
company" and one for each discipline (Electrical , HVAC, Plumbing). Each of
these menus has an MNL associated that loads a TON of lisp routines and
variables. Most of the LISP routines I have converted to "autoloading", but
the load time for these menus is significant and they of course load with
every drawing. Some of the routines are external files, some are codes right
in the MNL.

What I'm hoping for is that someone(s) can point me in a direction(s) that
allows me to load these routines once and minimize the time it takes to load
them. I'm thinking it will involve some combination of partial CUIs,
workspaces, acad.lsp and acaddoc.lsp...

I'm starting this installation with a clean slate if it kills me (as long as
it doesn't kill production)...

Thanks for any help!
Message 3 of 39
Anonymous
in reply to: Anonymous

Yup. That's what I'm doing with most of the externals. I plan to do it with
all of them, it's just taking a while to go through all the code. The guy
before me was a bit of security nut (which is both good an bad, I guess) so
a lot fo the code is intertwined...


"FG" wrote in message
news:5197261@discussion.autodesk.com...
When you say "autoloading" do you mean you are using this type of code in
your MNL?:

(autoload "filename" '("command"))

This code example will define a short command that will load quickly and
prevent the full lisp from loading until it is called for.



"pkirill" wrote in message
news:5197024@discussion.autodesk.com...
I am just starting to get us ready to migrate from AutoCAD 2005 to AutoCAD
2007 and I'm trying to fine tune a menu system that has not really been
touched since 2002. We basically have 4 menus (MNU's) - one for "the
company" and one for each discipline (Electrical , HVAC, Plumbing). Each of
these menus has an MNL associated that loads a TON of lisp routines and
variables. Most of the LISP routines I have converted to "autoloading", but
the load time for these menus is significant and they of course load with
every drawing. Some of the routines are external files, some are codes right
in the MNL.

What I'm hoping for is that someone(s) can point me in a direction(s) that
allows me to load these routines once and minimize the time it takes to load
them. I'm thinking it will involve some combination of partial CUIs,
workspaces, acad.lsp and acaddoc.lsp...

I'm starting this installation with a clean slate if it kills me (as long as
it doesn't kill production)...

Thanks for any help!
Message 4 of 39
Anonymous
in reply to: Anonymous

Are you saying that the autoload code is slow?
What I do in my shortcut key lisp and my menu's is the simple code of
(defun c:G ()
(ECHOOFF) (princ "\nMacro >\tGlue: ")
(if (not c:glue)(load "glue.lsp")) (c:glue)
(princ)
)

or in my menu
^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF

The only code I place in my .mnl is code to place the pulldown menu in the
list
I have an acaddoc.lsp that loads my shortcuts, variable settings, config and
a few
other items that have to run on every drawing.

I too have 4 decipline menu's
I don't load much code per decipline.

Not sure what else your code could be doing

--
Dave

"pkirill" wrote in message
news:5197024@discussion.autodesk.com...
I am just starting to get us ready to migrate from AutoCAD 2005 to AutoCAD
2007 and I'm trying to fine tune a menu system that has not really been
touched since 2002. We basically have 4 menus (MNU's) - one for "the
company" and one for each discipline (Electrical , HVAC, Plumbing). Each of
these menus has an MNL associated that loads a TON of lisp routines and
variables. Most of the LISP routines I have converted to "autoloading", but
the load time for these menus is significant and they of course load with
every drawing. Some of the routines are external files, some are codes right
in the MNL.

What I'm hoping for is that someone(s) can point me in a direction(s) that
allows me to load these routines once and minimize the time it takes to load
them. I'm thinking it will involve some combination of partial CUIs,
workspaces, acad.lsp and acaddoc.lsp...

I'm starting this installation with a clean slate if it kills me (as long as
it doesn't kill production)...

Thanks for any help!
Message 5 of 39
Anonymous
in reply to: Anonymous

I don't think it's the "autoload" code spcifically that's slow. I'm looking
at the process as a whole. And on the whole, it's too slow for my taste.
I've been moving a bunch of the preliminary stuff to the acaddoc.lsp and
that seems to speed things up a bit. There are also some vba macros that
load up into each drawing - why I don't know yet. There seems to be no
reason why they can't load when the command is called. I think I can back
those out to the mnl's...

I guess, I'm just looking for some creative ideas for minimizing startup
time. Your shortcut idea is a nice one...

Also, for a while I was in the habit of grouping a bunch of similar routines
into one LISP file. For example we have a bunch of block insertion routines
that control insertion scale, layering, insert multiple, etc. I put them all
in one BlockInsertion.LSP. Some have upwards of 20 small routines in them. I
think these are part of what's bogging me down and I need to harvest the
C:XXXX and put those in an autoload list.


"David Allen" wrote in message
news:5197904@discussion.autodesk.com...
Are you saying that the autoload code is slow?
What I do in my shortcut key lisp and my menu's is the simple code of
(defun c:G ()
(ECHOOFF) (princ "\nMacro >\tGlue: ")
(if (not c:glue)(load "glue.lsp")) (c:glue)
(princ)
)

or in my menu
^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF

The only code I place in my .mnl is code to place the pulldown menu in the
list
I have an acaddoc.lsp that loads my shortcuts, variable settings, config and
a few
other items that have to run on every drawing.

I too have 4 decipline menu's
I don't load much code per decipline.

Not sure what else your code could be doing

--
Dave

"pkirill" wrote in message
news:5197024@discussion.autodesk.com...
I am just starting to get us ready to migrate from AutoCAD 2005 to AutoCAD
2007 and I'm trying to fine tune a menu system that has not really been
touched since 2002. We basically have 4 menus (MNU's) - one for "the
company" and one for each discipline (Electrical , HVAC, Plumbing). Each of
these menus has an MNL associated that loads a TON of lisp routines and
variables. Most of the LISP routines I have converted to "autoloading", but
the load time for these menus is significant and they of course load with
every drawing. Some of the routines are external files, some are codes right
in the MNL.

What I'm hoping for is that someone(s) can point me in a direction(s) that
allows me to load these routines once and minimize the time it takes to load
them. I'm thinking it will involve some combination of partial CUIs,
workspaces, acad.lsp and acaddoc.lsp...

I'm starting this installation with a clean slate if it kills me (as long as
it doesn't kill production)...

Thanks for any help!
Message 6 of 39
Anonymous
in reply to: Anonymous

Its also a good time to ask everyone which commands are no longer being
used. We seem to remove a few each year as autodesk incorporates them into
the program.


"pkirill" wrote in message
news:5198784@discussion.autodesk.com...
I don't think it's the "autoload" code spcifically that's slow. I'm looking
at the process as a whole. And on the whole, it's too slow for my taste.
I've been moving a bunch of the preliminary stuff to the acaddoc.lsp and
that seems to speed things up a bit. There are also some vba macros that
load up into each drawing - why I don't know yet. There seems to be no
reason why they can't load when the command is called. I think I can back
those out to the mnl's...

I guess, I'm just looking for some creative ideas for minimizing startup
time. Your shortcut idea is a nice one...

Also, for a while I was in the habit of grouping a bunch of similar routines
into one LISP file. For example we have a bunch of block insertion routines
that control insertion scale, layering, insert multiple, etc. I put them all
in one BlockInsertion.LSP. Some have upwards of 20 small routines in them. I
think these are part of what's bogging me down and I need to harvest the
C:XXXX and put those in an autoload list.


"David Allen" wrote in message
news:5197904@discussion.autodesk.com...
Are you saying that the autoload code is slow?
What I do in my shortcut key lisp and my menu's is the simple code of
(defun c:G ()
(ECHOOFF) (princ "\nMacro >\tGlue: ")
(if (not c:glue)(load "glue.lsp")) (c:glue)
(princ)
)

or in my menu
^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF

The only code I place in my .mnl is code to place the pulldown menu in the
list
I have an acaddoc.lsp that loads my shortcuts, variable settings, config and
a few
other items that have to run on every drawing.

I too have 4 decipline menu's
I don't load much code per decipline.

Not sure what else your code could be doing

--
Dave

"pkirill" wrote in message
news:5197024@discussion.autodesk.com...
I am just starting to get us ready to migrate from AutoCAD 2005 to AutoCAD
2007 and I'm trying to fine tune a menu system that has not really been
touched since 2002. We basically have 4 menus (MNU's) - one for "the
company" and one for each discipline (Electrical , HVAC, Plumbing). Each of
these menus has an MNL associated that loads a TON of lisp routines and
variables. Most of the LISP routines I have converted to "autoloading", but
the load time for these menus is significant and they of course load with
every drawing. Some of the routines are external files, some are codes right
in the MNL.

What I'm hoping for is that someone(s) can point me in a direction(s) that
allows me to load these routines once and minimize the time it takes to load
them. I'm thinking it will involve some combination of partial CUIs,
workspaces, acad.lsp and acaddoc.lsp...

I'm starting this installation with a clean slate if it kills me (as long as
it doesn't kill production)...

Thanks for any help!
Message 7 of 39
Anonymous
in reply to: Anonymous

Here is what I do....
I have one file (lisp loader) that just has just load calls to specific lisp
routines. All or most of my lisp are separate files. This lisp loader is
much like aliases in that it only loads routines for use as they are needed
(this "lisp loader" call is put in the "acaddoc.lsp" to load on each
session). I then can add to or modify the "lisp loader" file at will for all
to use. I make each individual alias or "load call" the same as the its
routine "run call" so the user only has to remember one alias. This way
routines are only loaded as needed and I only need a couple of lines of code
in the acaddoc.lsp which can be copied to the next version update.

Hope this helps.

Ron Meicho


"pkirill" wrote in message
news:5198784@discussion.autodesk.com...
I don't think it's the "autoload" code spcifically that's slow. I'm looking
at the process as a whole. And on the whole, it's too slow for my taste.
I've been moving a bunch of the preliminary stuff to the acaddoc.lsp and
that seems to speed things up a bit. There are also some vba macros that
load up into each drawing - why I don't know yet. There seems to be no
reason why they can't load when the command is called. I think I can back
those out to the mnl's...

I guess, I'm just looking for some creative ideas for minimizing startup
time. Your shortcut idea is a nice one...

Also, for a while I was in the habit of grouping a bunch of similar routines
into one LISP file. For example we have a bunch of block insertion routines
that control insertion scale, layering, insert multiple, etc. I put them all
in one BlockInsertion.LSP. Some have upwards of 20 small routines in them. I
think these are part of what's bogging me down and I need to harvest the
C:XXXX and put those in an autoload list.


"David Allen" wrote in message
news:5197904@discussion.autodesk.com...
Are you saying that the autoload code is slow?
What I do in my shortcut key lisp and my menu's is the simple code of
(defun c:G ()
(ECHOOFF) (princ "\nMacro >\tGlue: ")
(if (not c:glue)(load "glue.lsp")) (c:glue)
(princ)
)

or in my menu
^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF

The only code I place in my .mnl is code to place the pulldown menu in the
list
I have an acaddoc.lsp that loads my shortcuts, variable settings, config and
a few
other items that have to run on every drawing.

I too have 4 decipline menu's
I don't load much code per decipline.

Not sure what else your code could be doing

--
Dave

"pkirill" wrote in message
news:5197024@discussion.autodesk.com...
I am just starting to get us ready to migrate from AutoCAD 2005 to AutoCAD
2007 and I'm trying to fine tune a menu system that has not really been
touched since 2002. We basically have 4 menus (MNU's) - one for "the
company" and one for each discipline (Electrical , HVAC, Plumbing). Each of
these menus has an MNL associated that loads a TON of lisp routines and
variables. Most of the LISP routines I have converted to "autoloading", but
the load time for these menus is significant and they of course load with
every drawing. Some of the routines are external files, some are codes right
in the MNL.

What I'm hoping for is that someone(s) can point me in a direction(s) that
allows me to load these routines once and minimize the time it takes to load
them. I'm thinking it will involve some combination of partial CUIs,
workspaces, acad.lsp and acaddoc.lsp...

I'm starting this installation with a clean slate if it kills me (as long as
it doesn't kill production)...

Thanks for any help!
Message 8 of 39
Anonymous
in reply to: Anonymous

Ah - about a year ago I went through all the LISPs we have and inserted a
call to another little routine called (lisplog) which rights out the
command, date and time, and user to a csv file. I am going through and
evaluating a bunch of our routines to see if they aren't being used because
they are useles or because no on knows about them...

In case anyone wants it, here it is. I can't take full credit as I had help
from this NG and the LISP NG for the reactor part...

;;;(lisplog) - add this inside any LISP routine you want to log

(defun setlispname (reactor name)
(setq *lispname* (car name))
)
(vlr-lisp-reactor nil '((:vlr-lispWillStart . setlispname)))
(defun lisplog ()
(setq *CDATE* (rtos (getvar "cdate") 2 4)
YEAR (substr *CDATE* 3 2)
MONTH (itoa (atoi (substr *CDATE* 5 2)))
DAY (itoa (atoi (substr *CDATE* 7 2)))
)
(setq CURDATE (strcat MONTH "/" DAY "/" YEAR))
(setq f (open (strcat "G:/CAD Standards/LogFiles/" (getvar "LOGINNAME")
"_Lisp.log") "a")
)
(write-line (strcat (getvar "LOGINNAME") "," CURDATE "," *lispname*) f)
(close f)
(princ)
)



"FG" wrote in message
news:5199002@discussion.autodesk.com...
Its also a good time to ask everyone which commands are no longer being
used. We seem to remove a few each year as autodesk incorporates them into
the program.


"pkirill" wrote in message
news:5198784@discussion.autodesk.com...
I don't think it's the "autoload" code spcifically that's slow. I'm looking
at the process as a whole. And on the whole, it's too slow for my taste.
I've been moving a bunch of the preliminary stuff to the acaddoc.lsp and
that seems to speed things up a bit. There are also some vba macros that
load up into each drawing - why I don't know yet. There seems to be no
reason why they can't load when the command is called. I think I can back
those out to the mnl's...

I guess, I'm just looking for some creative ideas for minimizing startup
time. Your shortcut idea is a nice one...

Also, for a while I was in the habit of grouping a bunch of similar routines
into one LISP file. For example we have a bunch of block insertion routines
that control insertion scale, layering, insert multiple, etc. I put them all
in one BlockInsertion.LSP. Some have upwards of 20 small routines in them. I
think these are part of what's bogging me down and I need to harvest the
C:XXXX and put those in an autoload list.


"David Allen" wrote in message
news:5197904@discussion.autodesk.com...
Are you saying that the autoload code is slow?
What I do in my shortcut key lisp and my menu's is the simple code of
(defun c:G ()
(ECHOOFF) (princ "\nMacro >\tGlue: ")
(if (not c:glue)(load "glue.lsp")) (c:glue)
(princ)
)

or in my menu
^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF

The only code I place in my .mnl is code to place the pulldown menu in the
list
I have an acaddoc.lsp that loads my shortcuts, variable settings, config and
a few
other items that have to run on every drawing.

I too have 4 decipline menu's
I don't load much code per decipline.

Not sure what else your code could be doing

--
Dave

"pkirill" wrote in message
news:5197024@discussion.autodesk.com...
I am just starting to get us ready to migrate from AutoCAD 2005 to AutoCAD
2007 and I'm trying to fine tune a menu system that has not really been
touched since 2002. We basically have 4 menus (MNU's) - one for "the
company" and one for each discipline (Electrical , HVAC, Plumbing). Each of
these menus has an MNL associated that loads a TON of lisp routines and
variables. Most of the LISP routines I have converted to "autoloading", but
the load time for these menus is significant and they of course load with
every drawing. Some of the routines are external files, some are codes right
in the MNL.

What I'm hoping for is that someone(s) can point me in a direction(s) that
allows me to load these routines once and minimize the time it takes to load
them. I'm thinking it will involve some combination of partial CUIs,
workspaces, acad.lsp and acaddoc.lsp...

I'm starting this installation with a clean slate if it kills me (as long as
it doesn't kill production)...

Thanks for any help!
Message 9 of 39
Anonymous
in reply to: Anonymous

" I only need a couple of lines of code
in the acaddoc.lsp which can be copied to the next version update."

I like that idea - thanks!
Message 10 of 39
Anonymous
in reply to: Anonymous

Could you explain how this works, or how to use it?
Thanks,

"pkirill" wrote in message
news:5199740@discussion.autodesk.com...
Ah - about a year ago I went through all the LISPs we have and inserted a
call to another little routine called (lisplog) which rights out the
command, date and time, and user to a csv file. I am going through and
evaluating a bunch of our routines to see if they aren't being used because
they are useles or because no on knows about them...

In case anyone wants it, here it is. I can't take full credit as I had help
from this NG and the LISP NG for the reactor part...

;;;(lisplog) - add this inside any LISP routine you want to log

(defun setlispname (reactor name)
(setq *lispname* (car name))
)
(vlr-lisp-reactor nil '((:vlr-lispWillStart . setlispname)))
(defun lisplog ()
(setq *CDATE* (rtos (getvar "cdate") 2 4)
YEAR (substr *CDATE* 3 2)
MONTH (itoa (atoi (substr *CDATE* 5 2)))
DAY (itoa (atoi (substr *CDATE* 7 2)))
)
(setq CURDATE (strcat MONTH "/" DAY "/" YEAR))
(setq f (open (strcat "G:/CAD Standards/LogFiles/" (getvar "LOGINNAME")
"_Lisp.log") "a")
)
(write-line (strcat (getvar "LOGINNAME") "," CURDATE "," *lispname*) f)
(close f)
(princ)
)



"FG" wrote in message
news:5199002@discussion.autodesk.com...
Its also a good time to ask everyone which commands are no longer being
used. We seem to remove a few each year as autodesk incorporates them into
the program.


"pkirill" wrote in message
news:5198784@discussion.autodesk.com...
I don't think it's the "autoload" code spcifically that's slow. I'm looking
at the process as a whole. And on the whole, it's too slow for my taste.
I've been moving a bunch of the preliminary stuff to the acaddoc.lsp and
that seems to speed things up a bit. There are also some vba macros that
load up into each drawing - why I don't know yet. There seems to be no
reason why they can't load when the command is called. I think I can back
those out to the mnl's...

I guess, I'm just looking for some creative ideas for minimizing startup
time. Your shortcut idea is a nice one...

Also, for a while I was in the habit of grouping a bunch of similar routines
into one LISP file. For example we have a bunch of block insertion routines
that control insertion scale, layering, insert multiple, etc. I put them all
in one BlockInsertion.LSP. Some have upwards of 20 small routines in them. I
think these are part of what's bogging me down and I need to harvest the
C:XXXX and put those in an autoload list.


"David Allen" wrote in message
news:5197904@discussion.autodesk.com...
Are you saying that the autoload code is slow?
What I do in my shortcut key lisp and my menu's is the simple code of
(defun c:G ()
(ECHOOFF) (princ "\nMacro >\tGlue: ")
(if (not c:glue)(load "glue.lsp")) (c:glue)
(princ)
)

or in my menu
^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF

The only code I place in my .mnl is code to place the pulldown menu in the
list
I have an acaddoc.lsp that loads my shortcuts, variable settings, config and
a few
other items that have to run on every drawing.

I too have 4 decipline menu's
I don't load much code per decipline.

Not sure what else your code could be doing

--
Dave

"pkirill" wrote in message
news:5197024@discussion.autodesk.com...
I am just starting to get us ready to migrate from AutoCAD 2005 to AutoCAD
2007 and I'm trying to fine tune a menu system that has not really been
touched since 2002. We basically have 4 menus (MNU's) - one for "the
company" and one for each discipline (Electrical , HVAC, Plumbing). Each of
these menus has an MNL associated that loads a TON of lisp routines and
variables. Most of the LISP routines I have converted to "autoloading", but
the load time for these menus is significant and they of course load with
every drawing. Some of the routines are external files, some are codes right
in the MNL.

What I'm hoping for is that someone(s) can point me in a direction(s) that
allows me to load these routines once and minimize the time it takes to load
them. I'm thinking it will involve some combination of partial CUIs,
workspaces, acad.lsp and acaddoc.lsp...

I'm starting this installation with a clean slate if it kills me (as long as
it doesn't kill production)...

Thanks for any help!
Message 11 of 39
Anonymous
in reply to: Anonymous

slick idea!


"pkirill" wrote in message
news:5199740@discussion.autodesk.com...
Ah - about a year ago I went through all the LISPs we have and inserted a
call to another little routine called (lisplog) which rights out the
command, date and time, and user to a csv file. I am going through and
evaluating a bunch of our routines to see if they aren't being used because
they are useles or because no on knows about them...

In case anyone wants it, here it is. I can't take full credit as I had help
from this NG and the LISP NG for the reactor part...

;;;(lisplog) - add this inside any LISP routine you want to log

(defun setlispname (reactor name)
(setq *lispname* (car name))
)
(vlr-lisp-reactor nil '((:vlr-lispWillStart . setlispname)))
(defun lisplog ()
(setq *CDATE* (rtos (getvar "cdate") 2 4)
YEAR (substr *CDATE* 3 2)
MONTH (itoa (atoi (substr *CDATE* 5 2)))
DAY (itoa (atoi (substr *CDATE* 7 2)))
)
(setq CURDATE (strcat MONTH "/" DAY "/" YEAR))
(setq f (open (strcat "G:/CAD Standards/LogFiles/" (getvar "LOGINNAME")
"_Lisp.log") "a")
)
(write-line (strcat (getvar "LOGINNAME") "," CURDATE "," *lispname*) f)
(close f)
(princ)
)



"FG" wrote in message
news:5199002@discussion.autodesk.com...
Its also a good time to ask everyone which commands are no longer being
used. We seem to remove a few each year as autodesk incorporates them into
the program.


"pkirill" wrote in message
news:5198784@discussion.autodesk.com...
I don't think it's the "autoload" code spcifically that's slow. I'm looking
at the process as a whole. And on the whole, it's too slow for my taste.
I've been moving a bunch of the preliminary stuff to the acaddoc.lsp and
that seems to speed things up a bit. There are also some vba macros that
load up into each drawing - why I don't know yet. There seems to be no
reason why they can't load when the command is called. I think I can back
those out to the mnl's...

I guess, I'm just looking for some creative ideas for minimizing startup
time. Your shortcut idea is a nice one...

Also, for a while I was in the habit of grouping a bunch of similar routines
into one LISP file. For example we have a bunch of block insertion routines
that control insertion scale, layering, insert multiple, etc. I put them all
in one BlockInsertion.LSP. Some have upwards of 20 small routines in them. I
think these are part of what's bogging me down and I need to harvest the
C:XXXX and put those in an autoload list.


"David Allen" wrote in message
news:5197904@discussion.autodesk.com...
Are you saying that the autoload code is slow?
What I do in my shortcut key lisp and my menu's is the simple code of
(defun c:G ()
(ECHOOFF) (princ "\nMacro >\tGlue: ")
(if (not c:glue)(load "glue.lsp")) (c:glue)
(princ)
)

or in my menu
^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF

The only code I place in my .mnl is code to place the pulldown menu in the
list
I have an acaddoc.lsp that loads my shortcuts, variable settings, config and
a few
other items that have to run on every drawing.

I too have 4 decipline menu's
I don't load much code per decipline.

Not sure what else your code could be doing

--
Dave

"pkirill" wrote in message
news:5197024@discussion.autodesk.com...
I am just starting to get us ready to migrate from AutoCAD 2005 to AutoCAD
2007 and I'm trying to fine tune a menu system that has not really been
touched since 2002. We basically have 4 menus (MNU's) - one for "the
company" and one for each discipline (Electrical , HVAC, Plumbing). Each of
these menus has an MNL associated that loads a TON of lisp routines and
variables. Most of the LISP routines I have converted to "autoloading", but
the load time for these menus is significant and they of course load with
every drawing. Some of the routines are external files, some are codes right
in the MNL.

What I'm hoping for is that someone(s) can point me in a direction(s) that
allows me to load these routines once and minimize the time it takes to load
them. I'm thinking it will involve some combination of partial CUIs,
workspaces, acad.lsp and acaddoc.lsp...

I'm starting this installation with a clean slate if it kills me (as long as
it doesn't kill production)...

Thanks for any help!
Message 12 of 39
Anonymous
in reply to: Anonymous

Put the code below in a txt file and call it "LISPLOG.LSP". Change "G:/CAD
Standards/LogFiles/" to a location on your network that everyone can write
to. Save it and put that file in your AutoCAD path. Then load the
LISPLOG.LSP file from your ACADDOC.LSP.

In every LISP routine you want to log add a call to (lisplog) - for example:

(defun C:MYLISP ()
(alert "This routine is being logged")
(lisplog)
(princ)
)

Every routine that has (lisplog) in it, writes out to a text file (or csv,
or log, etc.) username, date and routine. Like this:

paulk,6/7/06,(C:QL)
paulk,6/7/06,(C:SCA)
paulk,6/7/06,(C:Q)
paulk,6/7/06,(C:PL)
paulk,6/7/06,(C:PL)
paulk,6/7/06,(C:VPL)
paulk,6/7/06,(C:VPU)

I'm sure the data could be organized better, but I didn't want to spend a
bunch of time on it...

"SD'y" wrote in message
news:5199779@discussion.autodesk.com...
Could you explain how this works, or how to use it?
Thanks,

"pkirill" wrote in message
news:5199740@discussion.autodesk.com...
Ah - about a year ago I went through all the LISPs we have and inserted a
call to another little routine called (lisplog) which rights out the
command, date and time, and user to a csv file. I am going through and
evaluating a bunch of our routines to see if they aren't being used because
they are useles or because no on knows about them...

In case anyone wants it, here it is. I can't take full credit as I had help
from this NG and the LISP NG for the reactor part...

;;;(lisplog) - add this inside any LISP routine you want to log

(defun setlispname (reactor name)
(setq *lispname* (car name))
)
(vlr-lisp-reactor nil '((:vlr-lispWillStart . setlispname)))
(defun lisplog ()
(setq *CDATE* (rtos (getvar "cdate") 2 4)
YEAR (substr *CDATE* 3 2)
MONTH (itoa (atoi (substr *CDATE* 5 2)))
DAY (itoa (atoi (substr *CDATE* 7 2)))
)
(setq CURDATE (strcat MONTH "/" DAY "/" YEAR))
(setq f (open (strcat "G:/CAD Standards/LogFiles/" (getvar "LOGINNAME")
"_Lisp.log") "a")
)
(write-line (strcat (getvar "LOGINNAME") "," CURDATE "," *lispname*) f)
(close f)
(princ)
)



"FG" wrote in message
news:5199002@discussion.autodesk.com...
Its also a good time to ask everyone which commands are no longer being
used. We seem to remove a few each year as autodesk incorporates them into
the program.


"pkirill" wrote in message
news:5198784@discussion.autodesk.com...
I don't think it's the "autoload" code spcifically that's slow. I'm looking
at the process as a whole. And on the whole, it's too slow for my taste.
I've been moving a bunch of the preliminary stuff to the acaddoc.lsp and
that seems to speed things up a bit. There are also some vba macros that
load up into each drawing - why I don't know yet. There seems to be no
reason why they can't load when the command is called. I think I can back
those out to the mnl's...

I guess, I'm just looking for some creative ideas for minimizing startup
time. Your shortcut idea is a nice one...

Also, for a while I was in the habit of grouping a bunch of similar routines
into one LISP file. For example we have a bunch of block insertion routines
that control insertion scale, layering, insert multiple, etc. I put them all
in one BlockInsertion.LSP. Some have upwards of 20 small routines in them. I
think these are part of what's bogging me down and I need to harvest the
C:XXXX and put those in an autoload list.


"David Allen" wrote in message
news:5197904@discussion.autodesk.com...
Are you saying that the autoload code is slow?
What I do in my shortcut key lisp and my menu's is the simple code of
(defun c:G ()
(ECHOOFF) (princ "\nMacro >\tGlue: ")
(if (not c:glue)(load "glue.lsp")) (c:glue)
(princ)
)

or in my menu
^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF

The only code I place in my .mnl is code to place the pulldown menu in the
list
I have an acaddoc.lsp that loads my shortcuts, variable settings, config and
a few
other items that have to run on every drawing.

I too have 4 decipline menu's
I don't load much code per decipline.

Not sure what else your code could be doing

--
Dave

"pkirill" wrote in message
news:5197024@discussion.autodesk.com...
I am just starting to get us ready to migrate from AutoCAD 2005 to AutoCAD
2007 and I'm trying to fine tune a menu system that has not really been
touched since 2002. We basically have 4 menus (MNU's) - one for "the
company" and one for each discipline (Electrical , HVAC, Plumbing). Each of
these menus has an MNL associated that loads a TON of lisp routines and
variables. Most of the LISP routines I have converted to "autoloading", but
the load time for these menus is significant and they of course load with
every drawing. Some of the routines are external files, some are codes right
in the MNL.

What I'm hoping for is that someone(s) can point me in a direction(s) that
allows me to load these routines once and minimize the time it takes to load
them. I'm thinking it will involve some combination of partial CUIs,
workspaces, acad.lsp and acaddoc.lsp...

I'm starting this installation with a clean slate if it kills me (as long as
it doesn't kill production)...

Thanks for any help!
Message 13 of 39
Anonymous
in reply to: Anonymous

I am to the point of it creating the log file and that is about it. It is
blank and does not get updated after that. Also, when loading my lisp to
test I get the following:

Command: appload
xxRCL.LSP successfully loaded.
Command: bad argument type: stringp nil
Command:

Any help is appreciated,
Thanks,


"pkirill" wrote in message
news:5199989@discussion.autodesk.com...
Put the code below in a txt file and call it "LISPLOG.LSP". Change "G:/CAD
Standards/LogFiles/" to a location on your network that everyone can write
to. Save it and put that file in your AutoCAD path. Then load the
LISPLOG.LSP file from your ACADDOC.LSP.

In every LISP routine you want to log add a call to (lisplog) - for example:

(defun C:MYLISP ()
(alert "This routine is being logged")
(lisplog)
(princ)
)

Every routine that has (lisplog) in it, writes out to a text file (or csv,
or log, etc.) username, date and routine. Like this:

paulk,6/7/06,(C:QL)
paulk,6/7/06,(C:SCA)
paulk,6/7/06,(C:Q)
paulk,6/7/06,(C:PL)
paulk,6/7/06,(C:PL)
paulk,6/7/06,(C:VPL)
paulk,6/7/06,(C:VPU)

I'm sure the data could be organized better, but I didn't want to spend a
bunch of time on it...

"SD'y" wrote in message
news:5199779@discussion.autodesk.com...
Could you explain how this works, or how to use it?
Thanks,

"pkirill" wrote in message
news:5199740@discussion.autodesk.com...
Ah - about a year ago I went through all the LISPs we have and inserted a
call to another little routine called (lisplog) which rights out the
command, date and time, and user to a csv file. I am going through and
evaluating a bunch of our routines to see if they aren't being used because
they are useles or because no on knows about them...

In case anyone wants it, here it is. I can't take full credit as I had help
from this NG and the LISP NG for the reactor part...

;;;(lisplog) - add this inside any LISP routine you want to log

(defun setlispname (reactor name)
(setq *lispname* (car name))
)
(vlr-lisp-reactor nil '((:vlr-lispWillStart . setlispname)))
(defun lisplog ()
(setq *CDATE* (rtos (getvar "cdate") 2 4)
YEAR (substr *CDATE* 3 2)
MONTH (itoa (atoi (substr *CDATE* 5 2)))
DAY (itoa (atoi (substr *CDATE* 7 2)))
)
(setq CURDATE (strcat MONTH "/" DAY "/" YEAR))
(setq f (open (strcat "G:/CAD Standards/LogFiles/" (getvar "LOGINNAME")
"_Lisp.log") "a")
)
(write-line (strcat (getvar "LOGINNAME") "," CURDATE "," *lispname*) f)
(close f)
(princ)
)



"FG" wrote in message
news:5199002@discussion.autodesk.com...
Its also a good time to ask everyone which commands are no longer being
used. We seem to remove a few each year as autodesk incorporates them into
the program.


"pkirill" wrote in message
news:5198784@discussion.autodesk.com...
I don't think it's the "autoload" code spcifically that's slow. I'm looking
at the process as a whole. And on the whole, it's too slow for my taste.
I've been moving a bunch of the preliminary stuff to the acaddoc.lsp and
that seems to speed things up a bit. There are also some vba macros that
load up into each drawing - why I don't know yet. There seems to be no
reason why they can't load when the command is called. I think I can back
those out to the mnl's...

I guess, I'm just looking for some creative ideas for minimizing startup
time. Your shortcut idea is a nice one...

Also, for a while I was in the habit of grouping a bunch of similar routines
into one LISP file. For example we have a bunch of block insertion routines
that control insertion scale, layering, insert multiple, etc. I put them all
in one BlockInsertion.LSP. Some have upwards of 20 small routines in them. I
think these are part of what's bogging me down and I need to harvest the
C:XXXX and put those in an autoload list.


"David Allen" wrote in message
news:5197904@discussion.autodesk.com...
Are you saying that the autoload code is slow?
What I do in my shortcut key lisp and my menu's is the simple code of
(defun c:G ()
(ECHOOFF) (princ "\nMacro >\tGlue: ")
(if (not c:glue)(load "glue.lsp")) (c:glue)
(princ)
)

or in my menu
^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF

The only code I place in my .mnl is code to place the pulldown menu in the
list
I have an acaddoc.lsp that loads my shortcuts, variable settings, config and
a few
other items that have to run on every drawing.

I too have 4 decipline menu's
I don't load much code per decipline.

Not sure what else your code could be doing

--
Dave

"pkirill" wrote in message
news:5197024@discussion.autodesk.com...
I am just starting to get us ready to migrate from AutoCAD 2005 to AutoCAD
2007 and I'm trying to fine tune a menu system that has not really been
touched since 2002. We basically have 4 menus (MNU's) - one for "the
company" and one for each discipline (Electrical , HVAC, Plumbing). Each of
these menus has an MNL associated that loads a TON of lisp routines and
variables. Most of the LISP routines I have converted to "autoloading", but
the load time for these menus is significant and they of course load with
every drawing. Some of the routines are external files, some are codes right
in the MNL.

What I'm hoping for is that someone(s) can point me in a direction(s) that
allows me to load these routines once and minimize the time it takes to load
them. I'm thinking it will involve some combination of partial CUIs,
workspaces, acad.lsp and acaddoc.lsp...

I'm starting this installation with a clean slate if it kills me (as long as
it doesn't kill production)...

Thanks for any help!
Message 14 of 39
Anonymous
in reply to: Anonymous

Can you email me directly with your test LISP and what you modified in the
lisplog code? Just take out the NO SPAM and the spaces in my address...


"SD'y" wrote in message
news:5200040@discussion.autodesk.com...
I am to the point of it creating the log file and that is about it. It is
blank and does not get updated after that. Also, when loading my lisp to
test I get the following:

Command: appload
xxRCL.LSP successfully loaded.
Command: bad argument type: stringp nil
Command:

Any help is appreciated,
Thanks,


"pkirill" wrote in message
news:5199989@discussion.autodesk.com...
Put the code below in a txt file and call it "LISPLOG.LSP". Change "G:/CAD
Standards/LogFiles/" to a location on your network that everyone can write
to. Save it and put that file in your AutoCAD path. Then load the
LISPLOG.LSP file from your ACADDOC.LSP.

In every LISP routine you want to log add a call to (lisplog) - for example:

(defun C:MYLISP ()
(alert "This routine is being logged")
(lisplog)
(princ)
)

Every routine that has (lisplog) in it, writes out to a text file (or csv,
or log, etc.) username, date and routine. Like this:

paulk,6/7/06,(C:QL)
paulk,6/7/06,(C:SCA)
paulk,6/7/06,(C:Q)
paulk,6/7/06,(C:PL)
paulk,6/7/06,(C:PL)
paulk,6/7/06,(C:VPL)
paulk,6/7/06,(C:VPU)

I'm sure the data could be organized better, but I didn't want to spend a
bunch of time on it...

"SD'y" wrote in message
news:5199779@discussion.autodesk.com...
Could you explain how this works, or how to use it?
Thanks,

"pkirill" wrote in message
news:5199740@discussion.autodesk.com...
Ah - about a year ago I went through all the LISPs we have and inserted a
call to another little routine called (lisplog) which rights out the
command, date and time, and user to a csv file. I am going through and
evaluating a bunch of our routines to see if they aren't being used because
they are useles or because no on knows about them...

In case anyone wants it, here it is. I can't take full credit as I had help
from this NG and the LISP NG for the reactor part...

;;;(lisplog) - add this inside any LISP routine you want to log

(defun setlispname (reactor name)
(setq *lispname* (car name))
)
(vlr-lisp-reactor nil '((:vlr-lispWillStart . setlispname)))
(defun lisplog ()
(setq *CDATE* (rtos (getvar "cdate") 2 4)
YEAR (substr *CDATE* 3 2)
MONTH (itoa (atoi (substr *CDATE* 5 2)))
DAY (itoa (atoi (substr *CDATE* 7 2)))
)
(setq CURDATE (strcat MONTH "/" DAY "/" YEAR))
(setq f (open (strcat "G:/CAD Standards/LogFiles/" (getvar "LOGINNAME")
"_Lisp.log") "a")
)
(write-line (strcat (getvar "LOGINNAME") "," CURDATE "," *lispname*) f)
(close f)
(princ)
)



"FG" wrote in message
news:5199002@discussion.autodesk.com...
Its also a good time to ask everyone which commands are no longer being
used. We seem to remove a few each year as autodesk incorporates them into
the program.


"pkirill" wrote in message
news:5198784@discussion.autodesk.com...
I don't think it's the "autoload" code spcifically that's slow. I'm looking
at the process as a whole. And on the whole, it's too slow for my taste.
I've been moving a bunch of the preliminary stuff to the acaddoc.lsp and
that seems to speed things up a bit. There are also some vba macros that
load up into each drawing - why I don't know yet. There seems to be no
reason why they can't load when the command is called. I think I can back
those out to the mnl's...

I guess, I'm just looking for some creative ideas for minimizing startup
time. Your shortcut idea is a nice one...

Also, for a while I was in the habit of grouping a bunch of similar routines
into one LISP file. For example we have a bunch of block insertion routines
that control insertion scale, layering, insert multiple, etc. I put them all
in one BlockInsertion.LSP. Some have upwards of 20 small routines in them. I
think these are part of what's bogging me down and I need to harvest the
C:XXXX and put those in an autoload list.


"David Allen" wrote in message
news:5197904@discussion.autodesk.com...
Are you saying that the autoload code is slow?
What I do in my shortcut key lisp and my menu's is the simple code of
(defun c:G ()
(ECHOOFF) (princ "\nMacro >\tGlue: ")
(if (not c:glue)(load "glue.lsp")) (c:glue)
(princ)
)

or in my menu
^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF

The only code I place in my .mnl is code to place the pulldown menu in the
list
I have an acaddoc.lsp that loads my shortcuts, variable settings, config and
a few
other items that have to run on every drawing.

I too have 4 decipline menu's
I don't load much code per decipline.

Not sure what else your code could be doing

--
Dave

"pkirill" wrote in message
news:5197024@discussion.autodesk.com...
I am just starting to get us ready to migrate from AutoCAD 2005 to AutoCAD
2007 and I'm trying to fine tune a menu system that has not really been
touched since 2002. We basically have 4 menus (MNU's) - one for "the
company" and one for each discipline (Electrical , HVAC, Plumbing). Each of
these menus has an MNL associated that loads a TON of lisp routines and
variables. Most of the LISP routines I have converted to "autoloading", but
the load time for these menus is significant and they of course load with
every drawing. Some of the routines are external files, some are codes right
in the MNL.

What I'm hoping for is that someone(s) can point me in a direction(s) that
allows me to load these routines once and minimize the time it takes to load
them. I'm thinking it will involve some combination of partial CUIs,
workspaces, acad.lsp and acaddoc.lsp...

I'm starting this installation with a clean slate if it kills me (as long as
it doesn't kill production)...

Thanks for any help!
Message 15 of 39
Anonymous
in reply to: Anonymous

I actually have it working, kinda. Seems to have something to do with the
order they load. If I go back and forth and reload them a few times it
starts working. Let me play around and see what I can learn. If I do not bet
it I will take you up on your offer. Any insight on the loading order would
be helpful.
Thanks,
S

"pkirill" wrote in message
news:5200250@discussion.autodesk.com...
Can you email me directly with your test LISP and what you modified in the
lisplog code? Just take out the NO SPAM and the spaces in my address...


"SD'y" wrote in message
news:5200040@discussion.autodesk.com...
I am to the point of it creating the log file and that is about it. It is
blank and does not get updated after that. Also, when loading my lisp to
test I get the following:

Command: appload
xxRCL.LSP successfully loaded.
Command: bad argument type: stringp nil
Command:

Any help is appreciated,
Thanks,


"pkirill" wrote in message
news:5199989@discussion.autodesk.com...
Put the code below in a txt file and call it "LISPLOG.LSP". Change "G:/CAD
Standards/LogFiles/" to a location on your network that everyone can write
to. Save it and put that file in your AutoCAD path. Then load the
LISPLOG.LSP file from your ACADDOC.LSP.

In every LISP routine you want to log add a call to (lisplog) - for example:

(defun C:MYLISP ()
(alert "This routine is being logged")
(lisplog)
(princ)
)

Every routine that has (lisplog) in it, writes out to a text file (or csv,
or log, etc.) username, date and routine. Like this:

paulk,6/7/06,(C:QL)
paulk,6/7/06,(C:SCA)
paulk,6/7/06,(C:Q)
paulk,6/7/06,(C:PL)
paulk,6/7/06,(C:PL)
paulk,6/7/06,(C:VPL)
paulk,6/7/06,(C:VPU)

I'm sure the data could be organized better, but I didn't want to spend a
bunch of time on it...

"SD'y" wrote in message
news:5199779@discussion.autodesk.com...
Could you explain how this works, or how to use it?
Thanks,

"pkirill" wrote in message
news:5199740@discussion.autodesk.com...
Ah - about a year ago I went through all the LISPs we have and inserted a
call to another little routine called (lisplog) which rights out the
command, date and time, and user to a csv file. I am going through and
evaluating a bunch of our routines to see if they aren't being used because
they are useles or because no on knows about them...

In case anyone wants it, here it is. I can't take full credit as I had help
from this NG and the LISP NG for the reactor part...

;;;(lisplog) - add this inside any LISP routine you want to log

(defun setlispname (reactor name)
(setq *lispname* (car name))
)
(vlr-lisp-reactor nil '((:vlr-lispWillStart . setlispname)))
(defun lisplog ()
(setq *CDATE* (rtos (getvar "cdate") 2 4)
YEAR (substr *CDATE* 3 2)
MONTH (itoa (atoi (substr *CDATE* 5 2)))
DAY (itoa (atoi (substr *CDATE* 7 2)))
)
(setq CURDATE (strcat MONTH "/" DAY "/" YEAR))
(setq f (open (strcat "G:/CAD Standards/LogFiles/" (getvar "LOGINNAME")
"_Lisp.log") "a")
)
(write-line (strcat (getvar "LOGINNAME") "," CURDATE "," *lispname*) f)
(close f)
(princ)
)



"FG" wrote in message
news:5199002@discussion.autodesk.com...
Its also a good time to ask everyone which commands are no longer being
used. We seem to remove a few each year as autodesk incorporates them into
the program.


"pkirill" wrote in message
news:5198784@discussion.autodesk.com...
I don't think it's the "autoload" code spcifically that's slow. I'm looking
at the process as a whole. And on the whole, it's too slow for my taste.
I've been moving a bunch of the preliminary stuff to the acaddoc.lsp and
that seems to speed things up a bit. There are also some vba macros that
load up into each drawing - why I don't know yet. There seems to be no
reason why they can't load when the command is called. I think I can back
those out to the mnl's...

I guess, I'm just looking for some creative ideas for minimizing startup
time. Your shortcut idea is a nice one...

Also, for a while I was in the habit of grouping a bunch of similar routines
into one LISP file. For example we have a bunch of block insertion routines
that control insertion scale, layering, insert multiple, etc. I put them all
in one BlockInsertion.LSP. Some have upwards of 20 small routines in them. I
think these are part of what's bogging me down and I need to harvest the
C:XXXX and put those in an autoload list.


"David Allen" wrote in message
news:5197904@discussion.autodesk.com...
Are you saying that the autoload code is slow?
What I do in my shortcut key lisp and my menu's is the simple code of
(defun c:G ()
(ECHOOFF) (princ "\nMacro >\tGlue: ")
(if (not c:glue)(load "glue.lsp")) (c:glue)
(princ)
)

or in my menu
^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF

The only code I place in my .mnl is code to place the pulldown menu in the
list
I have an acaddoc.lsp that loads my shortcuts, variable settings, config and
a few
other items that have to run on every drawing.

I too have 4 decipline menu's
I don't load much code per decipline.

Not sure what else your code could be doing

--
Dave

"pkirill" wrote in message
news:5197024@discussion.autodesk.com...
I am just starting to get us ready to migrate from AutoCAD 2005 to AutoCAD
2007 and I'm trying to fine tune a menu system that has not really been
touched since 2002. We basically have 4 menus (MNU's) - one for "the
company" and one for each discipline (Electrical , HVAC, Plumbing). Each of
these menus has an MNL associated that loads a TON of lisp routines and
variables. Most of the LISP routines I have converted to "autoloading", but
the load time for these menus is significant and they of course load with
every drawing. Some of the routines are external files, some are codes right
in the MNL.

What I'm hoping for is that someone(s) can point me in a direction(s) that
allows me to load these routines once and minimize the time it takes to load
them. I'm thinking it will involve some combination of partial CUIs,
workspaces, acad.lsp and acaddoc.lsp...

I'm starting this installation with a clean slate if it kills me (as long as
it doesn't kill production)...

Thanks for any help!
Message 16 of 39
Anonymous
in reply to: Anonymous

Try loading it here:

(defun C:MYLISP ()
(lisplog) ;;********************
(alert "This routine is being logged")
(princ)
)

"SD'y" wrote in message
news:5200299@discussion.autodesk.com...
I actually have it working, kinda. Seems to have something to do with the
order they load. If I go back and forth and reload them a few times it
starts working. Let me play around and see what I can learn. If I do not bet
it I will take you up on your offer. Any insight on the loading order would
be helpful.
Thanks,
S

"pkirill" wrote in message
news:5200250@discussion.autodesk.com...
Can you email me directly with your test LISP and what you modified in the
lisplog code? Just take out the NO SPAM and the spaces in my address...


"SD'y" wrote in message
news:5200040@discussion.autodesk.com...
I am to the point of it creating the log file and that is about it. It is
blank and does not get updated after that. Also, when loading my lisp to
test I get the following:

Command: appload
xxRCL.LSP successfully loaded.
Command: bad argument type: stringp nil
Command:

Any help is appreciated,
Thanks,


"pkirill" wrote in message
news:5199989@discussion.autodesk.com...
Put the code below in a txt file and call it "LISPLOG.LSP". Change "G:/CAD
Standards/LogFiles/" to a location on your network that everyone can write
to. Save it and put that file in your AutoCAD path. Then load the
LISPLOG.LSP file from your ACADDOC.LSP.

In every LISP routine you want to log add a call to (lisplog) - for example:

(defun C:MYLISP ()
(alert "This routine is being logged")
(lisplog)
(princ)
)

Every routine that has (lisplog) in it, writes out to a text file (or csv,
or log, etc.) username, date and routine. Like this:

paulk,6/7/06,(C:QL)
paulk,6/7/06,(C:SCA)
paulk,6/7/06,(C:Q)
paulk,6/7/06,(C:PL)
paulk,6/7/06,(C:PL)
paulk,6/7/06,(C:VPL)
paulk,6/7/06,(C:VPU)

I'm sure the data could be organized better, but I didn't want to spend a
bunch of time on it...

"SD'y" wrote in message
news:5199779@discussion.autodesk.com...
Could you explain how this works, or how to use it?
Thanks,

"pkirill" wrote in message
news:5199740@discussion.autodesk.com...
Ah - about a year ago I went through all the LISPs we have and inserted a
call to another little routine called (lisplog) which rights out the
command, date and time, and user to a csv file. I am going through and
evaluating a bunch of our routines to see if they aren't being used because
they are useles or because no on knows about them...

In case anyone wants it, here it is. I can't take full credit as I had help
from this NG and the LISP NG for the reactor part...

;;;(lisplog) - add this inside any LISP routine you want to log

(defun setlispname (reactor name)
(setq *lispname* (car name))
)
(vlr-lisp-reactor nil '((:vlr-lispWillStart . setlispname)))
(defun lisplog ()
(setq *CDATE* (rtos (getvar "cdate") 2 4)
YEAR (substr *CDATE* 3 2)
MONTH (itoa (atoi (substr *CDATE* 5 2)))
DAY (itoa (atoi (substr *CDATE* 7 2)))
)
(setq CURDATE (strcat MONTH "/" DAY "/" YEAR))
(setq f (open (strcat "G:/CAD Standards/LogFiles/" (getvar "LOGINNAME")
"_Lisp.log") "a")
)
(write-line (strcat (getvar "LOGINNAME") "," CURDATE "," *lispname*) f)
(close f)
(princ)
)



"FG" wrote in message
news:5199002@discussion.autodesk.com...
Its also a good time to ask everyone which commands are no longer being
used. We seem to remove a few each year as autodesk incorporates them into
the program.


"pkirill" wrote in message
news:5198784@discussion.autodesk.com...
I don't think it's the "autoload" code spcifically that's slow. I'm looking
at the process as a whole. And on the whole, it's too slow for my taste.
I've been moving a bunch of the preliminary stuff to the acaddoc.lsp and
that seems to speed things up a bit. There are also some vba macros that
load up into each drawing - why I don't know yet. There seems to be no
reason why they can't load when the command is called. I think I can back
those out to the mnl's...

I guess, I'm just looking for some creative ideas for minimizing startup
time. Your shortcut idea is a nice one...

Also, for a while I was in the habit of grouping a bunch of similar routines
into one LISP file. For example we have a bunch of block insertion routines
that control insertion scale, layering, insert multiple, etc. I put them all
in one BlockInsertion.LSP. Some have upwards of 20 small routines in them. I
think these are part of what's bogging me down and I need to harvest the
C:XXXX and put those in an autoload list.


"David Allen" wrote in message
news:5197904@discussion.autodesk.com...
Are you saying that the autoload code is slow?
What I do in my shortcut key lisp and my menu's is the simple code of
(defun c:G ()
(ECHOOFF) (princ "\nMacro >\tGlue: ")
(if (not c:glue)(load "glue.lsp")) (c:glue)
(princ)
)

or in my menu
^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF

The only code I place in my .mnl is code to place the pulldown menu in the
list
I have an acaddoc.lsp that loads my shortcuts, variable settings, config and
a few
other items that have to run on every drawing.

I too have 4 decipline menu's
I don't load much code per decipline.

Not sure what else your code could be doing

--
Dave

"pkirill" wrote in message
news:5197024@discussion.autodesk.com...
I am just starting to get us ready to migrate from AutoCAD 2005 to AutoCAD
2007 and I'm trying to fine tune a menu system that has not really been
touched since 2002. We basically have 4 menus (MNU's) - one for "the
company" and one for each discipline (Electrical , HVAC, Plumbing). Each of
these menus has an MNL associated that loads a TON of lisp routines and
variables. Most of the LISP routines I have converted to "autoloading", but
the load time for these menus is significant and they of course load with
every drawing. Some of the routines are external files, some are codes right
in the MNL.

What I'm hoping for is that someone(s) can point me in a direction(s) that
allows me to load these routines once and minimize the time it takes to load
them. I'm thinking it will involve some combination of partial CUIs,
workspaces, acad.lsp and acaddoc.lsp...

I'm starting this installation with a clean slate if it kills me (as long as
it doesn't kill production)...

Thanks for any help!
Message 17 of 39
Anonymous
in reply to: Anonymous

This is where I am at. I all works ONLY if I load the LISPLOG first then
MYLISP next, after the dwg is open. It does not work using acaddoc.lsp with
them loading in the same order. Why would that be?

"pkirill" wrote in message
news:5200356@discussion.autodesk.com...
Try loading it here:

(defun C:MYLISP ()
(lisplog) ;;********************
(alert "This routine is being logged")
(princ)
)

"SD'y" wrote in message
news:5200299@discussion.autodesk.com...
I actually have it working, kinda. Seems to have something to do with the
order they load. If I go back and forth and reload them a few times it
starts working. Let me play around and see what I can learn. If I do not bet
it I will take you up on your offer. Any insight on the loading order would
be helpful.
Thanks,
S

"pkirill" wrote in message
news:5200250@discussion.autodesk.com...
Can you email me directly with your test LISP and what you modified in the
lisplog code? Just take out the NO SPAM and the spaces in my address...


"SD'y" wrote in message
news:5200040@discussion.autodesk.com...
I am to the point of it creating the log file and that is about it. It is
blank and does not get updated after that. Also, when loading my lisp to
test I get the following:

Command: appload
xxRCL.LSP successfully loaded.
Command: bad argument type: stringp nil
Command:

Any help is appreciated,
Thanks,


"pkirill" wrote in message
news:5199989@discussion.autodesk.com...
Put the code below in a txt file and call it "LISPLOG.LSP". Change "G:/CAD
Standards/LogFiles/" to a location on your network that everyone can write
to. Save it and put that file in your AutoCAD path. Then load the
LISPLOG.LSP file from your ACADDOC.LSP.

In every LISP routine you want to log add a call to (lisplog) - for example:

(defun C:MYLISP ()
(alert "This routine is being logged")
(lisplog)
(princ)
)

Every routine that has (lisplog) in it, writes out to a text file (or csv,
or log, etc.) username, date and routine. Like this:

paulk,6/7/06,(C:QL)
paulk,6/7/06,(C:SCA)
paulk,6/7/06,(C:Q)
paulk,6/7/06,(C:PL)
paulk,6/7/06,(C:PL)
paulk,6/7/06,(C:VPL)
paulk,6/7/06,(C:VPU)

I'm sure the data could be organized better, but I didn't want to spend a
bunch of time on it...

"SD'y" wrote in message
news:5199779@discussion.autodesk.com...
Could you explain how this works, or how to use it?
Thanks,

"pkirill" wrote in message
news:5199740@discussion.autodesk.com...
Ah - about a year ago I went through all the LISPs we have and inserted a
call to another little routine called (lisplog) which rights out the
command, date and time, and user to a csv file. I am going through and
evaluating a bunch of our routines to see if they aren't being used because
they are useles or because no on knows about them...

In case anyone wants it, here it is. I can't take full credit as I had help
from this NG and the LISP NG for the reactor part...

;;;(lisplog) - add this inside any LISP routine you want to log

(defun setlispname (reactor name)
(setq *lispname* (car name))
)
(vlr-lisp-reactor nil '((:vlr-lispWillStart . setlispname)))
(defun lisplog ()
(setq *CDATE* (rtos (getvar "cdate") 2 4)
YEAR (substr *CDATE* 3 2)
MONTH (itoa (atoi (substr *CDATE* 5 2)))
DAY (itoa (atoi (substr *CDATE* 7 2)))
)
(setq CURDATE (strcat MONTH "/" DAY "/" YEAR))
(setq f (open (strcat "G:/CAD Standards/LogFiles/" (getvar "LOGINNAME")
"_Lisp.log") "a")
)
(write-line (strcat (getvar "LOGINNAME") "," CURDATE "," *lispname*) f)
(close f)
(princ)
)



"FG" wrote in message
news:5199002@discussion.autodesk.com...
Its also a good time to ask everyone which commands are no longer being
used. We seem to remove a few each year as autodesk incorporates them into
the program.


"pkirill" wrote in message
news:5198784@discussion.autodesk.com...
I don't think it's the "autoload" code spcifically that's slow. I'm looking
at the process as a whole. And on the whole, it's too slow for my taste.
I've been moving a bunch of the preliminary stuff to the acaddoc.lsp and
that seems to speed things up a bit. There are also some vba macros that
load up into each drawing - why I don't know yet. There seems to be no
reason why they can't load when the command is called. I think I can back
those out to the mnl's...

I guess, I'm just looking for some creative ideas for minimizing startup
time. Your shortcut idea is a nice one...

Also, for a while I was in the habit of grouping a bunch of similar routines
into one LISP file. For example we have a bunch of block insertion routines
that control insertion scale, layering, insert multiple, etc. I put them all
in one BlockInsertion.LSP. Some have upwards of 20 small routines in them. I
think these are part of what's bogging me down and I need to harvest the
C:XXXX and put those in an autoload list.


"David Allen" wrote in message
news:5197904@discussion.autodesk.com...
Are you saying that the autoload code is slow?
What I do in my shortcut key lisp and my menu's is the simple code of
(defun c:G ()
(ECHOOFF) (princ "\nMacro >\tGlue: ")
(if (not c:glue)(load "glue.lsp")) (c:glue)
(princ)
)

or in my menu
^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF

The only code I place in my .mnl is code to place the pulldown menu in the
list
I have an acaddoc.lsp that loads my shortcuts, variable settings, config and
a few
other items that have to run on every drawing.

I too have 4 decipline menu's
I don't load much code per decipline.

Not sure what else your code could be doing

--
Dave

"pkirill" wrote in message
news:5197024@discussion.autodesk.com...
I am just starting to get us ready to migrate from AutoCAD 2005 to AutoCAD
2007 and I'm trying to fine tune a menu system that has not really been
touched since 2002. We basically have 4 menus (MNU's) - one for "the
company" and one for each discipline (Electrical , HVAC, Plumbing). Each of
these menus has an MNL associated that loads a TON of lisp routines and
variables. Most of the LISP routines I have converted to "autoloading", but
the load time for these menus is significant and they of course load with
every drawing. Some of the routines are external files, some are codes right
in the MNL.

What I'm hoping for is that someone(s) can point me in a direction(s) that
allows me to load these routines once and minimize the time it takes to load
them. I'm thinking it will involve some combination of partial CUIs,
workspaces, acad.lsp and acaddoc.lsp...

I'm starting this installation with a clean slate if it kills me (as long as
it doesn't kill production)...

Thanks for any help!
Message 18 of 39
Anonymous
in reply to: Anonymous

For me and you who are keyboard shortcut people this works well but I find
most people cannot remember the commands
This is why I switched from this method to the tool palette for my blocks.


--
Dave

"pkirill" wrote in message
news:5198784@discussion.autodesk.com...

Also, for a while I was in the habit of grouping a bunch of similar routines
into one LISP file. For example we have a bunch of block insertion routines
that control insertion scale, layering, insert multiple, etc. I put them all
in one BlockInsertion.LSP. Some have upwards of 20 small routines in them. I
think these are part of what's bogging me down and I need to harvest the
C:XXXX and put those in an autoload list.
Message 19 of 39
Anonymous
in reply to: Anonymous

On Wed, 7 Jun 2006 18:09:30 +0000, pkirill wrote:

>I guess, I'm just looking for some creative ideas for minimizing startup
>time.

>Also, for a while I was in the habit of grouping a bunch of similar routines
>into one LISP file.

Here's my approach, which works pretty well:

I currently have over 1,000 keyboard macors and utilities which my users use on
a daily basis. As you can imagine, there's a lot of code that doesn't need to be
loaded for each DWG file, so I worked to minimize code bloat.

First, I removed almost everything from acaddoc.lsp, opting to load things
externally instead. This was done to more easily manage things granularly than
have to deal with a source file that's way huge. I can also cut off the loading
of all customization with a single comment, which is a nice little software
valve to have.

Second, I created many smaller macro libraries, grouping each macro into a file
named by starting letter, e.g., a.lsp, b.lsp, c.lsp, and so on. This made it
easier to work on macros files instead of having everything in one huge honkin'
LSP file.

To edit these easily, I have an MEDIT command, that asks for a single letter
character, and the appropriate macros file loads up in my text editor (I don't
use the VLISP editor except when compiling stuff). So "medit" "m" would load up
the "m.lsp" source file for editing.

Thirdly, I created many small "support function" libraries, one for each type of
work it does. For example, here's a partial list:

corelib.lsp - Core global functions (loaded from acaddoc.lsp)
reglib.lsp - registry handling functions
blocklib.lsp - Block handling
entlib.lsp - entity data handling
annotlib.lsp - Annotation (text, dimstyle) handling
dialoglib.lsp - Dialog box functions
filelib.lsp - File handling
geomlib.lsp - Geometry handling
layerlib.lsp - Layer handling

and so on.

The idea here is that each macro uses (and reuses) code from one or more of
these function libraries, instead of having 10 macros which have the same
function defined in the macro code itself. This maximizes code reuse, making the
overall footprint of the LSP files much smaller.

In my corelib.lsp file, I created "include" functions which checks and loads the
required function libraries.

For example, (core:IncludeFileLib) will check to see if filelib.lsp is loaded.
So, in a macro that is going to access files (such as a block insertion command
macro) I have something like this

;; Insert a file as a block
(defun c:IF ()
;; load required function libraries
(core:IncludeFileLib)
(core:IncludeBlockLib)

(body of code here)
:
:
(princ)
)

That way, the user only loads the support functions when they need them when the
macro is run for the first time.

After all of this is done, I compile all of the "macro" functions into a single
"MACROS.VLX" file, and compile each of the smaller function libraries into their
own VLX files. My startup code only needs to load the single "macros.vlx" file;
all the support function files are then demand loaded.

I use (autoload) only for some larger command utilities which have their own
dedicated LSP file. Because I have so many command macros, I did not want the
overhead of a (autoload) function for each one. I would also have to track thems
in two locations, one as I write the command function, then also create another
(autoload) statement in the acaddoc.lsp file.

If I could figure out a way to load a set of macros automatically just be
recognizing the first character, that would be cool, so I wouldn't even have to
compile/load a macros.vlx at all - running the "IF" command would load the
"i.vlx" file and run the command. But that's something for the future...

Because everything is compiled into smaller VLX files, the overhead for loading
stuff is greatly reduced over the raw LSP code, and provides a means of securing
the source code, as users have access to compiled VLX files - my LSP source is
in a separate folder structure with admin-only access rights.

Hope this gives you some ideas.

Matt
mstachoni@comcast.net
mstachoni@bhhtait.com





> For example we have a bunch of block insertion routines
>that control insertion scale, layering, insert multiple, etc. I put them all
>in one BlockInsertion.LSP. Some have upwards of 20 small routines in them. I
>think these are part of what's bogging me down and I need to harvest the
>C:XXXX and put those in an autoload list.
>
>
>"David Allen" wrote in message
>news:5197904@discussion.autodesk.com...
>Are you saying that the autoload code is slow?
>What I do in my shortcut key lisp and my menu's is the simple code of
>(defun c:G ()
> (ECHOOFF) (princ "\nMacro >\tGlue: ")
> (if (not c:glue)(load "glue.lsp")) (c:glue)
> (princ)
>)
>
>or in my menu
>^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF
>
>The only code I place in my .mnl is code to place the pulldown menu in the
>list
>I have an acaddoc.lsp that loads my shortcuts, variable settings, config and
>a few
>other items that have to run on every drawing.
>
>I too have 4 decipline menu's
>I don't load much code per decipline.
>
>Not sure what else your code could be doing
Message 20 of 39
Anonymous
in reply to: Anonymous

one thing I found useful is to make sure your pulldowns have the key-in tabbed to the right, like [Draw Box\tBX]...
That way, you can find a key-in using the pulldown once, then type the key-in next time.
Pull downs are nice for organization of things into categories, one big list of key-ins or even a help file (how I used
to do it) is cumbersome..


Matt Stachoni
|>On Wed, 7 Jun 2006 18:09:30 +0000, pkirill wrote:
|>
|>>I guess, I'm just looking for some creative ideas for minimizing startup
|>>time.
|>
|>>Also, for a while I was in the habit of grouping a bunch of similar routines
|>>into one LISP file.
|>
|>Here's my approach, which works pretty well:
|>
|>I currently have over 1,000 keyboard macors and utilities which my users use on
|>a daily basis. As you can imagine, there's a lot of code that doesn't need to be
|>loaded for each DWG file, so I worked to minimize code bloat.
|>
|>First, I removed almost everything from acaddoc.lsp, opting to load things
|>externally instead. This was done to more easily manage things granularly than
|>have to deal with a source file that's way huge. I can also cut off the loading
|>of all customization with a single comment, which is a nice little software
|>valve to have.
|>
|>Second, I created many smaller macro libraries, grouping each macro into a file
|>named by starting letter, e.g., a.lsp, b.lsp, c.lsp, and so on. This made it
|>easier to work on macros files instead of having everything in one huge honkin'
|>LSP file.
|>
|>To edit these easily, I have an MEDIT command, that asks for a single letter
|>character, and the appropriate macros file loads up in my text editor (I don't
|>use the VLISP editor except when compiling stuff). So "medit" "m" would load up
|>the "m.lsp" source file for editing.
|>
|>Thirdly, I created many small "support function" libraries, one for each type of
|>work it does. For example, here's a partial list:
|>
|>corelib.lsp - Core global functions (loaded from acaddoc.lsp)
|>reglib.lsp - registry handling functions
|>blocklib.lsp - Block handling
|>entlib.lsp - entity data handling
|>annotlib.lsp - Annotation (text, dimstyle) handling
|>dialoglib.lsp - Dialog box functions
|>filelib.lsp - File handling
|>geomlib.lsp - Geometry handling
|>layerlib.lsp - Layer handling
|>
|>and so on.
|>
|>The idea here is that each macro uses (and reuses) code from one or more of
|>these function libraries, instead of having 10 macros which have the same
|>function defined in the macro code itself. This maximizes code reuse, making the
|>overall footprint of the LSP files much smaller.
|>
|>In my corelib.lsp file, I created "include" functions which checks and loads the
|>required function libraries.
|>
|>For example, (core:IncludeFileLib) will check to see if filelib.lsp is loaded.
|>So, in a macro that is going to access files (such as a block insertion command
|>macro) I have something like this
|>
|>;; Insert a file as a block
|>(defun c:IF ()
|> ;; load required function libraries
|> (core:IncludeFileLib)
|> (core:IncludeBlockLib)
|>
|> (body of code here)
|> :
|> :
|> (princ)
|>)
|>
|>That way, the user only loads the support functions when they need them when the
|>macro is run for the first time.
|>
|>After all of this is done, I compile all of the "macro" functions into a single
|>"MACROS.VLX" file, and compile each of the smaller function libraries into their
|>own VLX files. My startup code only needs to load the single "macros.vlx" file;
|>all the support function files are then demand loaded.
|>
|>I use (autoload) only for some larger command utilities which have their own
|>dedicated LSP file. Because I have so many command macros, I did not want the
|>overhead of a (autoload) function for each one. I would also have to track thems
|>in two locations, one as I write the command function, then also create another
|>(autoload) statement in the acaddoc.lsp file.
|>
|>If I could figure out a way to load a set of macros automatically just be
|>recognizing the first character, that would be cool, so I wouldn't even have to
|>compile/load a macros.vlx at all - running the "IF" command would load the
|>"i.vlx" file and run the command. But that's something for the future...
|>
|>Because everything is compiled into smaller VLX files, the overhead for loading
|>stuff is greatly reduced over the raw LSP code, and provides a means of securing
|>the source code, as users have access to compiled VLX files - my LSP source is
|>in a separate folder structure with admin-only access rights.
|>
|>Hope this gives you some ideas.
|>
|>Matt
|>mstachoni@comcast.net
|>mstachoni@bhhtait.com
|>
|>
|>
|>
|>
|>> For example we have a bunch of block insertion routines
|>>that control insertion scale, layering, insert multiple, etc. I put them all
|>>in one BlockInsertion.LSP. Some have upwards of 20 small routines in them. I
|>>think these are part of what's bogging me down and I need to harvest the
|>>C:XXXX and put those in an autoload list.
|>>
|>>
|>>"David Allen" wrote in message
|>>news:5197904@discussion.autodesk.com...
|>>Are you saying that the autoload code is slow?
|>>What I do in my shortcut key lisp and my menu's is the simple code of
|>>(defun c:G ()
|>> (ECHOOFF) (princ "\nMacro >\tGlue: ")
|>> (if (not c:glue)(load "glue.lsp")) (c:glue)
|>> (princ)
|>>)
|>>
|>>or in my menu
|>>^C^C^P(if (not c:MXREF)(load "MULT-XREF.lsp"))^P MXREF
|>>
|>>The only code I place in my .mnl is code to place the pulldown menu in the
|>>list
|>>I have an acaddoc.lsp that loads my shortcuts, variable settings, config and
|>>a few
|>>other items that have to run on every drawing.
|>>
|>>I too have 4 decipline menu's
|>>I don't load much code per decipline.
|>>
|>>Not sure what else your code could be doing
James Maeding
Civil Engineer and Programmer
jmaeding - athunsaker - com

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

Post to forums  

Administrator Productivity

Autodesk Design & Make Report