Visual LISP, AutoLISP and General Customization
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Autoloader & SFSP via Acad.lsp?

18 REPLIES 18
Reply
Message 1 of 19
BlackBox_
986 Views, 18 Replies

Autoloader & SFSP via Acad.lsp?

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

 

 

 

 



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

18 REPLIES 18
Message 2 of 19
Lee_Mac
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?

Message 3 of 19
BlackBox_
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



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

Message 4 of 19
owenwengerd
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
Message 5 of 19
BlackBox_
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



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

Message 6 of 19
Lee_Mac
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?!

Message 7 of 19
BlackBox_
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.



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

Message 8 of 19
Lee_Mac
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.

Message 9 of 19
owenwengerd
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
Message 10 of 19
BlackBox_
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

 

 

 



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

Message 11 of 19
owenwengerd
in reply to: BlackBox_

BB, I looked at two of your links and so no mention in either of overwriting the SFSP, so I didn't waste any time with the rest. Perhaps you imagined or assumed that the (vla-Put-SupportPath) code was intended for replacing instead of appending? In any case, I stand by my assertion.

--
Owen Wengerd
ManuSoft
Message 12 of 19
BlackBox_
in reply to: owenwengerd


@owenwengerd wrote:

BB, I looked at two of your links and so no mention in either of overwriting the SFSP, so I didn't waste any time with the rest. Perhaps you imagined or assumed that the (vla-Put-SupportPath) code was intended for replacing instead of appending? In any case, I stand by my assertion.


Thank youf or your time, and consideration, Owen... It's unfortunate that you required someone to state the word 'overwrite' explicitly rather than observing the nature of the vla-Put-SupportPath call, but that changes nothing of how the built-in LispFunction works.

 

Perhaps it is I using incorrect, or at least unfamiliar terminology here, when I say 'overwrite'?

 

As you well know, if an Object's property has an initial value, and you were to set/put a new valid value, the initial value is not preserved (the new value overwrites it), unless stored to another property/variable/field first, nor is the new value appended to the initial value during this procedure.

 

In any event, the net result of 'appending', or 'overwritting' SFSP (an Object Property) is a simple matter of symantics, really... More specifically, with each call to the vla-Put-SupportPath LispFunction (presuming a valid string argument) the current value of SFSP _is_ overwritten, even when the supplied string argument is a concatenation of the current SFSP string value (i.e., vla-Get-SupportPath, etc.), and any additional path(s).

 

Cheers

 

_$ (setq oFiles (vla-get-files (vla-get-preferences (vlax-get-acad-object))))
#<VLA-OBJECT IAcadPreferencesFiles 000000003d668ec0>

_$ (setq sfsp (vla-get-supportpath oFiles))
<InitialSupportFileSearchPathString>

_$ (vla-put-supportpath oFiles "C:\\users\\BlackBox\\")
nil

_$ (vla-get-supportpath oFiles)
"C:\\users\\BlackBox\\"

_$ (vla-put-supportpath oFiles sfsp)
nil

_$ (vla-get-supportpath oFiles)
<InitialSupportFileSearchPathString>

_$ 

 

 



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

Message 13 of 19
owenwengerd
in reply to: BlackBox_

I used "overwrite" the same way you used it, i.e. to express that you are not preserving the original SFSP, which is what you have stated and even explicitly clarified in this thread. But let's change the terminology to be more clear. You asserted that it is "common" to not preserve the original SFSP when calling the (vla-Put-SupportPath) function. If you want to convince us of that, it's not enough to prove that other people use the same function you do: you must prove that other people use it to ignore and discard the original SFSP and replace it with a new SFSP.

--
Owen Wengerd
ManuSoft
Message 14 of 19
BlackBox_
in reply to: owenwengerd

Thank you for the confirmation, Owen.

 

I am uninterested in convincing you, nor anyone else that this is common (even if I could do so).

 

If the inference given my limited experience (and it is limited) is mistaken to you, or even to the community as a whole (to make this more centered on truth), that's perfectly fine... Consider your argument that this is not common, dually noted.

 

 

 

Perhaps, and I may still be missing the mark here, a more valid phrasing might be that 'it is possible to break SFSP dependent Autoloader app functionality with a simple call to vla-Put-SupportPath'

 

Given both my interest to avoid this as a user, and as an app developer, I feel that a simple event handler could be implemented as part of the otherwise autonomous Autoloader mechanism, in order to account for, and ultimately mitigate this potentiality.

 

Cheers



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

Message 15 of 19
owenwengerd
in reply to: BlackBox_

Let's recap. You're doing something dangerous ("but it has always worked fine in the past" does not mitigate this fact) and probably avoidable, and it's causing problems. You think there's a simple solution, but Autodesk has to implement part of the solution for you. Fair enough, but let's be clear that as far as we know, your organization is the only one that would benefit.

--
Owen Wengerd
ManuSoft
Message 16 of 19
BlackBox_
in reply to: owenwengerd

... Enlighten me as to the safe usage of vla-Put-SupportPath, Owen?



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

Message 17 of 19
Lee_Mac
in reply to: BlackBox_


@BlackBox_ wrote:

... Enlighten me as to the safe usage of vla-Put-SupportPath, Owen?


Here is a simple example of what I believe Owen is referring to:

 

(defun addpaths ( paths / existing prefiles )
    (setq prefiles (vla-get-files (vla-get-preferences (vlax-get-acad-object)))
          existing (vla-get-supportpath prefiles)
    )
    (if
        (setq paths
            (vl-remove-if
               '(lambda ( path )
                    (or (vl-string-search (strcase path) (strcase existing))
                        (not (findfile path))
                    )
                )
                paths
            )
        )
        (vla-put-supportpath prefiles
            (strcat (vl-string-right-trim ";" existing) ";"
                (apply 'strcat (mapcar '(lambda ( path ) (strcat path ";")) paths))
            )
        )
    )
)

Usage

(addpaths '("C:\\Path1" "C:\\Path2" "C:\\Path3"))

The above will add a set of supplied support paths by modifying the ActiveX supportpath property, whilst preserving all existing paths (and hence any .bundle paths)

 

Alternatively, here are some more examples manipulating the ACAD environment string.

 

Each of these examples is following the method I described in the final paragraph of Message #8.

 

I hope this clarifies the matters discussed.

 

Message 18 of 19
owenwengerd
in reply to: BlackBox_


@BlackBox_ wrote:

... Enlighten me as to the safe usage of vla-Put-SupportPath, Owen?


In short, don't remove any directories from the SFSP that you didn't put there. As Lee has explained, appending or prepending directories is the safe way of making changes. In my opinion, third party applications should almost never modify the SFSP in any case, as it's rarely necessary.

 

To your larger problem, I don't quite understand all your requirements, but I wonder why you're not just switching profiles to accomplish your goals.

--
Owen Wengerd
ManuSoft
Message 19 of 19
BlackBox_
in reply to: owenwengerd


@owenwengerd wrote:

@BlackBox_ wrote:

... Enlighten me as to the safe usage of vla-Put-SupportPath, Owen?


In short, don't remove any directories from the SFSP that you didn't put there. As Lee has explained, appending or prepending directories is the safe way of making changes. In my opinion, third party applications should almost never modify the SFSP in any case, as it's rarely necessary.

 

To your larger problem, I don't quite understand all your requirements, but I wonder why you're not just switching profiles to accomplish your goals.


Owen, might I ask that we backup for a moment, please... There are two entirely separate perspectives here, and perhaps I've done a poor job of making that clear.

 

 

 

I'm a CAD user, responsible for daily production, and one of my responsabilities (given that I double as a CAD Admin when needed), is to test, implement, and maintain our multiple product deployments for each version 2009-2012, and 2014 (soon)... Only in my personal time, on my personal computer (where I have ADN license products installed), do I develop app(s) such as the one I currently have live at Autodesk Exchange.

 

As a user, no path is ever added to SFSP which I do not personally have write permission (as I created the folder[s] on the network myself), or those which are consistently available on each user's computer per our installation image.

 

 

 

Due to my work as a user (whilst testing a change in our SFSP per admin task in Civil 3D 2012), I observed for the first time, a single situation which may, or may not affect other users secondarily to Autoloader's primary, in which this internal, specific task practiced here for our production deployments may preclude the proper usage of any 3rd party app(s) which Autoloader has previously, correctly appended the app-defined SupportPath XmlAttributes strings.

 

Earlier in this thread I made sure to identify two separate methods for either mitigating this issue (to first parse the existing paths, extracting any ..\ApplicationsPlugins\ reference, and merge with one's own paths prior to set/put), or to instead simply set/put one's own paths and immediately follow with a call to:

 

(command "._appautoloader" "_reload")

 

... Which properly reloads any product/version-applicable Autoloader app, both of which allow for the proper usage of any Autoloader apps a given user might have. Only after that, did I identify the opportunity for a simple event handler be implemented within the Autoloader mechanism which precludes the need for the user to mitigate this on their end.

 

Given the word selection of your latest post, I'm starting to suspect you think I was encountering an issue modifying SFSP via Exchange app (which is not the case), rather than as an internal best practice which I personally maintain, and is something put into place before I was even employed here. 

 

So there can be no confusion... I am not now, nor have I ever suggested modifying the SFSP via any 3rd party app which the user does not personally control (save something such as SFSP+), as I firmly believe SFSP is entirely the user/admin's responsability. Any possible modification to SFSP would be relegated to the use of PackageContents.xml per Exchange Apps criteria.

 

What I was trying to point out, as I also have the previledge of beign a developer (when free time permits), is that from the developer's perspective, if one's Exchange app depended on any .bundle relative folder(s) for resources that were accidentally lost due to such a unique cricumstance as noted above (without properly accounting for those paths added via Autoloader at session start), an app developer may be quite displeased if their customers (users) thought that the improper function of said app was the fault of the app developer (which it is obvioulsy not, given that a user could make such a change to SFSP, and not even be aware of the innerworkings of Autoloader, etc.).

 

I'm (perhaps poorly) attempting to identify a potential problem that exists only in Autoloader enabled product versions, offer two solutions to those who may encounter such from the user's perspective, and attempted to offer a single, thoughtful solution which if incorporated into the Autoloader mechanism would mitigate the lot (and make Autoloader a better, more dependable utility, IMO).

 

The latter is not necessary, as either of the former well resolve any such potential issue.

 

 

 

I sincerely hope that this makes (more?) sense to you now, my friend.

 

Cheers

 

 



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

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

Post to forums  

Autodesk Design & Make Report

”Boost