Macro to Open File Dialog Box to a Specific Location

[Brenda Tanner]

Thank you very much RenderMan, this looks like a good start but for some reason it's not picking up the filepath variable. The OPEN dialog box opens just fine but it's opening up to something Windows must have in it's memory...a folder on the local C:\ drive.

I'm very grateful for your guidance and advice here. We just threw the 800 lbs gorilla at this issue and mapped a new drive letter to T:\Checker...it's called just plain old Q:. This allows the macro to work from the menu (CUI). The IT guys are telling me that we must be missing something. If it works from the command line then it should work as a macro for a menu item. I would tend to agree with them.

[BlackBox]

Thank you very much RenderMan, this looks like a good start but for some reason it's now picking up the filepath variable. The OPEN dialog box opens just fine but it's opening up to something Windows must have in it's memory...a folder on the local C:\ drive.

You're welcome, Brenda.

The sub-function I posted checks for a valid file path (the argument you specify in the macro), and only if it (the argument) is a valid location, changes the registry key value that the Open dialog uses, otherwise no change is made prior to the macro calling the Open Command.

The sample macro posted is using the file path you specified in an earlier post. As I do not have this drive mapped in my setup, I used a different file path as String for my testing, but was successful in opening to multiple network locations.

Please post the macro you're attempting to use.

[Brenda Tanner]

^C^C^P(I:/ACAD/VLISP/OpenHere "T:/Checker");._open;^P

I have located the lisp file in a folder on the servers reserved for such things. The lisp file is running ok, it's just not picking up the filepath variable. Could it possibly be that my limited rights on this machine do not allow an edit to the Registry. I have asked IT about this and they kind of think that might be the issue but as always they are too busy putting out other fires to spend time with me on this...maybe later they can offer assistance.

OK...I just checked and writing to the Registry is not the problem. I made a new entry in it and added a few keys, then deleted them. All that worked well. Also I changed the name of the lisp file from _OpenHere to OpenHere.

[BlackBox]

Stop ... Your macro is incorrect.

Lets backup a bit, to make sure we've got the basics covered....

If you haven't already, please copy the LISP code I posted here into an empty text file, and save with the .LSP file extension. Name this file anything you wish, but for these instructions I'll use "OpenHere.lsp" as a given for the file's name.

Save "OpenHere.lsp" to any location that resides within your Support File Search Path (SFSP), and load this file either via APPLOAD, or via AcadDoc.lsp, or YourCuiName.mnl using the LOAD function.

_OpenHere is the function name, and not the file name (for "OpenHere.lsp"), thus the file path is not needed within the macro. Your macro should look like this:

^C^C^P(LispFunctionName Argument);._Open;^P

... Or:

^C^C^P(_OpenHere "T:/Checker");._Open;^P

Try that, and see if that corrects the undesired behavior. Let us now how this works out for you?

[Brenda Tanner]

RenderMan,

You're right. That took care of it. Now to convince the IT guys to autoload this LISP file. They are always skeptical about this kind of department wide policy change...in fact they hate any kind of change. Still, they serve their purpose around here fairly well.

OK. Just avoided that problem. Added something to the macro to have it load the LISP file on the fly. It works fine and IT will never have to be bothered with a policy change. Thanks.

[BlackBox]

No worries; glad you got it sorted.

We too have strict guidelines from our corporate CAD group (separate from IT), but AcadDoc.lsp falls under my realm of authority (as a CAD Lead for my regional group).

FWIW - *IF* your IT permits user customization (as we do), then ask them instead to simply consider incorporating this into the code that is loaded:

((lambda (user / file)
   (if (setq file (findfile (strcat user ".lsp")))
     (load file)
   )
 )
  (getvar 'loginname)
)

We build into our SFSP several paths that reside on the user's personal network space for customizations in each deployment for things like Main CUIx, LISP, Scripts, etc.. All of which are loaded prior to our corporate customizations. This both allows the user to be creative, and enforce our standards.

HTH

[BlackBox]

OK. Just avoided that problem. Added something to the macro to have it load the LISP file on the fly. It works fine and IT will never have to be bothered with a policy change. Thanks.

Provided "OpenHere.lsp" resides within SFSP:

^C^C^P(if (not _OpenHere)(load "OpenHere"));(_OpenHere "T:/Checker");._Open;^P

[Brenda Tanner]

Thanks a million for all your advice. But as they say about the best laid plans...

1. The method of using the LISP and ._Open command worked fine the first time. Then of course the user wants to open another file, but this time they will not be using the menu item I created because that's for a different set of files in a special folder. Of course when they choose <File><Open>. the same special location opens up.....WHACK...ticked off users who now have to navigate back their other typical folders.

2. OK...that being said and the user cools off. Now they choose the new custom menu again and go to open a file from the special location again. WHACK! The macro does not function now. The Open menu comes up but the Registry Key apparently has been written back to the same typical folder the user just opened.

3. On top of all this, we are finding that loading the custom menu into other user's computers is a hit or miss thing. I cannot believe what I'm seeing but I saw it now on two different machines. We loaded the menu file and all looked well. The user selected the choice from the menu and the macro executed. Now, we made a slight change to the macro and resaved the menu in the CUI screen. The user then tried to execute the menu choice again and it was still performing the old operation. WHACK! We then unloaded the menu and reloaded it. WHACK! Same thing. We shutdown AutoCAD and restarted it. WHACK the menu choice was still executing the old macro. I looked at the macro in the CUI and it shows the changes we made. We then unloaded the custom menu, cold booted the computer and reloaded the menu and it worked. The menu choice still has the big trouble of not keeping it's state over the session. If the user used the Open menu and changes the location where they select a file, when we run the macro again, it opens up to this new folder, not the targeted one we want.

The boss finally got ticked off enough at me to say just go back to the drive mapping method you had working and let's move forward. So for now at least, the macro:

^C^C^P(startapp "explorer.exe" "T:")

We will have to insist that all users map T:\ drive to this special location. But for now it's on to the next phase.

[BlackBox]

Not sure what's different on your end, but this works perfectly fine here, repeatedly.

FWIW - I'd like to think I do good work more often than not, but I would never incorporate something picked up from a CAD forum into our deployment, affecting multiple users, without first extensively testing on my own. Just saying.

When using the macro, a predefined location is set. So, yes, when a user issues the Open Command rather than using the Macro, the last location is now default. You've not implemented any sort of Command Reactor to reset that registry key, so yes, of course it's in that location.

We heavily use shortcuts here, so navigating to another project is a non-issue for us.

Sorry for any confusion, and good luck.

[JGA]

LISP I picked up years ago from an unknown source - works for me on 2011.

;========= Explorer to Current Directory
 
(Defun C:ECD ()
   (Setvar "Cmdecho" 0)
   (Command "Shell"
      (Strcat
         "Explorer /n,/e,"              ;Explorer, New Window, use Explorer View 
         (Chr 34)                       ;Quote marks
         (Getvar "dwgprefix")           ;Current drive and folder
         (Chr 34)                       ;Quote marks
      )                                 ;Close Strcat
   )                                    ;Close Command
   (Princ)
)                                       ;Close Defun on C:ECD

;========= Explorer to AutoSave Directory
 
(Defun C:EASD ()
   (Setvar "Cmdecho" 0)
   (Command "Shell"
      (Strcat
         "Explorer /n,/e,"              ;Explorer, New Window, use Explorer View 
         (Chr 34)                       ;Quote marks
         (getvar "savefilepath")        ;Current drive and folder
         (Chr 34)                       ;Quote marks
      )                                 ;Close Strcat
   )                                    ;Close Command
   (Princ)
)                                       ;Close Defun on C:EASD

Another from Lee Ambrosius;-

;; Created by: Lee Ambrosius
;;                HyperPics, http://www.hyperpics.com
;;
;; Last revised on: 06/15/03
;; Program is used to search for a file with in the AutoCAD Support paths.
;; It then will display the file in Explorer or folder view
;; Opens Explorer w/ Treeview and highlights the file
(defun c:BrowseToFileWithTree( / fileLoc fileName)
;  (setq fileName (getstring "\nEnter file name and extension to find: "))
; Added to open current file in Explorer 18/08/2005 JGA
  (setq fileName (getvar "DWGname"))
  (if (setq fileLoc (findfile fileName))
    (startapp "explorer" (strcat "/n, /e, /select," (substr fileLoc 1 (- (strlen fileLoc) (+ (strlen fileName) 1))) " \\" filename))
  )
)
;; Opens Explorer w/o Treeview and highlights the file
(defun c:BrowseToFileWithoutTree( / fileLoc fileName)
  (setq fileName (getstring "\nEnter file name and extension to find: "))
  (if (setq fileLoc (findfile fileName))
    (startapp "explorer" (strcat "/n, /select," (substr fileLoc 1 (- (strlen fileLoc) (+ (strlen fileName) 1))) " \\" filename))
  )
)
(defun c:B2FT()(c:BrowseToFileWithTree))
(defun c:B2F()(c:BrowseToFileWithoutTree))

(prompt "\nType B2FT or B2F to display a file in Windows Explorer.")
(princ)