You can use the LIST command in AutoCAD to check the object DXF name.

Good morning all,

Is there a way I can change dynamic stamp attached from "Issued for Approval" to IFC using Lee Mac's Batte lisp routine. I love the way Batte can change attributes in a directory but only attribute it can change on dynamic stamp is the date. Any advice would be greatly appreciated.
Thank you,
David

Instead of loading via lisp, use the built-in loader within the CUIx utility

I have this routine loaded within a CUI under LISP Files.
If a routine is accidently not there, the file will not load any of the routines below.
How can I get keep loading even when a file is not there?

(defun C:cui_Loader()
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\85x11_L.lsp")
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\85x11_P.lsp")
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\11X17_L.lsp")
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\11X17_P.lsp")
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\22X34_L.lsp")
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\22X34_P.lsp")
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\24X36_L.lsp")
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\24X36_P.lsp")
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\30X42_L.lsp")
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\30X42_P.lsp")
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\36X48_L.lsp")
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\36X48_P.lsp")
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\1-10.lsp")
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\1-20.lsp")
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\1-30.lsp")
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\1-40.lsp")
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\1-50.lsp")
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\1-60.lsp")
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\1-80.lsp")
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\1-100.lsp")
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\1-200.lsp")
(load "\\\\Server1\\Autodesk\\CUI\\Ribbon\\1-500.lsp")
(princ))
(C:cui_Loader)

Thanks for any help

I'm pretty new to AutoCAD (and by that I mean I've done a couple of years programming on and off), but a very experienced software engineer/business analyst and I would back up the 2 to 3 years observation to get to the point of being reasonably comfortable with it.

I would back up what CADBloke said with a few extras: 

First and foremost, keep it simple.  If a function gets above a screens worth of code or has more than one foreach or switch/case statement, that's usually the prompt to see if you need to split code up into different functions.  Name things what they are and do not abbreviate unless you have to.  If a function is called GetThisThatAndTheOther, that's a prompt that it's doing too much and need splitting up.  The simpler the structure the easier it is to read...the easier it is to read the less debugging you do and the easier it is for others to pick up the logic of it.

Yes, wrap everything in Try/catch, but then make the error message publicly available.  It's become really fashionable to log errors and that suffers from the "what the eyes don't see the heart won't grieve" syndrome i.e. they get logged and forgotten.  If you have error handlers that shout out "sommits wrong" it keeps you honest and also helps the users develop confidence in your software...if users know you are being honest they will give you more leeway when things do go wrong.  Hide things and they will smack you when you're down.

The bulk of engineer/designer's I have worked with start off thinking that programming is trivial and easy to achieve.  They then hit various brick walls and develop a large headache.  It is an entire "profession" (and I use that word with grave reservations) in it's own right and needs to be treated with respect.  Given this lad is an intern and as green as a newly hewn branch he needs to start with the "Dummies guide to programming"...I'm not taking the mickey either.  You guys are all experienced, but i'll bet you can't name me the four principles of OOP design without looking it up....to be sure, most programmers can't either.  Without understanding those principles all programmers are condemned to writing spaghetti code.

regards, Paul