Visual LISP, AutoLISP and General Customization

Reply
Distinguished Mentor
owenwengerd
Posts: 592
Registered: ‎08-06-2002
Message 11 of 19 (168 Views)

Re: Autoloader & SFSP via Acad.lsp?

08-30-2013 09:00 AM 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
Distinguished Mentor
BlackBox_
Posts: 733
Registered: ‎02-25-2013
Message 12 of 19 (162 Views)

Re: Autoloader & SFSP via Acad.lsp?

08-30-2013 10:11 AM 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>

_$ 

 

 



"Potential has a shelf life." - Margaret Atwood


Autodesk Exchange Apps ~ Autoloader ~ AutoCAD Security

Distinguished Mentor
owenwengerd
Posts: 592
Registered: ‎08-06-2002
Message 13 of 19 (158 Views)

Re: Autoloader & SFSP via Acad.lsp?

08-30-2013 11:16 AM 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
Distinguished Mentor
BlackBox_
Posts: 733
Registered: ‎02-25-2013
Message 14 of 19 (149 Views)

Re: Autoloader & SFSP via Acad.lsp?

08-30-2013 12:39 PM 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



"Potential has a shelf life." - Margaret Atwood


Autodesk Exchange Apps ~ Autoloader ~ AutoCAD Security

Distinguished Mentor
owenwengerd
Posts: 592
Registered: ‎08-06-2002
Message 15 of 19 (144 Views)

Re: Autoloader & SFSP via Acad.lsp?

08-30-2013 01:53 PM 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
Distinguished Mentor
BlackBox_
Posts: 733
Registered: ‎02-25-2013
Message 16 of 19 (138 Views)

Re: Autoloader & SFSP via Acad.lsp?

08-30-2013 03:29 PM in reply to: owenwengerd

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



"Potential has a shelf life." - Margaret Atwood


Autodesk Exchange Apps ~ Autoloader ~ AutoCAD Security

*Expert Elite*
Lee_Mac
Posts: 1,101
Registered: ‎12-29-2009
Message 17 of 19 (126 Views)

Re: Autoloader & SFSP via Acad.lsp?

08-30-2013 04:45 PM 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.

 

Lee Mac ProgrammingTwitterExchange App StoreDropbox (500MB free)
Expert Elite
With Mathematics there is the possibility of perfect rigour, so why settle for less?
Distinguished Mentor
owenwengerd
Posts: 592
Registered: ‎08-06-2002
Message 18 of 19 (110 Views)

Re: Autoloader & SFSP via Acad.lsp?

08-30-2013 08:05 PM 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
Distinguished Mentor
BlackBox_
Posts: 733
Registered: ‎02-25-2013
Message 19 of 19 (93 Views)

Re: Autoloader & SFSP via Acad.lsp?

09-03-2013 01:25 PM 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

 

 



"Potential has a shelf life." - Margaret Atwood


Autodesk Exchange Apps ~ Autoloader ~ AutoCAD Security

You are not logged in.

Log into access your profile, ask and answer questions, share ideas and more. Haven't signed up yet? Register

Announcements
Are you familiar with the Autodesk Expert Elites? The Expert Elite program is made up of customers that help other customers by sharing knowledge and exemplifying an engaging style of collaboration. To learn more, please visit our Expert Elite website.

Need installation help?

Start with some of our most frequented solutions to get help installing your software.

Ask the Community