Author Topic: ACAD.lsp defining support paths in AutoCAD  (Read 4132 times)

0 Members and 1 Guest are viewing this topic.

zride91

  • Guest
ACAD.lsp defining support paths in AutoCAD
« on: June 27, 2012, 11:50:27 AM »
I have learned how to add the ACAD.lsp to be able to define the support paths in AutoCAD across my company, and it has worked GREAT!  The ONLY problem I am running into with this process is with add-on applications such as Carlson Survey and AutoCAD Raster Design.  When running these add-on applications through AutoCAD, they need paths to their support files.  When NOT running the applications, I do not want them in the list, as I do not want it to cause performace issues.

Does anyone have any suggestions on defining support paths with and without add-on applications???

Thank you!

BlackBox

  • King Gator
  • Posts: 3770
Re: ACAD.lsp defining support paths in AutoCAD
« Reply #1 on: June 27, 2012, 12:13:33 PM »

Doesn't Carlson use its own Profile?

Why not query the ActiveProfile, then implement the desired Support Paths?

I use different Application Icons for different Profiles in our setup, and each Profile has a different Acad.lsp and AcadDoc.lsp, which makes maintaining things a bit simpler here.

HTH
"How we think determines what we do, and what we do determines what we get."

dgorsman

  • Water Moccasin
  • Posts: 2437
Re: ACAD.lsp defining support paths in AutoCAD
« Reply #2 on: June 27, 2012, 12:23:46 PM »
And Raster Design can be demand loaded into any profile, so it only loads up when commands are invoked.  The support paths for this can be at the botttom of the list so they don't send your own file searches on wild goose chases.
If you are going to fly by the seat of your pants, expect friction burns.

try {GreatPower;}
   catch (notResponsible)
      {NextTime(PlanAhead);}
   finally
      {MasterBasics;}

zride91

  • Guest
Re: ACAD.lsp defining support paths in AutoCAD
« Reply #3 on: June 27, 2012, 12:47:29 PM »
Hmm...

Render Man -

So you are using differnt profiles in combination with different acad.lsp files?  I have not worked with this yet.  We were just using profiles controled by shortcuts to drive our mapping before I learned about the acad.lsp.  I thought the acad.lsp was great, and drove everything from the lisp and completely abandoned using profiles at all.  It seems as though there is a happy medium I should be using of profiles and lisps.

So to dummy things down:

You have (2) shourtcuts, one starts just AutoCAD, the other starts RasterDesign on AutoCAD, each shortcut launches AutoCAD with a unique profile.  When AutoCAD launches, the acad.lsp runs and the lisp figures which profile is active by the shortcut, from there the acad.lsp assigns the paths depending on which profile is active??  - I like it.  I have a bit more learning to do on getting to this point, but it sounds very promising.  Thank you!

dgorsman - Are you implying that when Rasterdesign is demand loaded, the paths can then be added?  Thank you!

dgorsman

  • Water Moccasin
  • Posts: 2437
Re: ACAD.lsp defining support paths in AutoCAD
« Reply #4 on: June 27, 2012, 02:11:49 PM »
Actually, that wasn't the implication.  In fact for demand-loading to work properly the paths have to exist first.

A quick background on our set-up so you have some context: we have multiple third-party software running (some of which don't cooperate very well!), some in use across all departments some just a few, and a number of different clients for each of those applications.  Each application has its own profile, and has a separate desktop shortcut.  Most of them have the paths for Raster Design, rather than having a stand-alone separate profile/"application" so the users have both the application tools and the RD tools.  Each profile has a number of common paths for basic AutoCAD functions (like RD, AutoCAD CUIx files), plus paths particular to that application, plus paths specific to a given client for blocks and custom routines.  We have something of a blend between your two methods: profiles for gross selection of settings, ARX loads, and so on; and acad.doc for ensuring the fine tuning of the various settings and mass updates.

The start-up sequence provides for a choice of client; if the user picks a different client the search paths are adjusted to include the proper client paths along with the standard application and common AutoCAD paths.  If the user starts with the same client, then the search paths were set previously and don't need to be continuously re-adjusted.  With the separate profiles its easy to check which application is running by checking the active profile name.
If you are going to fly by the seat of your pants, expect friction burns.

try {GreatPower;}
   catch (notResponsible)
      {NextTime(PlanAhead);}
   finally
      {MasterBasics;}

BlackBox

  • King Gator
  • Posts: 3770
Re: ACAD.lsp defining support paths in AutoCAD
« Reply #5 on: June 27, 2012, 02:24:29 PM »
zride91,

We do not segregate Raster Design from our core applications, such as Civil 3D. Instead, we customize our Civil 3D Profile(s) to incorporate Raster Design (and other plug-ins like AutoTurn, etc.).

So for example, each user is provided at minimum two customized application icons for their discipline, one for Civil 3D as AutoCAD (i.e., Map), and another for Civil 3D. Both of which include Raster Design be it in the Support File Search Paths, and CUIx mapping.

It is this that allows for the Raster Design functionality (Aeci*) to be demand loaded.

However, we also have separate application icons for other disciplines, where each discipline has a pair of Acad.lsp, and AcadDoc.lsp for each version, as each has an individual support structure on the network (we do account for Common files as well, which is included in the SFSP to mitigate duplication of data).

... Does this make (more?) sense?
"How we think determines what we do, and what we do determines what we get."

KewlToyZ

  • Guest
Re: ACAD.lsp defining support paths in AutoCAD
« Reply #6 on: June 27, 2012, 03:32:15 PM »
I was curious if anyone using the AEC Smart Objects uses a discipline specific template for their discipline specific profile as well? How has this worked for you?

BlackBox

  • King Gator
  • Posts: 3770
Re: ACAD.lsp defining support paths in AutoCAD
« Reply #7 on: June 27, 2012, 05:03:11 PM »

Perhaps this is due to a very long day, but I'm not sure that I understand your question. Can you elaborate?
"How we think determines what we do, and what we do determines what we get."

zride91

  • Guest
Re: ACAD.lsp defining support paths in AutoCAD
« Reply #8 on: August 21, 2012, 12:01:54 AM »
Sorry I dropped this thread, I must have missed a notification that it was updated, I didn't see any of the replies since my last post.  Since, I've been pretty busy creating all my Autodesk 2013 install deployments scripts and acad.lsp files.

I have added the Raster Design support paths to my acad.lsp, and I have decided to install Raster design on all my AutoCAD installs, this way the product is available to everyone and is demand loaded as you have both suggested.  It looks like it's working pretty well.

So now, Raster Design is set, to be installed on all my workstations, but now it's the other add-on apps tripping me up, like AutoTrack and Carlson.  The way it looks like they run is, they each have their own shortcut that is installed with the program. 

AutoTrack simply launches AutoCAD, runs a script to load the application and launch it within AutoCAD, and it also forces it's own profile, which it created during install off the default AutoCAD profile.  My problem is, when using the AutoTrack shortcut and my acad.lsp, it does not appear the shortcut command line switches work, as it does not appear the script that the shortcut launches runs.  Does the acad.lsp bypass the command line switches?  When I disable my acad.lsp, the shortcut works fine and loads the application.  Now, when I have my acad.lsp UNloaded so AutoTrack is running OK within it's own profile in AutoCAD, there are no support paths for it.  Ideally, I would just like to load the AutoTRack menus with out loading the application so it works on demand like Raster Design.  How would this be done without support paths?

I'm really kind of hesitant to go back to making multiple custom icons for all these applications because that is what I tried for the 2008 Autodesk releases when we adjusted our standards directory and had to remap all our support paths.  It did the trick, but there was a lot of confusion with users, they usually found some of the default shortcuts, but the biggest problem with custom shortcuts is 98% of my users LOVE double clicking files directly from Windows Explorer or e-mails, which of course would bypass anything that was built into the shortcut command lines.  I could do a better job of making sure all machines have the right shortcuts and ONLY the right shortcuts, but I don't know how I'd make sure people are still using them.  I just had one of my users report he couldn't open AutoCAD at all, I found out it's because he was just double clicking a file, and it was defaulted to AutoCAD 2008 still, which we do not have licensed any more...

Sorry for the length of this, it's late, I'm going a bit of crazy  :ugly: 

Thanks!