Visual LISP, AutoLISP and General Customization

Visual LISP, AutoLISP and General Customization

Reply
Collaborator
851 Posts
94 Kudos
45 Solutions
Post 1 of 19

Autoloader & SFSP via Acad.lsp?

417 Views, 18 Replies
08-27-2013 08:48 AM

I must be missing something, as I cannot be the only one who has noticed this, given that Autoloader has been out since AutoCAD 2012....

 

It is quite common for users to configure Support File Search Path (SFSP) at session start via Acad.lsp (as I've done for years), but doing this strips all .bundle-centric SupportPath XmlAttribute values loaded by one or more PackageContents.xml files located in any of the multiple ..\ApplicationPlugins\ folders which are implicitly trusted.

 

Autoloader (ARX, or .NET?) does the loading of an App-dependent SupportPath XmlAttribute values prior to any Acad* file in the startup sequence... Which is how a basic Acad.lsp file can overwrite these App-dependent support paths.

 

Are we (users) expected to account for this potentiality by now being responsible for parsing SFSP for any ..\ApplicationPlugins\ reference, in order to support any user-downloaded Exchange Apps, and/or internal Autoloader Apps?

 

Another option would be to invoke:

 

(command "appautoloader" "_reload")

 ... Once done configuring SFSP, but still, this shouldn't be required (I feel).

 

Why doesn't Autoloader already handle this in the code-behind? 

 

Cheers

 

 

 

 



"Potential has a shelf life." - Margaret Atwood


Autodesk Exchange Apps ~ Autoloader ~ AutoCAD Security


AutoCAD®, and Civil 3D® Certified Professional ~ Autodesk® Authorized Developer

AUTODESK EXPERT ELITE
1328 Posts
344 Kudos
182 Solutions
Post 2 of 19

Re: Autoloader & SFSP via Acad.lsp?

08-27-2013 09:00 AM in reply to: BlackBox_

BlackBox_ wrote:

It is quite common for users to configure Support File Search Path (SFSP) at session start via Acad.lsp (as I've done for years), but doing this strips all .bundle-centric SupportPath XmlAttribute values loaded by one or more PackageContents.xml files located in any of the multiple ..\ApplicationPlugins\ folders which are implicitly trusted.


 

Does this still occur if you append the acad.lsp-configured SFSP to the existing list of paths (rather than perhaps replacing the existing paths), and if not, is this not a viable option?

Lee Mac ProgrammingTwitterExchange App StoreDropbox (500MB free)
Expert Elite
With Mathematics there is the possibility of perfect rigour, so why settle for less?
Collaborator
851 Posts
94 Kudos
45 Solutions
Post 3 of 19

Re: Autoloader & SFSP via Acad.lsp?

08-27-2013 09:20 AM in reply to: Lee_Mac

Historically, SFSP is loaded by a call to SupportPath Property in order to overwrite any supplementary paths, as part of implementing standards, based upon either client-specific, or internal standards that apply to that particular session.

 

This makes it simple to add/update a path, and for users to simply reload, and carry on with their work... This rather than re-importing .ARG, etc.

 

Appending is not satisfactory, which is where the suggestion that the existing common practice be ammended to instead parse for any ..\ApplicationPlugins\ reference, and potentially replace any/all others in effect.

 

If I had an Exchange App which is dependent on my specified SupportPath XmlAttribute to function properly, I'd be less than pleased that this scenario was not somehow 'mitigated' in order to allow users to do what they like, without directly breaking my Exchange App.

 

Same applies to an internal app, with the added benefit of having access to the person(s) who configure our setup, or put out our internal Autoloader App(s)... But the issue still exists, and is seemingly unaccounted for by Autodesk.

 

Again, this if I am not missing something... I'd gladly be corrected here, but this stems from several observations from both the user, and developer perspective, and I'd hope it to be addressed for both parties benefit.

 

Cheers



"Potential has a shelf life." - Margaret Atwood


Autodesk Exchange Apps ~ Autoloader ~ AutoCAD Security


AutoCAD®, and Civil 3D® Certified Professional ~ Autodesk® Authorized Developer

Advisor
807 Posts
117 Kudos
93 Solutions
Post 4 of 19

Re: Autoloader & SFSP via Acad.lsp?

08-29-2013 10:25 AM in reply to: BlackBox_

I think most applications append to the SFSP rather than overwrite. I'm not sure I understand entirely what is happening in the case of autoloader bundles, but your scenario demonstrates yet again why applications should never modify or depend on the SFSP.

--
Owen Wengerd
ManuSoft
Collaborator
851 Posts
94 Kudos
45 Solutions
Post 5 of 19

Re: Autoloader & SFSP via Acad.lsp?

08-29-2013 11:18 AM in reply to: owenwengerd

Hi Owen,

 

I couldn't find anything on this topic, and given that Autoloader has been out since AutoCAD 2012, I thought I'd seek others' thoughts on the topic.

 

In an effort to try and clarify... The setup we've been using at work for years, is to employ our Acad.lsp to set SFSP at session start. 

 

Autoloader inherently appends to SFSP, if any SupportPath XmlAttributes are found when iterating any PackageContents.xml files (obviously from .bundles).

 

 

 

The issue being observed, is due to the startup sequence... where Acad.lsp is being loaded and modifying our SFSP after Autoloader's native code is executed appending the app-dependent SupportPath XmlAttributes (effectively stripping them from SFSP).

 

As a CAD user/admin, in order to maintain our existing methodology, this leaves me to first extract any ..\ApplicationPlugins\ reference from a parsed SFSP string, from (getenv "ACAD") as an example, and then append them (the app-dependent paths) to the paths we need for our setup, and only then can I write them.

 

We use a separate Acad.lsp file to maintain each internal, and client-specifc profile, for each version, which allows both profile-specific, and version-specific changes to happen on the fly, by simply reloading Acad.lsp via an implemented Menu, Toolbar Button, RibbonButton, or Shortcut MenuItem, removing the need for re-importing a given profile.

 

Obviously this methodology of setting SFSP via Acad.lsp has been around since before my time as a CAD user, and isn't going away anytime soon... The point I am attempting to make is that Autoloader is relatively autonomous in other ways, such as the loading/unloading of partial CUIx files, etc., and I feel this is one area where it should be as well.

 

While app .bundle's will be developed internally for various employers, the Autoloader mechanism was primarily developed to allow the ease of use for 3rd party apps, for which the end-user has presumably no knowledge of the innerworkings of each-and-every-single app they simply download, install, and consume.

 

Autoloader appropriately adds the paths, presumably at Initialize(), and removes them, again presumably at Terminate() as they are not found in HKEY_CURRENT_USER\Software\Autodesk\AutoCAD\<YourVersion>\Profiles\<YourProfileName>\General\ACAD after a session is closed... So methinks Autoloader should also preserve the app-dependent SupportPath(s) during said session by way of a simple event handler... Until a given app is unloaded (if the app allows such functionality, etc.).

 

As a user, this is creating more work for me to prepair, and maintain our setup. As an Exchange app developer this presents an opportunity for my apps to be broken (albeit if unintentionally) by what in my limited experience is a very common practice (setting SFSP via Acad.lsp)... Then who is responsible for fixing my app (say a given user only has one installed, so that they do not recognize the larger issue)? 

 

Hope this makes (more?) sense... I'd be very interested in others thoughts/experience with Autoloader enabled versions.

 

Cheers



"Potential has a shelf life." - Margaret Atwood


Autodesk Exchange Apps ~ Autoloader ~ AutoCAD Security


AutoCAD®, and Civil 3D® Certified Professional ~ Autodesk® Authorized Developer

AUTODESK EXPERT ELITE
1328 Posts
344 Kudos
182 Solutions
Post 6 of 19

Re: Autoloader & SFSP via Acad.lsp?

08-29-2013 11:33 AM in reply to: BlackBox_

A couple of notes on your post:

 

  • Surely the SFSPs added through the acad.lsp only need be added once per machine, hence this issue should only arise the very first time they are added?
  • If, as you state, the Autoloader module is modifying the SFSP before the acad.lsp is loaded, I don't see why your code should strip the .bundle support paths if you are appending to the list of existing paths?

Sorry if I am missing something Smiley Sad

 

EDIT: Why do bullet points show up in the post editor but not in the actual post?!

Lee Mac ProgrammingTwitterExchange App StoreDropbox (500MB free)
Expert Elite
With Mathematics there is the possibility of perfect rigour, so why settle for less?
Collaborator
851 Posts
94 Kudos
45 Solutions
Post 7 of 19

Re: Autoloader & SFSP via Acad.lsp?

08-29-2013 12:03 PM in reply to: Lee_Mac

Lee_Mac wrote:

A couple of notes on your post:

 

  • Surely the SFSPs added through the acad.lsp only need be added once per machine, hence this issue should only arise the very first time they are added?
  • If, as you state, the Autoloader module is modifying the SFSP before the acad.lsp is loaded, I don't see why your code should strip the .bundle support paths if you are appending to the list of existing paths?

Sorry if I am missing something Smiley Sad

 

EDIT: Why do bullet points show up in the post editor but not in the actual post?!


Agreed on the bullet points, they show in reply quotes as well. LoL

 

In any event, Acad.lsp is loaded once per session typically, as we use AcadLspAsDoc == 0, but can at any given moment depending on any of our client's fancy, need to add paths which happens far more often than I'd care for. It happened often enough, that we implemented a system where we could update SFSP mid-session as described.

 

Again, we're not appending paths... We're overwritting them to dually maintain consistency to a particular standard (of which we have several different standards, again at the client's fancy), and to make updating them simple while working.

 

Given that Autodesk has implemented a mechanism whereby any end-user can (pruchase?, ) download, and employ an Autoloader app .bundle which entirely bypasses any internal, and/or built-in Security (if using 2013 SP1-2014), each user in an organization can have an entirely different app library. Any apps with dependent SupportPath(s) being appended at Initialize() are overwritten.

 

It's simple enough to perform the additional task of extracting and adding them to the list of our own paths, but I shouldn't have to do this (I feel), the end-user shouldn't deal with broken apps, and the app developer should receive potential complaints from consumers for Autodesk's failure to maintain Autoloader added paths.

 

I don't have any Exchange apps that include SupportPath XmlAttributes, but still... I may in the future, and others I know do, so I can see this happeneing, and the developer could receive some customer calls for support.

 

I feel that this can be mitigated for all perspectives, and hope that it is (in the near future).

 

Again, I hope this makes (more?) sense.



"Potential has a shelf life." - Margaret Atwood


Autodesk Exchange Apps ~ Autoloader ~ AutoCAD Security


AutoCAD®, and Civil 3D® Certified Professional ~ Autodesk® Authorized Developer

AUTODESK EXPERT ELITE
1328 Posts
344 Kudos
182 Solutions
Post 8 of 19

Re: Autoloader & SFSP via Acad.lsp?

08-29-2013 02:36 PM in reply to: BlackBox_

BlackBox_ wrote:

Again, we're not appending paths... We're overwritting them.


 ^^ This is the point I was missing.

 

Given this information, some thoughts come to mind:

 

I see no way to retain the .bundle support paths whilst overwriting the existing support paths, unless you can somehow exploit an event occurring before the Autoloader initiates in the AutoCAD startup procedure. If this is possible, you could quite easily store a list of support paths present before the Autoloader has potentially appended new paths, and remove only those paths present in this stored list when adding your standard paths, hence retaining any .bundle paths added.

 

A possible alternative might be to rely on the .bundle support paths using some standard path format that you could test for and retain whilst appending your company standard paths - though, I'm unsure whether or not the .bundle support paths follow any such standard or can be an arbitrary path.

 

The only other alternative that I can suggest would be to test for the existence of your company standard paths in the list of support paths, and append only those which are necessary. This would then ensure that all users included your standard support paths whilst retaining .bundle paths, though with the drawback that any additional paths added by the user are also retained - violating the standard.

Lee Mac ProgrammingTwitterExchange App StoreDropbox (500MB free)
Expert Elite
With Mathematics there is the possibility of perfect rigour, so why settle for less?
Advisor
807 Posts
117 Kudos
93 Solutions
Post 9 of 19

Re: Autoloader & SFSP via Acad.lsp?

08-29-2013 07:16 PM in reply to: BlackBox_

This is the first time I've ever heard of overwriting the SFSP, so I don't think it's common at all. In fact, I think it's extremely rare -- and for good reason. It sounds to me like you're forcing a square block through a round hole, then insisting that Autodesk should make the hole square so you don't have to push as hard.

--
Owen Wengerd
ManuSoft
Collaborator
851 Posts
94 Kudos
45 Solutions
Post 10 of 19

Re: Autoloader & SFSP via Acad.lsp?

08-30-2013 07:33 AM in reply to: owenwengerd

That's is an interesting assessment, Owen... I must say. LoL

 

I find it of interest, as I am not the author of the vla-Put-SupportPath LispFunction Method, nor did I implement the "ACAD" Environment Variable (i.e., [setenv "ACAD"...]) (the square peg)... I'm simply using the tools Autodesk provided, and successfully so prior to Autoloader.

 

Even that isn't fully correct, as what I'm doing is successful, exactly as it was designed to function, it's just that with the introduction of Autoloader there's a byproduct unaccounted for, which I've attempted to discuss here.

 

What we're doing may not be the best option in your estimation, and that's perfectly fine, but it's been in place for years, and isn't going away (slow moving ship and all that).

 

... So since Autodesk implemented both the ability to set/put the SupportPath, and Autodesk implemented the mechanism that isn't accounting for changes to this even though it's partially maintaining this property (it's only adding them at Initialize(), and removing them at Terminate(), etc.), methinks it pretty simple to suggest that they also account for during the session for apps they're paying developers to create for their software.

 

 

 

Since this is a first for you, the oldest usage of setting SFSP I've found (in a very quick search) is Tony Tanzillo in 1999 here (I was still in High School)

 

https://groups.google.com/forum/#!topic/autodesk.autocad.customization/3x--M4W9JEY

 

 

... And R.K. back in 2007 (whom I originally learned this methodology from in early 2010), among others - 

 

http://cadpanacea.com/node/52

 

http://rkmcswain.blogspot.ca/2007/02/setting-support-paths-via-lisp.html

 

http://www.afralisp.net/visual-lisp/tutorials/beginning-visual-lisp-part-2.php

 

http://forums.autodesk.com/t5/Visual-LISP-AutoLISP-and-General/Support-Path-Placement/td-p/813632

 

http://forums.augi.com/showthread.php?150628-Script-file-to-Auto-cad-support-paths&p=1235669&viewful...

 

http://forums.augi.com/showthread.php?149678-Programmatically-Assigning-Support-File-Search-Paths&p=...

 

http://www.cadtutor.net/forum/showthread.php?69519-Adding-Folders-to-Support-File-Search-Path&p=4758...

 

 

 

Cheers

 

 

 



"Potential has a shelf life." - Margaret Atwood


Autodesk Exchange Apps ~ Autoloader ~ AutoCAD Security


AutoCAD®, and Civil 3D® Certified Professional ~ Autodesk® Authorized Developer

Post to the Community

Have questions about Autodesk products? Ask the community.

New Post