Making a Macro User Specific

[ryled]

Currently I have a menu written with a bunch of macros into it.  A lot of these macros are calling a path to a specific block location.  This works fine for just my computer however if I want to use it on a difference computer the path name changes because of a different username.

Is there any way I can have the username part of the path be relative to the specific user with a macro?  Or a way to start the load path at "documents" since that is pretty consistent amongst Windows computers?

Thank you

[Lee_Mac]

You could reference the LOGINNAME system variable.

In LISP:

(getvar 'loginname)

In DIESEL:

$(getvar,loginname)

[ryled]

Sorry, I have no clue how to do that, I am unsure what diesel is.  Would I put this at the beginning of my menu?

[Lee_Mac]

No, the above expressions return the user's username, for you to use in your paths to make them user-specific.

[ryled]

Lee_Mac,

Would I do this within my menu file.  And if so where/would it work being a .mnu and not a .lsp. 

Would I do something like:

(getvar 'loginname)
***POP16
[MENU TITLE]
[INSERT]^C^C^C-INSERT;"C:/users/'loginname/Documents...."

[dmfrazier · Accepted solution]

This code would store the Windows login name as a variable named "user":

(setq user (getvar 'loginname))

You could then modify your menu macro to run everything inside LISP, like this (untested):

^C^C^C(setq user (getvar 'loginname)) (command "-INSERT" (strcat "C:/users/" user "/Documents....")...);you would need to complete the responses to the INSERT command where I placed "..."

There are, of course, many other ways to do this...

In your original post, you asked:

"Is there any way I can have the username part of the path be relative to the specific user with a macro?  Or a way to start the load path at "documents" since that is pretty consistent amongst Windows computers?"

If the block name is going to be consistent among users, you could leave out the path from the macro (reference the filename only) and have each user add his own unique path to his own Support Files Search path (part of his unique profile) so that AutoCAD will search for and find it there.

^C^C^C-INSERT;"thisfilename"...

[ryled]

So you could have multiple lisp routines within a .mnu file?  And also in this lisp there are spaces before and after 'user' in the lisp routine (" user ")?

I was under the impression lisps had to be their own file but I am new to them so I'm probably wrong. 

Also someone had mentioned to me about using %username% but I am not sure if that would work either?

I probably would want to avoid option two because not all of the users here are AutoCAD trained, they just do small drawings to get ideas of how they will build things and would like the use of some of the blocks to make it easier.

Thank you

[dmfrazier]

"So you could have multiple lisp routines within a .mnu file?"

If you're dealing with MNU, then I have to assume you are using a version of AutoCAD that is older than the CUI. (Correct?)

Or are you using MNU to mean CUI?  (Please clarify.)

I'm not sure why you're asking about "multiple LISP routines".

In either case, it sounds like you are trying to get one menu macro (within a MNU or CUI file)that will work for several different users. (They would all click on the same menu item, but based on the value of their "user" variable, it would do something slightly different for each user.

"And also in this lisp there are spaces before and after 'user' in the lisp routine (" user ")?"

The code uses a string concatenation function that takes several arguments and puts them all together.  Each argument is a string enclosed in quotes, with a space separating them.  "User" (the variable) does not get quotes because it is a variable (defined earlier).  When AutoLISP resolves this variable, the quotes are part of it. This concatenated string then becomes the argument for the INSERT command.  (For more on this stuff, look for books or other resources on how to write AutoLISP programs.)

You can test all this at the AutoCAD command line:

On your machine, this code: (setq user (getvar 'loginname)) should return (echo back to you) your Windows login Id enclosed in quotes.

If you then type !user on the command line (followed by Enter), you will get that same response.  This tells you that the variable "user" is currently set to a value that equals your Windows login Id.

Once that is done, this code: (strcat "C:/users/" user "/Documents....") will string together those pieces, but AutoLISP will first replace (evaluate or resolve) the "user" variable with its current value, so you should end up with a path that includes your Windows login Id.  A different user will get a path with his Id in place of yours.

(Note that you will have to correct and complete this path and verify that it exists for this to work.)

"I was under the impression lisps had to be their own file but I am new to them so I'm probably wrong."

They can be, but thay don't have to be.  There's no reason that one cannot use LISP on the command line (which you now know first-hand) or in a menu macro (or in a number of other different places and ways).

"Also someone had mentioned to me about using %username% but I am not sure if that would work either?"

That syntax does work in certain contexts, but not within AutoLISP, AFAIK.

I probably would want to avoid option two because not all of the users here are AutoCAD trained, they just do small drawings to get ideas of how they will build things and would like the use of some of the blocks to make it easier.

I assume you are referring to having the user add his own unique path to his own Support Files Search path.  This isn't necessarily something you would actually have them do (regardless of their AutoCAD knowledge).  This can easily be done for them.

[ryled]

dmfrazier,

Thanks for the help!

By using a .mnu file, what I am creating is a basic text document, saving it as 'doc.mnu' and then using menuload to load it into the menu bar.  However I do see that this also creates a 'doc.cui' file which it uses the menu section from to apply it to a workspace.  So when I said multiple lisp routines in a .mnu file I was referring to the .mnu file I would create to load.  I also have had issues in the past running commands after running a lisp within the same macro. 

(You gave me a hand with this as well, however I resorted to include the rest of the command in a lisp thanks to help)

http://forums.autodesk.com/t5/Visual-LISP-AutoLISP-and-General/Adding-a-command-after-a-lisp-in-a-ma...

"In either case, it sounds like you are trying to get one menu macro (within a MNU or CUI file)that will work for several different users. (They would all click on the same menu item, but based on the value of their "user" variable, it would do something slightly different for each user."

This is close, the user would click the menu item and it would pull the same block from their C drive.  This is being done to allow mobility within the company's AutoCAD system I am 'attempting' to put together.  I also have an enterprise file, this menu would be more of a backup. 

(If you would like a little more information I have detailed it in this thread)

http://forums.autodesk.com/t5/CAD-Managers/Attempting-to-become-a-CAD-Manager/td-p/5127206/page/2

To build on that, I am currently building a main 'custom' CUI each computer will get a copy of.  In this main CUI I could add the support path to the same folder I will be putting on each computer, however I believe I would still have the same problem, as this would path to my computer as I am setting up the support path on here, correct?  Then this path wouldn't work on the other computers.

I would prefer to go with the first option however is it possible to:

Add before starting the menu

(setq user(getvar 'loginname))
***POP16
[Menu Title]
[Command]^C^C^C-insert;"C:/users/"!user"/Documents..."

or

Add (setq user(getvar ' logginname)) to the startup lisp and then run

[Command]^C^C^C-insert;"C:/users/"!user"/Documents..."

or does this type of concatenation not work within a macro?

Once again thanks for all your help.

[dmfrazier · Accepted solution]

"This is close, the user would click the menu item and it would pull the same block from their C drive."

This is exactly what I meant by "slightly different".

"...I am currently building a main 'custom' CUI each computer will get a copy of.  In this main CUI I could add the support path to the same folder I will be putting on each computer, however I believe I would still have the same problem, as this would path to my computer as I am setting up the support path on here, correct?  Then this path wouldn't work on the other computers."

I think the best way to proceed with this (if I understand correctly) is to do what I suggested earlier and you referred to as "option2": add each user's block path (or paths, if appropriate) to each user's Support File Search path.

(Another thing to investigate, which can get a little more complicated and potentially confusing, is to rely on AutoCAD/Windows' ability to "reinterpret" a path that includes the "roamable root prefix".  You can add a path to your Support Files Search path that includes your user Id.  If you then export your profile, which includes that path, and then import that profile on a different user's machine, the user Id portion of that path will adjust to the current user.) 

"I would prefer to go with the first option however is it possible to:

Add before starting the menu...

(setq user(getvar 'loginname))
***POP16
[Menu Title]
[Command]^C^C^C-insert;"C:/users/"!user"/Documents..."

No, the setq LISP code has to be part of the menu macro, so that line of code has to go after the ^Cs and before the insert command.

Also, I don't think the "!user" inserted into the path is going to work.  You have to use LISP to incorporate the variable into the path.  (See the code as I wrote it in my previous response.)

"...or Add (setq user(getvar ' logginname)) to the startup lisp and then run

[Command]^C^C^C-insert;"C:/users/"!user"/Documents..." 

or does this type of concatenation not work within a macro?"

As long as the concatenation is done in LISP code, it can be used in a macro.  (I don't know of a way to do the equivalent in menu macro syntax.)

This macro should work just fine:

^C^C^C(setq user (getvar 'loginname)) (command "-INSERT" (strcat "C:/users/" user "/Documents....")...)

You just have to finish out the INSERT command with all the input it requires beyond the filename to insert (insert point, scale, etc.).  When you run an AutoCAD command within AutoLISP using the "command" function, you just follow the command name with all the prompts and input (enclosed in quotes and separated by spaces) that the command would normally receive when it's run on the command line.  If you want the user to supply a response to any of the prompts, use PAUSE (no quotes), as described here:

http://docs.autodesk.com/ACD/2013/ENU/files/GUID-93E25253-F42A-4E85-84AD-4DCA66DB48A6.htm

Another thing I would strongly suggest is to wean yourself off your reliance on the MNU file as a way of editing menu macros and other customizations.  Once these changes are either converted or incorporated into a CUI, I think you will find that maintaining your menus and other interface elements is much easier using the CUI editor (CUI command).  CUI/CUIX files can be shared just like MNU files.  Elements can easily be copied between CUI files via the Transfer tab of the CUI editor.

[ryled]

dmfrazier,

I like the idea of adding the support file paths because it will let me stick with using macros that don't incorporate lisps since I am not completely fluent with them for troubleshooting purposes. 

I just have a couple more questions if you wouldn't mind.

I believe I added the support paths correctly?  In the green box you can see that I added a couple, I'd would have to add about 15 more, and to keep it simplistic I was curious if I was to stop the path at the purple underline (as you can see it is consistent up to that point) if AutoCAD would search through the multiple subfolders for the blocks and Mslides I was looking to reference? 

And exporting this profile and uploading on a separate computer will change the "dryle" part of the path to the appropriate user or not?

"I think the best way to proceed with this (if I understand correctly) is to do what I suggested earlier and you referred to as "option2": add each user's block path (or paths, if appropriate) to each user's Support File Search path.

(Another thing to investigate, which can get a little more complicated and potentially confusing, is to rely on AutoCAD/Windows' ability to "reinterpret" a path that includes the "roamable root prefix".  You can add a path to your Support Files Search path that includes your user Id.  If you then export your profile, which includes that path, and then import that profile on a different user's machine, the user Id portion of that path will adjust to the current user.) "

These two statements had me confused if it would or not.

Since the folder structure and objects on each computer are the same this would be a feasible thing to do since I would only have to path once, and can make updates to the master CUI/Profile to update the stations.

Thanks again!

[dmfrazier]

It looks like you're on your way.

"I was curious if I was to stop the path at the purple underline (as you can see it is consistent up to that point) if AutoCAD would search through the multiple subfolders for the blocks and Mslides I was looking to reference?"

I don't think so.  This is something you can easily test in your own environment.

"These two statements had me confused if it would or not."

Sorry for confusing you.  (My attention has been a little "divided" lately, so I don't always have time to validate some of my suggestions before making them.)

I think (based on my own experience) what you have described (with the full paths) will work, but I'm not 100% certain, so you will have to test it.  In my case, it works with custom subfolders that have been created beneath the default roaming user "support" folder for Acad2013:

(C:\Users\<username>\AppData\Roaming\Autodesk\AutoCAD 2013 - English\R19.0\enu\Support\)

So, I think it will work for you.

When you export a profile (as an ARG file), AutoCAD replaces most of its recognizable paths with "placeholders" (or replaceable parameters), such as "%roamablerootfolder%", so that the profile can be imported on other users' machines and those folder names will automatically adjust.  You can see this by opening an ARG file (which is just a REGEDIT file) in Notepad.

[ryled]

dmfrazier,

Thank you for your help.  I wound up making a support path to each individual location for assurance since the username will change according to station. 

I did test doing a 'dummy' folder and putting a block inside, then writing a macro "^C^C^C-INSERT;"Block Name";..." and the support path was to the 'dummy folder'.  This worked, so I made a new folder inside of that and moved the block into it and it worked again, and I repeated and it worked once again.  I am not sure if this is because the block was already defined from the first time I inserted it or if it pathed each time, and I don't have the time to try a bunch of experiments with it haha.

I do know the support path has worked great fro me so thank you for your help!

[dgorsman]

tl/dr

The back-and-forth on this should be a good clue: move away from paths that depend on changing folder names ie. user names.  Keeping as much as possible the same reduces the amount of management required and maximizes the ability to re-use automation.

[dmfrazier]

I am not sure if this is because the block was already defined from the first time I inserted it or if it pathed each time, and I don't have the time to try a bunch of experiments with it haha."

If you did not either ERASE and PURGE the block between tests or run your subsequent tests in a new DWG that you know did not already have an insert or a definition of the block, then it was definitely using the existing block definition.  That's how INSERT works: if you don't explicitly specify a path to a file, AutoCAD looks first for a definition within the DWG, then it starts looking "beyond".  (This is an important "fact of AutoCAD" to understand, particularly if you plan on being an effective CAD manager.)

In addition to dgorsman's advice, I would add two more things to put on your "wish list":

1. Use a shared network folder to store and access common resources such as block DWGs, etc.

2. Learn about Tool Palettes as an alternative to menus. 

"I do know the support path has worked great fro me so thank you for your help!"

You're very welcome.

Edit: Here's a fun thread to read thru (in your spare time, right?), if you haven't already:

http://forums.autodesk.com/t5/Visual-LISP-AutoLISP-and-General/AutoLisp-beginners-exercises/m-p/4372...

It'll either inspire you or scare the hell out of you - a good thing either way. "

[ryled]

dgorsman and dmfrazier,

Thanks for the advice.  This 'local' menu with all the macros is meant to serve as a backup incase of a network failure or working away from the office. 

I have been able to set up a working Enterprise CUI with all paths to blocks,lisps, slides, templates etc.  on the network drive.  This will be the thing used 99% of the time, I just wanted all the basis covered so I felt like this was necessary.

I will have to look into pallettes, I did offer that as an idea but the ribbon was preferred here so I have set it up that way.

And I will read through that AutoLisp forum, I have it favorited now. I have multiple printouts to go through and am enrolled in one programming class with two more on the way so I can understand how to write them!  I'm sure I'll be spending plenty of time here for help. 

The forums have done more for me than my classes.  Thanks for the help guys I really appreciate it.

[dgorsman]

Have a serious look into Offline Files for laptops.  This will enable them to operate as normal when disconnected and automatically update when they are back on the network.

[dmfrazier]

Agreed.  That's what we do here.  We used to do it even for desktops, back when our network was "less reliable".  (We might still, except that we have replaced most of our desktops with notebooks.)

[ryled]

I will have to take a look into those, I've never heard of them but it sounds like an even better solution then what I did.