rules for acaddoc.lsp

[dbroada]

what are the rules for loading acaddoc.lsp? If there is more than one instance in your search paths does only the first get loaded or will they all get loaded in turn?

 

I am asking as I want to NETLOAD a vb.net routine on all machines at start-up. We have a few common folders that should be in everybodies search path and I would rather place my netload there than have to go to each machine.

 

Is acaddoc.lsp the best place to do this?

[Lee Mac]

If there is more than one instance in your search paths does only the first get loaded or will they all get loaded in turn?

 

When a drawing is opened, AutoCAD will first search the working directory (i.e. the directory in which the active drawing resides), and then all Support File Search Paths for the ACADDOC.lsp file and will load the first (and only the first) ACADDOC.lsp file found.

 

This behaviour can be very useful to exploit as you can have multiple ACADDOC.lsp files with customisations tailored for specific projects and have each ACADDOC.lsp located in the relevant project drawing folder. Then, when a drawing for a project is opened, AutoCAD will load only the ACADDOC.lsp file residing in the relevant project folder, since this becomes the working directory and only one ACADDOC.lsp is loaded when a drawing is opened.

[Tiger]

...

 

This behaviour can be very useful to exploit as you can have multiple ACADDOC.lsp files with customisations tailored for specific projects and have each ACADDOC.lsp located in the relevant project drawing folder. Then, when a drawing for a project is opened, AutoCAD will load only the ACADDOC.lsp file residing in the relevant project folder, since this becomes the working directory and only one ACADDOC.lsp is loaded when a drawing is opened.

 

Do I understand it correctly that you have to first open a drawing in that project file to get the working directory defined, and the next drawing you open will have the correct acaddoc.lsp file loaded with it?

[caddcop]

Does anyone have any examples of how they exploit this for various projects? Any Civil 3D specific tips would be really appreciated. There seems to be a dearth of information that CADD Managers need to make certain aspects of these products work in a real world situation.

[Lee Mac]

Do I understand it correctly that you have to first open a drawing in that project file to get the working directory defined, and the next drawing you open will have the correct acaddoc.lsp file loaded with it?

 

You are correct, however to clarify, you don't need to 'define' a working directory; whenever you open a drawing in AutoCAD, the directory in which that drawing resides automatically becomes the working directory, and AutoCAD will search the working directory before the SFSP for an ACADDOC.lsp to be loaded.

[Tiger]

You are correct, however to clarify, you don't need to 'define' a working directory; whenever you open a drawing in AutoCAD, the directory in which that drawing resides automatically becomes the working directory, and AutoCAD will search the working directory before the SFSP for an ACADDOC.lsp to be loaded.

 

Got it, thanks!

[dbroada]

Thanks Lee. I don't think any of us have an acaddoc.lsp of our own. At least a (findfile) didn't reveal one for me and the others are unlikely to have created their own.

 

One supplementary question though. I set up a little routine to put up an alert box against two logins. I got the alert box once while my guinea pig had it each time she opened a drawing. Is this a setting or was it because she was in MDI mode (or something else)?

[Lee Mac]

Got it, thanks!

 

You're welcome!

 

Thanks Lee. I don't think any of us have an acaddoc.lsp of our own. At least a (findfile) didn't reveal one for me and the others are unlikely to have created their own.

 

No problem; just be aware that (findfile), like AutoCAD, will only search the working directory and SFSP, and so if you have ACADDOC.lsp files in other directories, these won't be found by (findfile) but may be loaded as & when such directories become the working directory.

 

One supplementary question though. I set up a little routine to put up an alert box against two logins. I got the alert box once while my guinea pig had it each time she opened a drawing. Is this a setting or was it because she was in MDI mode (or something else)?

 

If the ACADDOC.lsp can be found for every drawing opened (i.e. it resides in a common support path, not a working directory for only one of the drawings), you should receive the alert box every time a drawing is opened.

 

There is the ACADLSPASDOC System Variable, however this setting controls whether the ACAD.lsp file is loaded with every drawing or only on application startup, and doesn't concern the ACADDOC.lsp file.

[BlackBox]

Does anyone have any examples of how they exploit this for various projects? Any Civil 3D specific tips would be really appreciated. There seems to be a dearth of information that CADD Managers need to make certain aspects of these products work in a real world situation.

 

In reverse order... As for the Civil 3D specific, what issues, or obstacles are you trying to overcome? I use Civil 3D daily for my work.

 

As to the question of project-specific use, and as a direct result of this:

 

... whenever you open a drawing in AutoCAD, the directory in which that drawing resides automatically becomes the working directory, and AutoCAD will search the working directory before the SFSP for an ACADDOC.lsp to be loaded.

 

... I've (for years) insisted that our CAD users _not_ use either Acad[.lsp[.fas[.vlx]]], or AcadDoc[.lsp[.fas[.vlx]]] for personal, or project customization in favor of another mechanism that I'll share in a moment. My reason for this is simple... It is this built-in behavior (to load from DwgPrefix prior to user-defined SFSP) that allows malicious code to exploit this and potentially infect a user's computer, and network.

 

Our Acad.lsp, and AcadDoc.lsp files are located on the network within SFSP for each Profile, and we do not allow compiled code in public locations to avoid accidental malicious goings on. We are fortunate to have hardware specs sufficient that even compiled LISP code has little performance gain, if any.

 

To load user-specific code, this snippet is included in AcadDoc.lsp:

 

((lambda (user / file)
  (if (setq file (findfile (strcat user ".lsp")))
    (load file)
  )
)
 (getvar 'loginname)
)

 

 

In kind, a simple adaptation will load project-specific code:

 

((lambda (projectCode / file)
  (if (setq file (findfile projectCode))
    (load file)
  )
)
 "project.lsp" ;; <-- any name of your choosing, NOT Acad.lsp, or AcadDoc.lsp
)

 

** Note - For efficiency, wrap these in the same function, or lambda expression. Split here for those who only choose to use one.

 

 

Separately, malicious code recently (last year) caused some issues in several of our offices across the US, which as we later found out stemmed from one user copying an infected legacy project from the archive where the Acad.fas was Hidden, and Read-Only (which FindFile will still find). This resulted in infecting his computer with backup malicious code files (in the event that the project side wasn't found), where the local worm would then self-replicate to any project not already infected, which resulted in others users being infected, etc. In direct response to this happening more than once (after IT 'killed' this virus for the third time), I decided enough was enough.

 

I was tired of having to be 'highly reactive' instead of proactive, and devised a method to 'search and destroy' so-to-speak prior to any Acad* files being loaded in the startup sequence... I coded a .NET plug-in that fired when the DocumentCreated Event is raised, which hunts down a list of any number of virus definitions, both in the working directory, and the entire SFSP as specified in a user-defined XML file.

 

After a great deal of encouragement from management, my corporate CAD group, and users no longer being infected as a result of this initiative done on my own time at home, I've submitted this to be published at Autodesk Exchange, and it is currently being reviewed.

 

Admittedly, this may not be perfect for everyone as-is, but it has certainly helped our working environment to be infection free since implementation, and I am entirely open to enhance it to benefit others as well.

 

I am also working to get Autodesk to reverse the order of operation for the FindFile() Method, such that rather than searching the DwgPrefix then user-defined SFSP as-is today, the user-defined SFSP be searched first, and then DwgPrefix. This will safeguard those who do use Acad* files, and those who do not will still be exposed to the same possible infection they face today.

[BlackBox]

No problem; just be aware that (findfile), like AutoCAD, will only search the working directory and SFSP, and so if you have ACADDOC.lsp files in other directories, these won't be found by (findfile) but may be loaded as & when such directories become the working directory.

 

Given a Support Path:

 

C:\foo\

 

... And a LISP file located here:

 

C:\foo\someFolder\someOtherFolder\foo.lsp

 

... This:

 

Command: sfsp+

SFSP+
"C:\foo\" has been added to SFSP.

Command:
Command: (findfile "[color="red"]someFolder\\someOtherFolder\\[/color]foo.lsp")
"C:\\foo\\someFolder\\someOtherFolder\\foo.lsp"

[Lee Mac]

... This:

 

Command: sfsp+

SFSP+
"C:\foo\" has been added to SFSP.

Command:
Command: (findfile "[color="red"]someFolder\\someOtherFolder\\[/color]foo.lsp")
"C:\\foo\\someFolder\\someOtherFolder\\foo.lsp"

 

Of course - however you are supplying a relative path, not just a filename.

 

If called with:

(findfile "acaddoc.lsp")

 

Only the working directory and SFSP will be searched.

[BlackBox]

I was attempting to build on your accurate post, by offering a means for others to load code files from sub-folders of those included in SFSP, and not correcting you, Lee.

[Lee Mac]

I was attempting to build on your accurate post, by offering a means for others to load code files from sub-folders of those included in SFSP, and not correcting you, Lee.

 

Apologies, I misinterpreted your post.

[BlackBox]

Apologies, I misinterpreted your post.

 

No apologies necessary my friend ; more often than I'd like, my quick posts are not as clear as they perhaps should be.

 

I probably shouldn't post as much as I do, as I am at work.

 

In any event, my reason for adding that in the first place, was that most (especially those who are new to Acad.lsp, and AcadDoc.lsp in my limited experience) are unaware of the relative path support of FindFile, let alone the Autoloader mechanism which I am using more and more these days (yes, even for LISP).

[dbroada]

If the ACADDOC.lsp can be found for every drawing opened (i.e. it resides in a common support path, not a working directory for only one of the drawings), you should receive the alert box every time a drawing is opened.

 

There is the ACADLSPASDOC System Variable, however this setting controls whether the ACAD.lsp file is loaded with every drawing or only on application startup, and doesn't concern the ACADDOC.lsp file.

Of course I could have tested this for myself, and the answer is I get one alert box per session when in SDI mode and one alert box per drawing when in MDI mode.

[caddcop]

In reverse order... As for the Civil 3D specific, what issues, or obstacles are you trying to overcome? I use Civil 3D daily for my work.

 

We are just starting with Civil 3D and I was thinking of possibly working folders or some other item that might vary from project to project.

[BlackBox]

We are just starting with Civil 3D and I was thinking of possibly working folders or some other item that might vary from project to project.

 

Well Civil 3D is built upon Map 3D, which is built upon AutoCAD, so anything either Map 3D, or AutoCAD can do, Civil 3D can do as well... I've found very few cases (at least nothing of concern) where built-in functionality in one (i.e., AutoCAD), didn't also function the same in Civil 3D. For the purposes of this thread, this means that the same rules apply for Acad.lsp, and AcadDoc.lsp user-defined files.

 

What is very different, is the Civil 3D (i.e., AECC*) Objects... Many (most) of these are not exposed to Visual LISP, and will either require an external COM Object to access said AECC* Objects, or for you to step up into .NET API... But even then, some things are still only exposed to COM, and not .NET API, so you may have the need for some late binding, etc.... Another discussion for another thread I'm afraid; just wanted to touch on it in case you had high hopes for Visual LISP in terms of Civil 3D.

 

Post'em, when you got'em (questions, that is).

[dbroada]

Following on from this, I now have my first VB.Net routine finished and dll produced but want to spread it around the office. How is the best way?

 

I don't particularly want to go in to the registry as that is a sackable offence and it will take forever to get clearance to do it with permission.

 

Is putting the NETLOAD command in acaddoc.lsp and place it in a common folder along with the dll a good enough way to do it? I anticipate updating the dll often so don't want to have it local to each machine (unless I have to). We have less than 8 machines (but more logins) running AutoCAD so it is fairly easy to ensure the shared folder is in the search path and that there are no local acaddoc.lsp files lurking anywhere. I was hoping to put it somewhere so that it only gets loaded once but I now know acaddoc gets loaded on each instance of AutoCAD. Most of us only work in SDI mode so that will only be one load but at least one person prefers MDI mode. Presumable the dll load gets overwritten with each netload rather than filling up memory.

 

Any other (simple) ideas?

 

EDIT=======================================

 

I have been a bit premature with this question. If I try to load the dll from acaddoc.lsp I get a security alert. I will have to sort that out before anything else.

 

another edit =================================

 

it would appear that I can use the acaddoc.lsp to netload my dll. If I load it from my C: or D: all is well but if I load it from the network I have security issues. Looks like I will be having to distribute the dll to all the machines. Shame, people here only read their emails when your answer to their question "what's gone wrong here" is "have you read the email".

 

Suplementary question, is it possible for acaddoc.lsp to copy the file from a central location to a local drive and load it from there? (Yes I will try but if somebody can stop me before I do something wrong I would be grateful!)

Edited March 18, 2013 by dbroada

[BlackBox]

Not sure what version you're using to test netloading your assembly (2011?), or where you're netloading from (local, or network folder?)... I might be able to help with more information.

 

 

 

As to the question of how one might netload code from Acad.lsp, I've used this quite successfully for some time:

 

((lambda (arxList arxFiles netFiles)

  (acad-push-dbmod)

  ;; Load arx utilities
  (foreach x arxFiles
    (if (and (findfile x)
             (not (vl-position (vl-filename-base x) arxList))
        )
      (vl-catch-all-apply 'arxload (list x))
    )
  )

  ;; Load net utilities
  (foreach dll netFiles
    (if (findfile dll)
      (progn
        (terpri)
        (command "netload" dll)
      )
    )
  )

  (acad-pop-dbmod)
)
 (arx)
 '(                                                                    ; arxFiles
   "YourFilePath\\YourAssemblyName.arx"
   ;;<-- Others
  )
 '(                                                                    ; netFiles
   "YourFilePath\\YourAssemblyName.dll"
   ;;<-- Others
  )
)

 

... Although, there are some other considerations that you should factor in, such as what version you'll be working with at present, and near future (i.e., upgrades?).

 

For example, using 2011 (.NET 3.5) as our enterprise standard currently, a small change to Acad.Exe.Config is required in order to enable the LoadFromRemoteSources Element (as Kean demonstrates here) which lets me netload assemblies from our network folder rather than replicating them (and keeping them up to date) on local disk.

 

Another reason version may be relevant, is 2012+ supports the Autoloader mechanism, which I am finding to be quite useful (despite it's deficiencies), especially when supporting multiple platforms, and versions. Again, more information is needed to be more specific, but this (I feel) is a broad stroke of options available to you.

[dbroada]

Thanks again BB. I am not sure if that was posted before or after my edits as I can't see posting times (have to run in compatibility mode when CODE tags have been used) but it doesn;t really matter.

 

As far as we know we will be using AutoCAD Electrical 2011 untill I retire. We were told we would be using 2008 until the evaluation of 2011 was complete sometime this year but 2011 appeared some time last year. All new machines are being supplied with Windows 7 64 bit OS so I wouldn't like to guess what will happen if I get a new machine at any time.

 

Looking at all the options I currently favour emailing the dll to each draughtsman and let them install it for themselves. Its been a long week already.